User-managed access (UMA) provides your customers and employees with a convenient way to determine who gains access to personal data and when, for how long, and under what circumstances. Users delegate access through a simple share button in their application and can monitor and manage sharing preferences through a central console.
UMA: What it is and why it is important
UMA (User Managed Access) is a standard authorization protocol approved by the Kantara Initiative, a professional group whose aim is to promote business relations based on digital identity management and data privacy on the grounds of technical and legal innovation. Built on OAuth 2.0, it facilitates the use of data, information and accesses shared by several parties.
UMA establishes a workflow in which the owners of certain resources manage the access that other team members have to a series of resources that would otherwise be protected. Key to UMA are the authorization policies that are established from a centralized authorization server.
User-managed access structure
Within the functions established for a UMA workflow, 5 main roles stand out; the resource owner, who establishes the control of these resources in such a way that, from a single authorization server, it manages different resources that are found in several servers; the authorization server or WSO2 Identity Server, which protects the resources in the resource server; the resource server, which hosts the protected resources and responds to requests for protected resources; the client, which is an application that acts on behalf of the requesting party; and the requesting party, the entity that wishes to access a protected resource using a client.
UMA 2 vs. OAuth2: Differences
OAuth2 is a data access delegation protocol that provides access to third party applications, which it calls ‘OAuth2 Clients’. The main difference with UMA is that, while UMA makes it possible for resource owners to delegate access to third parties based on well-defined authorization policies maintained on the authorization server (AS), OAuth2 allows such access on behalf of the resource owner (RO) using a temporary access token issued by an authorization server that has the approval of the owner.
UMA and OAuth2 do not compete with each other, on the contrary, UMA is extended from OAuth2 by the introduction of a new type of support called ‘UMA 2.0 Grant for OAuth 2.0’. OAuth2 has the so-called ‘Scope’, which can be used to name various permissions associated with a resource. UMA, on the other hand, has the possibility of naming resources to represent them and with an API to manage them.
UMA & WSO2 Identity Server
Ensuring data privacy has become both a priority and a major challenge for many public and private organizations. WSO2 Identity Server allows you to do this by collaborating with user-managed access. When the owner wants to share a resource within a resource server, for example the cloud, with another party, they can take advantage of the functionality offered by the WSO2 identity server. In this case, the data owner would use the UMA to outsource the authorization and proactively manage the resources, as well as their access from a single authorization server.
Defining access policies
The WSO2 Identity Server is used as the authorization server, defining policies as to who can access which resource and with what scope of permission. If a third party uses a mobile application to access data on behalf of someone else, and this third party makes a resource request without an access token with valid security credentials or RPT (Request Party Token), the resource server goes to the authorization server to request one or more permissions.
In return, the resource server receives a permission ticket and the resource server sends the client a newly created permission ticket and the URL of the authorization server.
The customer then requests an RPT providing valid claims and the permit ticket. The customer will receive an RPT if the authorization evaluation proves successful. From this point on, the customer can again request access to the information protected with the valid access token to the resource server.
