...
Externalizing an authorization decision requires a formal registration process and consequently a delegation of protection of a resource.
Furthermore, because the AM does not know the requester directly, it has to use information from third parties who know the requester better. Normally, the AM trusts these third parties only for certain things and only to certain degrees.
These trust and delegation aspects make UMA's authorization system different from traditional access control.
The following diagram illustrates is an high level representation of the UMA Trust Model which describes the trust relationships. We use a multiple triangles representation because it's useful to represent this complex trust relationship (2 parties + one authority).
In the diagram are represented the three main aspects of the UMA trust model:
- Registration (Host-AM trust relationship),
- Trusted Claims (AM-Requester trust relationship) and
- Delegation (Host-Requester trust relationship)
...
The Trusted Claims aspect describes the AM-Requester (on behalf of Requesting Party) relationship.
UMA is designed to support claims-based Access Control, by which the access control decision to grant access to Authorizing User's resource (Protected Resource at Host) is made based on Requesting party information, such as Subject's name, age (or date of birth) email address, role, location, or score credit, etc.
In general, in UMA authorization system, there is no relationship between a Requester and the Authorization Manager (AM) prior to a request. Because the AM does not know the requester directly, to satisfy the access policy, it has to ask for information (Trusted Claims) from third parties who know the Requester better.
UMA trust model leverages the Trust Framework in order to trust identity (claims) issues from Identity Service provider.
For this specific purpose, UMA protocol provides an OpenID Connect claim profile based on OpenID Connect specification.
OpenID Connect provides authentication, authorization, and attribute transmission capability. It allows third party attested claims from distributed sources.
OpenID Connect specification refers to the Authentication Context which is an information that the Relying Party (AM) may require before it makes an entitlements decision with respect to an authentication response. Such context may include, but is not limited to, the actual authentication method used or level of assurance such as ITU X.1254 | ISO/IEC 29115|\ entity authentication assurance level.
The picture below shows an high level diagram about UMA and OpenID Connect interoperability model based on the following steps:
...