AM as the UMA Authorization Server
In the role of the User-Managed Access (UMA) authorization server, AM grants delegated consent to a requesting party on behalf of the resource owner to authorize who and what can get access to their data and for how long.
Tip
Before configuring UMA in your environment, ensure you are familiar with the OAuth 2.0 standards and AM's implementation of OAuth 2.0.
Supported Specifications
AM supports the following UMA grants and specifications:
User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization
This specification defines an OAuth 2.0 extension grant, allowing a party-to-party authorization mechanism where entities in a requesting party role can access protected resources authorized by the resource owner using authorization policies. The specification also defines how a resource owner can configure an authorization server with authorization grant rules to run asynchronously with the resource server using an RPT versus granting consent at runtime.
Note
The User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization specification also discusses the use of the authorization server's claims interaction endpoint for interactive claims gathering during the UMA grant flow. AM does not currently support interactive claims gathering. Claims gathering is accomplished by having the client acquire an OpenID Connect ID token.
The specification also discusses the optional issuance of a persisted claims token (PCT), which is a correlation handle issued by the authorization server, representing a set of claims collected during one authorization process to be used in later ones. AM does not currently support PCTs, because AM uses an OIDC ID token for its claims.
For more information, see The UMA Grant Flow.
Federated Authorization for User-Managed Access (UMA) 2.0
This specification defines the loosely coupled federation of the authorization process by means of multiple resource servers in different domains that communicate with the centralized authorization server and acts on behalf of a resource owner. The authorization server can reside locally or in another domain from the resource server(s).
Tip
See the complete list of supported OpenID Connect and OAuth 2.0 standards.
Deployment Considerations
The UMA 2.0 process largely involves the UMA 2.0 Grant flow, in which a requesting party obtains an RPT to access the resource, and resource registration which can occur at various stages through the UMA process by the resource owner. These stages could occur at initial resource creation, when needed for policy creation, and at resource access attempt.
See the section, "Considerations Regarding Resource Registration Timing and Mechanism" in the UMA Implementer's Guide for information.
AM stores UMA-related data, such as resources, audit information, and labels in the configuration store by default, but this information may grow very large in environments with many users, or in environments where users own many resources.
In production environments, configure at least one external UMA store to hold UMA information.
For more information, see Configuring UMA Stores.
UMA Discovery
In order to let relying parties or clients discover the URL of the UMA provider and its configuration for an end user, AM exposes the following REST endpoints:
Discovery relies on WebFinger, a protocol to discover information about people and other entities using standard HTTP methods. WebFinger uses Well-Known URIs, which defines the path prefix /.well-known/ for the URLs defined by OpenID Connect Discovery.
Just like they do for OpenID Connect flows, relying parties need to find the right host:port/deployment-uri combination to locate the well-known endpoints. You must manage the redirection to AM using your proxies, load balancers, and others, such that a request to http://www.example.com/.well-known/webfinger reaches, for example, https://openam.example.com:8443/openam/.well-known/webfinger.