Access Management 7.3.2

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:

AM acts as the Authorization Server in the UMA workflow.
Figure 1. Actors and actions in the UMA 2.0 workflow
UMA actors explained
Resource owner

The resource owner is a user or legal entity that can grant access to a protected resource.

Client

The client is an application that can make 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 can accept and respond to requests for protected resources.

You can configure ForgeRock Identity Gateway as an UMA resource server.

Authorization server

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

You can set up AM to 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 policies 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.

UMA actions explained

  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 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 the /uma/resource_set endpoint.

  3. Control

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

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

  4. Authorize

    The client, acting on behalf of the requesting party, uses the authorization server’s UMA Grant Flow to acquire an RPT. The RPT is a token that is 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. In some cases, the requesting party and the resource owner can be the same entity.

    This interaction allows for party-to-party data sharing and delegated access authorization. The resource owner grants consent by policy, using the authorization server, rather than by issuing a token at runtime. Consent is thus granted asynchronously.

  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 sufficient permissions, the resource server returns the protected resource to the requesting party.

ForgeRock provides an example use case to help you configure and demonstrate the UMA flow.

When you are familiar with the actors and the flow, read the rest of these topics to configure UMA in production environments, and to understand the UMA functionality that the AM REST APIs offer.

For additional UMA use cases, see: