The Process

The Requesting Party (RqP) is a subject that accesses resources for a specific purposes (scopes). The resources are owned and managed by the Resource Owner (RO). The Resource Owner decides which resources a subject may access and for what purposes.

This scenario assumes that the Resource Owner (RO) has previously created a resource, registered the resource with an Authorization Server (AS) and shared the resource with the Requesting Party (RqP) for a set of purposes (scopes).

This scenario also assumes that the Requesting Party (RqP) is an existing user known to the Authorization Server (AS). The RqP will need to during the resource access process.

This scenario uses a UMA Client Proxy to "off load" the UMA dialog between the Resource Server (AS) and the Authorization Server (AS). This enables multiple Client Application (CA) to easily access shared resources without having to implement the UMA interaction details.

The Sequence

1. The Resource Owner (RO) obtains a "Resource Id" that contains access information to the resource and the allowed scopes. The RO delivers the "Resource Id" (and scopes) to the Requesting Party (RqP).
2. The Requesting Party (RqP) accesses a Client Application (CA), which is used to access the resource. The RqP enters the "Resource Id" (and scopes) into the CA. The CA submits a request to the RqP Client Proxy Identity Gateway (CPIG) for the resource with the scopes.
3. The RqP Client Proxy Identity Gateway (CPIG) determines that a Requesting Party Token (RPT) is needed. A request is submitted using the Resource Id and scopes.
4. The Resource Server (RS) gets the "meta data" for the resource. The Protection API Token (PAT) credential record key is stored in the "meta data".
   1. The PAT, which is an access_token, is obtained.
   2. The RS submits a POST to the Authorization Server (AS), using the resource id, scopes, and PAT.
   3. The AS returns a "Permission Ticket". The "permission ticket" ensures that the resource, scopes, Resource Owner (RO) and RS are valid.
   4. The "Permission Ticket" and information about the AS is returned to Resource Server Identity Gateway (RSIG).
   5. The "permission Ticket" and information about the AS is returned to RqP Client Proxy Identity Gateway (CPIG).
5. A "Claim Token" is required to validate the Client Application (CA), in this case the Client Proxy Identity Gateway (CPIG) and Requesting Party (RqP) with the Authorization Server (AS). The OAuth "authorization code" flow is used to obtain the "Claim Token"
   1. Using the sso session token, submit request to Authorization Server (AS) using .../oauth2/authorize end-point. An "Authorization Code" is returned.
   2. Using the "Authorization Code", submit request to Authorization Server (AS) using .../oauth2/access_token end-point. The "Claim Token" is returned.
6. Now that the Client Proxy has a valid "Permission Ticket" and "Claim Token", the Requesting Party Token (RPT) can be requested.
   1. The CPIG submits a request POST /openam/oauth2/access_token to the Authorization Server (AS) for the RPT.
   2. The request MUST include the "Permission Ticket" and the "Claims Token".
   3. The AS returns the RPT to the CPIG.
7. The Client Proxy Identity Gateway (CPIG) makes a second request for the resource, to the Resource Server (RS) using the Requesting Party Token (RPT) and scopes.
8. The Resource Server (RS) validates the Requesting Party Token (RPT) with the Authorization Server (AS).
   1. The RS gets the "meta" data and / or "content" related to the resource to obtain the resource's information on the Content Server (CS).
9. The Resource Server (RS) submits a request to the Content Server (CS) to obtain the actual resource.
   1. The CS is protected by an Identity Gateway (IGCS) and only allows authorized access.
   2. The RS request contains "proxy credentials" for authentication.
10. The Content Server (CS) receives the request, obtains the resource data and returns it.
11. The RS passes the resource data to the Client Proxy Identity Gateway (CPIG)
12. The CPIG passes the response to the CA
13. The CA processes or displays the resource data.