First Steps With UMA

UMA 2.0 is a lightweight access control protocol that defines a centralized workflow to let an entity (user or corporation) manage access to their resources.

It extends the OAuth 2.0 protocol and gives resource owners granular management of their protected resources by creating authorization policies on a centralized authorization server, such as AM.

UMA 2.0 uses the OAuth 2.0 actors in extended ways and introduces the requesting party as a new actor:

Actors and Actions in the UMA 2.0 Workflow
Diagram of the UMA workflow, and participants.

Resource Owner

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

Client

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

Resource Server

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.

Authorization Server

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.

Requesting Party

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.

1. Manage

The resource owner manages their resources on the resource server.

2. Protect

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 aPAT —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".

3. Control

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".

4. Authorize

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.

5. Access

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.

ForgeRock provides an example use case that will help you configure and demo the UMA flow.

Once you are familiar with the actors and the flow, read the rest of the topics to learn how to configure UMA in production environments, and the functionality that the AM REST APIs have to offer.

For additional UMA use cases, see:

Read a different version of :