Abstract

There may be a situation where the Resource Owner (RO) and / or the Resource Server (RS) needs to "control" what Client Application (CA) is being used by the Requesting Party (RqP). The Resource Owner (RO) might have a resource that should only be accessed via special client because a specific resource might be "restricted" or have a security level (like classified, secret, top secret). The Resource Server, managed by a specific organization, might want to ensure that its resources are only accessed by Requesting Parties (RqPs) that are using clients that belong to their "trust network"

Current Environment

The UMA 2.0 specification has a policy model that enables the Resource Owner (RO) to declare which "resource" can be accessed by a given Requesting Party (RqP) for an allowed set of scopes. After a policy has been established for a given resource (see below) the Requesting Party can access the resource by obtaining a valid Requesting Party Token (RPT) from "any" valid client.

{
    "policyId": "0d7790de-9066-4bb6-8e81-25b6f9d0b8853",
    "permissions":
    [
        {
            "subject": "bob",
            "scopes": [
                "view",
                "comment"
            ]
        }
    ]
}

To obtain the "resource" the Requesting Party (RqP) must perform these steps:

1. Get a Permission Ticket from the Resource Server ... this verifies that the "resource" is a registered UMA Resource affiliated with the Resource Server (RS) / Resource Owner (RO)
2. Authenticate to the Authorization Server (AS) ... in this case we will obtain an authorization code
3. Get a Claim Token, using the authorization code, which proves the Requesting Party (RqP) is using an OAuth client known by the Authorization Server (AS)
4. Get a Requesting Party Token (RPT), with the Permission Ticket and a valid Claim Token, from the Authorization Server (AS)
5. Submit the Requesting Party Token (RPT) to the Resource Server to obtain the "resource"

The Resource Server (RS) and the Resource Owner (RO) have no control over what "client" was used by the Requesting Party (RqP). The only client validation is that the client is known / trusted by the Authorization Server.

Enhancement Request

The process of obtaining a "resource" should support allowed clients. There should be an option for specifying what clients are either allowed or denied. Defining which clients are allowed or denied should be configured for all resources on a given Resources Server. Resource Owner should be allowed to set allowed or denied clients for a specific "resource". Possible client configuration all resources or a specific resource:

{
    "clients": {
        "allow": [ "secret", "top-secret" ],
        "deny": [ "*.com" ]
    }
}

Implementation Ideas

Authorization Server

The Authorization Server (AS) could be enhanced to only issue Requesting Party Tokens (RPT) when the Claim Token is from an "allowed" client

Resource Server

The Resource Server (RS) could be enhanced to only honor Requesting Party Tokens (RPT) that came from an "allowed" client