Sequence: RqP: Get Resource (Client) - ForgeRock/frdp-uma-resource-server GitHub Wiki

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.

The Sequence

  1. The Resource Owner (RO) obtains a "shareable link" that contains access information to the resource and the allowed scopes. The RO delivers the "shareable link" 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 "shareable link" into the CA. The CA submits a request to the Resource Server (RS) for the resource with the scopes. (Note: the CA does not provide a Requesting Party Token).
  3. 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. The "permission ticket" and information about the AS is returned to the Client Application (CA).
  4. A "claims token" is required to validate the Client Application (CA) and Requesting Party (RqP) with the Authorization Server (AS).
  5. The CA is a previously registered OAuth client with the AS. The CA obtains a Basic Auth header using its "client id" and "client secret".
  6. The CA submits a request POST /openam/oauth2/access_token to the AS for an access token (the "claims token"), with a scope of "openid", using the Basic Auth header to validate the CA.
  7. The AS determines that the RqP needs to authenticate and re-directed to a Login Interface.
  8. The RqP submits login credentials for authentication and a SSO session is created. The RqP is re-directed back to the oauth interface.
  9. The AS validates the Requesting Party (RqP) SSO session. The AS returns a "claims token" to the CA.
  10. Now that the Client Application (CA) has a valid "permission ticket" and "claims token", the Requesting Party Token (RPT) can be requested.
    1. The CA 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 CA.
  11. The Client Application (CA) makes a second request for the resource, to the Resource Server (RS), using the Requesting Party Token (RPT) and scopes.
  12. The Resource Server (RS) validates the Requesting Party Token (RPT) with the Authorization Server (AS).
    1. The RS gets the "meta data" related to the resource to obtain the resource's information on the Content Server (CS).
  13. 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.
  14. The Content Server (CS) receives the request, obtains the resource data and returns it.
  15. The RS passes the resource data to the Client Application (CA)
  16. The CA processes or displays the resource data.