First Steps With UMA

The resource owner is a user or legal entity that is capable of granting access to a protected resource.

The client is an application that is capable of making requests with the resource owner's authorization and on the requesting party's behalf.

The resource server hosts resources on a resource owner's behalf, and is capable of accepting and responding to requests for protected resources.

You can configure ForgeRock Identity Gateway 6 or later as an UMA resource server. For more information, see ForgeRock Identity Gateway 7.1 Gateway Guide.

The authorization server protects resources hosted on a resource server on behalf of resource owners.

You can set up AM to fully function as an authorization server in an UMA 2.0 deployment. AM provides an UMA provider service, an UMA grant type handler, and endpoints for resource registration, permission ticket generation, and UMA token introspection. AM also uses its OAuth Provider Service to generate OIDC ID tokens, and to provide claim tokens and its policy engine for UMA resource management.

The requesting party is a user or legal entity that uses a client to access a protected resource. The requesting party may or may not be the same as the resource owner. This actor is specific to the UMA protocol.

The resource owner manages their resources on the resource server.

The authorization server and the resource server are loosely coupled elements in an UMA deployment. Because of this, the authorization server can onboard multiple resource servers in any domain. To onboard multiple resource servers, the authorization server exposes a protection API that provides resource registration, permission tickets, and token inspection endpoints to bind the resource server and authorization server.

The API endpoints are protected by a PAT —an OAuth 2.0 token with a specific scope of uma_protection—which establishes a trust relationship between the two components.

For more information, see "/uma/resource_set".

The resource owner controls who has access to their registered resources by creating policies on the authorization server. This allows the resource owner to grant consent asynchronously, rather than at resource request time. As a result, the requesting party can access data using an RPT.

For more information, see "/json/users/{user}/uma/policies".

The client, acting on behalf of the requesting party, uses the authorization server's UMA Grant Flow to acquire an RPT, which is a token unique to the requesting party, client, authorization server, resource server, and resource owner. The requesting party and the resource owner can interact with their applications at any time they want. In some cases, the requesting party and the resource owner may be the same entity.

This interaction allows for party-to-party data sharing and access authorization delegation. The resource owner can grant consent by policy using the authorization server, rather than issue a token at runtime; thus, allowing for the asynchronous granting of consent.

The client presents the RPT to the resource server, which verifies its validity with the authorization server. If the token is valid and contains the sufficient permissions, the resource server returns the protected resource to the requesting party.