Sequence: RqP: Request Resource - 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) but has not shared the resource with the Requesting Party (RqP) for any specific purpose.

The Sequence

The Requesting Party (RqP) must obtain the "shareable link" to submit a request. The RqP might may have been forwarded a "shareable link" from another RqP or it was obtained through a "Resource Discovery" mechanism.

  1. The Requesting Party (RqP) authenticates with the Authorization Server (AS) and has a Single-Sign-On (SSO) session
  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". The PAT, which is an access_token, is obtained. The RS submits a POST to the Authorization Server (AS), using the resource id, scopes, and PAT. 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). 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". The CA submits a request POST /am/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. The AS validates the Requesting Party (RqP) SSO session. The AS returns a "claims token" to the CA.
  5. Now that the Client Application (CA) has a valid "permission ticket" and "claims token", the Requesting Party Token (RPT) can be requested. The CA submits a request POST /am/oauth2/access_token to the Authorization Server (AS) for the RPT. The request MUST include the "permission ticket" and the "claims token".
    1. The Authorization Server (AS) checks for a policy, related to the resource, that allows the specified scope for the Requesting Party (RqP). The policy check fails. The AS creates a access request for the Resource Owner (RO). The AS returns an error indicating that there is "No Access" and that a request has been submitted.