A Quick Guide To User-Managed Access 2.0

Introduction

User-Managed Access 2.0 or UMA is a new federated authorization standard protocol built on top of OAuth 2.0 which enables party-to-party sharing. Kantara Initiative has introduced this award winning protocol.

UMA gives a resource owner the ability to control who can access his or her protected resources (digital assets) from a centralized authorization server by creating authorization policies no matter where the resources reside. For example, an elderly person sharing health-related data (such as medical prescriptions and blood reports) with doctors, his or her insurance company, and family members.

Sharing of resources can be done selectively which helps individuals gain control of their resource sharing in a reliable and secured manner. The specialty of this protocol is that resource owners need not to be present online at the access time as the cross-party sharing is driven by predefined policies.

Using UMA 2.0 standards enables you to achieve the following:

• Context: The right moment to make the decision to share.
• Control: The power to share only what the resource owner desires.
• Choice: The ability to make an independent decision.
• Respect: Regard for one’s preferences.

UMA Versions

The first version, UMA 1.0, was released in 2015. Kantara Initiative officially announced the approval and publication of the UMA Version 2.0 technical specifications in February 2018. UMA 2.0 was designed to be closely associated with the well-known OAuth protocol, making it easier for implementation purposes and improving its security aspects.

UMA 2.0 Specification

The protocol consists of 2 specifications:

1. UMA 2.0 Grant for OAuth 2.0 Authorization: Specifies how a client should use a permission ticket to request an OAuth 2.0 access token to gain access to a protected resource asynchronously from the time a resource owner authorizes access.
2. Federated Authorization for UMA 2.0: Defines a means for an UMA-enabled authorization server and resource server to be loosely coupled, or federated, in a secure and authorized resource owner context. This specification is optional to be used with UMA grant.

Anatomy of UMA 2.0

UMA protocol consists of 5 roles:

1. Resource Owner: An entity which grants access to a protected resource.
2. Requesting Party: A person that seeks access to a protected resource by the support of a client.
3. Client: An application that makes requests for protected resources on behalf of the requesting party with the resource owner’s authorization.
4. Resource Server: A server that hosts protected resources and it has the capability of reacting to requests for protected resources.
5. Authorization Server: A server that protects resources hosted by resource server on behalf of the resource owner.

The manner in which the resource owner manages his/her resources at the resource server and the manner in which the resource owner defines policies at the authorization server are out of scope for the UMA specification.

The client acting on behalf of the requesting party needs to get a token from the authorization server before getting access to a UMA protected resource. The client interacts with the authorization server and provides the necessary claims that satisfies the resource owner’s policies. The client will then receive a token which it can present to the resource server in order to obtain the required access.

Protection API

This OAuth protected API provides the following endpoints:

1. Resource Registration Endpoint
2. Permission Endpoint
3. Token Introspection Endpoint (optional)

Prior to interacting with the protection API of the authorization server, the resource server should have acquired OAuth client credentials from the authorization server. To access the Resource Registration Endpoint, Permission Endpoint, and Token Introspection Endpoint, it is a must for the request made by the resource server to the authorization server to be accompanied with an access token, namely Protection API Access Token (PAT). PAT represents the resource owner’s authorization to use the protection API. The PAT token is simply an OAuth access token with the scope “uma_protection”. It uniquely represents the resource owner, resource server used for resource management, and authorization server used for protection of these resources.

Resource Registration Endpoint

Resource registration endpoint provides a means for the resource server to put resources under the protection of the authorization server on behalf of the resource owner and manage them over time.

A resource residing at a resource server falls under the protection of an authorization server by successful registration of the resource at the resource registration endpoint. The protection for the resource ends by de-registration at the resource registration endpoint. The resource owner can set policy conditions for the registered resource anytime before de-registration.

This API supports five registration options, which are:

• Create resource description: Registers a new resource to the authorization server using the POST method.
• Read resource description: Reads a previously registered resource description using the GET method.
• Update resource description: Updates a registered resource description, by completely replacing the previous resource description, using the PUT method.
• Delete resource description: Deregisters a previously registered resource description using the DELETE method.
• List resource descriptions: Lists all previously registered resource identifiers for this resource owner using the GET method.
• 
  

Permission Endpoint

This endpoint provides a means for the resource server to request permission(s) when the client’s resource request is unaccompanied by RPT (Requesting Party Token) or is accompanied by an invalid RPT.

A permission represents a resource identifier and its corresponding scopes. At a single instance, the resource server can only request permissions for access to the resources belonging to a single resource owner, protected by a single authorization server. As the response, the resource server receives a permission ticket which represents the same permissions that the resource server requested.

Token Introspection Endpoint

This endpoint provides a means for the resource server to introspect the RPT which is required to access a UMA protected resource.

UMA Grant

UMA grant can simply be defined as an extension of OAuth 2.0 grant. The grant enhances OAuth capabilities in the following ways:

• Enables party-to-party authorization. The resource owner authorizes access to his/her protected resource for clients used by entities that are in a requesting party role.
• Enables a resource owner configure an authorization server with authorization grant rules (policy conditions) at will, rather than authorizing access token issuance synchronously after authenticating. The authorization server and resource server interact with the client and requesting party in a way that is asynchronous with respect to resource owner interactions.

When a client, acting on behalf of the requesting party, makes an initial resource request at the authorization server without access token or invalid access token, the client receives a permission ticket and the authorization server location. The client can then obtain a Requesting Party Token (RPT) from the authorization server by presenting the received permission ticket and any other required claims. RPT will be issued with successful evaluation of policy conditions, scopes, claims, and any other relevant information.

A RPT is an OAuth access token associated with the UMA grant. An RPT is unique to a requesting party, client, authorization server, resource server, and resource owner. This token represents some number of granted permissions.

For issuance of RPT, claims collection is required. The UMA grant specification mentions that this can be achieved by a client directly pushing claims or by supporting an interactive claims gathering with an end-user requesting party.

原文链接：https://wso2.com/library/article/2018/12/a-quick-guide-to-user-managed-access-2-0/?utm_source=infoq&utm_medium=article&utm_campaign=infoq_2019