AM as UMA authorization server
In the role of UMA authorization server, AM grants delegated consent to a requesting party on behalf of the resource owner, to authorize who and what can access their data, and for how long.
|
Before you configure UMA in your environment, familiarize yourself 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.
For more information, see 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).
|
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 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.