How Pauldron Implements Cascaded Authorization

(also posted here).

Summary: Pauldron implements Cascaded Authorization by allowing a client to submit a Requesting Party Token (RPT) issued by another UMA server as a claim token.

The goal of Cascaded Authorization is to allow an UMA server to base its decision, in part, on the decision of another UMA server –referred to as the upstream Authorization Server. This enables the UMA server to enforce policies that require the approval of the upstream server.

Cascaded Authorization paves the way for distributing authorization policies among a number of UMA servers, with a principal UMA server eventually adjudicating their decisions into a final authorization decision and a set of scopes. In this architecture, different types of authorization policies can be enforced by different UMA servers.

A common use-case discussed in the original Cascaded Authorization paper is enforcing patient consents. Patient consents can be collected and maintained by a separate entity which communicates patients’ preferences to the outside world via an UMA server. The authorization server of an EHR system can, then, consult this Consent UMA server for any access request which requires the patient’s consent, therefore, consider and incorporate the patient’s consent into its authorization decision, without having to manage and process patient consents locally.

As an experimental UMA implementation, Pauldron supports Cascaded Authorization as an extension with an emphasis on using the existing mechanisms in UMA and minimizing the extensions.

Pauldron uses the UMA referral response to direct a client to an upstream UMA server when necessary, and enables the client to submit the RPT acquired from that server in the form of a claim token.

Referral

In UMA, when a client requests for an RPT from the Authorization Endpoint, the UMA server either rejects this request or issues an RPT in response.

With the Cascaded Authorization extension in Pauldron, if the policy applicable to the request requires the approval of an upstream UMA server, the server responds with a 401 status and a ticket, after registering for the permissions with the upstream UMA server.

This is similar to the response sent by a Resource Server to the client in the first place when the approval of an UMA server is required.

The following shows a sample response from the Pauldron Authorization Endpoint, referring to another upstream UMA server.

Note that the additional information included in the body of this response is an extension to hint at the upstream UMA server endpoints; the client must ultimately rely on the server configuration information for this informatino as described in Section 1.4 of UMA specifications:

WWW-Authenticate: "UMA realm=\"Upstream UMA Server\",
                   as_uri=\"https://upstream-uma-server\",
                   ticket=\"b617dd56-e213-11e8-9f32-f2801f1b9fd1\""

{
   "message": "Need approval from https://upstream-uma-server.",
   "error": "uma_redirect",
   "status": 401,
   "info": {
      "server": {
         "realm": "Upstream UMA Server",
         "uri": "https://upstream-uma-server",
         "authroization_endpoint": "/authorization",
         "introspection_endpoint": "/protection/introspection",
         "permission_registration_endpoint": "/protection/permissions"
      }
   }
}

RPT Claim Token

After interacting with the upstream UMA server and acquiring an RPT, the client must go back to the original UMA server and present the upstream RPT to continue the authorization.

Pauldron enables this by allowing the client to include the upstream RPT as an additional claim token in the array of claim tokens presented to the Authorization Endpoint. The type of the claim should be set to rpt and it should include the actual token and the identity of the upstream server which issued the token. Note that the additional information only serves as a hint and the UMA server must verify this information with its own settings and the upstream configuration endpoint to make sure it can reliably get introspection for this RPT. The following shows a sample request by the client, after acquiring an RPT from the upstream UMA server:

{
   "ticket": "9a1b1f98-e216-11e8-9f32-f2801f1b9fd1",
   "claim_tokens": [
     {
        "format": "jwt",
        "token": "..."
     },
     {
        "format": "rpt",
        "token": "a3113d9e-e216-11e8-9f32-f2801f1b9fd1",
        "info": {
           "uri": "https://upstream-uma-server",
           "introspection_endpoint": "/introspection"
        }
     }
   ]
}

Introspection and Adjudication of Scopes

After receiving an upstream RPT as a claim, the UMA server requests for introspection from the issuing upstream server to ensure that the RPT is valid and to determine the granted scopes. If the RPT is valid, its granted scopes are sufficient, and other local policies also approve of the request, the UMA server issues the final RPT which grants the client ultimate access to the resources initially requested from the Resource Server.

An important step here is to adjudicate the scopes granted by the upstream server and decide which ones will eventually be granted to the client. At its own discretion, the UMA server can grant all or some of these scopes, or use them as the basis for granting an entirely different set of scopes.

Currently, Pauldron adjudicates the scopes simply by removing any scopes explicitly denied by the local policy. In other words, unless there is an explicit denial for a scope in the local policies, the Pauldron server re-grants whatever scope the upstream server has granted to the client.

Tweet