Protocol for delegated authorization based on OAuth
User-Managed Access (UMA) is an OAuth-based access management protocol standard for party-to-party authorization.[1] Version 1.0 of the standard was approved by the Kantara Initiative on March 23, 2015.[2]
As described by the charter of the group that developed UMA,[3] the purpose of the protocol specifications is to “enable a resource owner to control the authorization of data sharing and other protected-resource access made between online services on the owner’s behalf or with the owner’s authorization by an autonomous requesting party”. This purpose has privacy and consent implications for web applications and the Internet of Things (IoT), as explored by the collection of case studies contributed by participants in the standards group.[4]
Comparison to OAuth 2.0
This diagram provides a high level overview of the entities and relationships involved in the UMA specification.
The diagram from [5] (see right) highlights key additions that UMA makes to OAuth 2.0.
In a typical OAuth flow:
A resource owner (RO), a human who uses a client application, is redirected to an authorization server (AS) to log in and consent to the issuance of an access token. This access token allows the client application to gain API access to the resource server (RS) on the resource owner's behalf in the future, likely in a scoped (limited) fashion. The resource server and authorization server most likely operate within the same security domain, and communication between them is not necessarily standardized by the main OAuth specification.
User-Managed Access adds three main concepts and corresponding structures and flows:
Protection API
UMA defines a standardized Protection API for the authorization servers with which resource servers communicate about data security. This API enables multiple resource servers to communicate with one authorization server and vice versa. Because the Protection API is itself secured with OAuth, it allows for formal trust establishment between each pair. This also allows an authorization server to present a centralized user interface for resource owners.
Requesting Party (RqP)
UMA defines requesting parties separately from resource owners. This enables party-to-party sharing and fine-grained delegation of access authorization. A resource owner need not consent to token issuance at runtime (i.e. each time their data is requested), but can instead define a policy at the authorization server to allow requesting parties asynchronous access to specific limited authorization scopes.
Trust Elevation
UMA enables access attempts to result in successful issuance of authorization tokens based on a process of trust elevation for requesting parties. This process may involve gathering identity claims or other claims from a requesting party, thus facilitating more robust security of resource owners' data.
History and background
The Kantara Initiative's UMA Work Group[3] held its first meeting[6] on August 6, 2009. UMA's design principles and technical design have been informed by previous work by Sun Microsystems employees, begun in March 2008, on a protocol called ProtectServe. In turn, ProtectServe was influenced by the goals of the Vendor Relationship Management movement and an offshoot effort called feeds-based VRM.
ProtectServe and UMA's earliest versions leveraged the OAuth 1.0 protocol. As OAuth underwent significant change through the publication of the Web Resource Authorization Protocol (WRAP) specification and, subsequently, drafts of OAuth 2.0, the UMA specification has kept pace, and it now uses the OAuth 2.0 family of specifications for several key protocol flows.
UMA does not use or depend on OpenID 2.0 as a means of user identification. However, it optionally uses the OAuth-based OpenID Connect protocol as a means of collecting identity claims from a requesting party in order to attempt to satisfy the authorizing user's access policy.[citation needed]
UMA also does not use or depend on the eXtensible Access Control Markup Language (XACML) as a means of encoding user policy or requesting policy decisions. UMA does not dictate policy format, as policy evaluation is performed internally to the authorization server (AS) from the UMA perspective. Typically, XACML would be used to implement the policies inside the AS. Its implementation is out-of-scope of UMA. The UMA protocol flows for requesting access permission have some features in common with the XACML protocol.
Standardization status
The UMA group conducts its work in the Kantara Initiative[7] and has also contributed a series of Internet-Draft specifications to the Internet Engineering Task Force (IETF) as an eventual home for UMA standardization work. To this end, the WG has contributed several individual Internet-Drafts to the IETF for consideration. One of these, a specification for OAuth dynamic client registration,[8] served as input for the more generalized mechanism ultimately developed for OAuth.[8]
UMA was presented to the OAuth Working Group[9] at the IETF 104 conference in March 2019,[10] but that did not result in any UMA specifications being adopted by the IETF.
Implementation and adoption status
The UMA core protocol has several implementations,[11] including several open source implementations. Sources of active and available open-source implementations include ForgeRock,[12] Gluu,[13] IDENTOS Inc.,[14] MITREid Connect,[15]Atricore, Node-UMA,[16] Roland Hedberg,[17]Keycloak,[18] and WSO2 Identity Server.[19] A Kantara Initiative group is working on developing "free and open-source software (FOSS), in several popular programming languages, that empowers developers to incorporate UMA protection and authorization API enablement into applications, services, and devices".[20]
UMA-enabled products are available from Gluu,[21] Jericho Systems,[22] ForgeRock,[23] IDENTOS Inc.[24] and WSO2 Identity Server [19]
Current processing and acceptance status
The UMA protocol has multiple implementations. Forgerock offers a first open source implementation under OpenUMA.[25] A first implementation of the authorization server is to be tested with OpenAM in the nightly build.[26]
Gluu has implemented UMA to secure and manage access to APIs.[27] Cloud Identity Limited has a full UMA implementation for securing and managing access to personal information and web APIs. Several others have expressed interest in implementation and interoperability testing to the working group.
Applicable use cases
UMA's architecture can serve a variety of consumer-facing and enterprise-facing use cases. The UMA group collects case studies on its wiki.[28]
One example set of use cases is in healthcare IT and consumer health. In the OpenID Foundation organization, a working group called Health Relationship Trust (HEART)[29] is working to "harmonize and develop a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs", building upon, among other standards, UMA.
Another example set of use cases, which originally influenced UMA's development, is in the area of "personal data stores" in the fashion of vendor relationship management. In this conception, an individual can choose an operator of an authorization service that accepts connections from a variety of consumer-facing digital resource hosts in order to offer a dashboard with resource sharing management capabilities.
Schwartz, Michael; Machulak, Maciej (2018). "User-Managed Access". Securing the Perimiter: Deploying Identity and Access Management with Free Open Source Software. Apress. ISBN9781484226018.
