 | ||
User-Managed Access (UMA) is an OAuth-based access management protocol standard. Version 1.0 of the standard was approved by the Kantara Initiative on March 23, 2015.
Contents
- History and background
- Standardization status
- Implementation and adoption status
- Comparison to OAuth 20
- Applicable Use Cases
- References
As described by the charter of the group that developed UMA, 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.
History and background
The Kantara Initiative's UMA Work Group held its first meeting 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.
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 AS from the UMA perspective. However, 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 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, served as input for the more generalized mechanism ultimately developed for OAuth.
Implementation and adoption status
The UMA core protocol has several implementations, including several open source implementations. Sources of active and available open-source implementations include ForgeRock, Gluu, MITREid Connect, Atricore, Node-UMA and Roland Hedberg. 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” .
UMA-enabled products are available from Gluu and Jericho Systems and ForgeRock.
Comparison to OAuth 2.0
The diagram (see right) highlights key additions that UMA makes to OAuth 2.0.
In a typical OAuth flow, a human resource owner (RO) operating a client application is redirected to an authorization server (AS) to log in and consent to the issuance of an access token so that the client application can gain access to the resource server (RS) on the RO’s behalf in future, likely in a scoped (limited) fashion. The RS and AS are in all likelihood operating within the same security domain, and any communication between them is not standardized by the main OAuth specification.
UMA adds three main concepts and corresponding structures and flows. First, it defines a standardized API at the AS, called the protection API, that the RS speaks to; this enables multiple RS’s to communicate with one AS and vice versa, and because the API is itself secured with OAuth, allows for formal trust establishment between each pair. This also allows an AS to present an RO with a centralized user interface. Second, UMA defines a formal notion of a requesting party (RqP) that is autonomous from an RO, enabling party-to-party sharing and delegation of access authorization. An RO need not consent to token issuance at run time but can set policy at an AS, allowing an RqP to attempt access asynchronously. Third, UMA enables access attempts to result in successful issuance of tokens associated with authorization data based on a process of trust elevation in the RqP, for example, gathering identity claims or other claims from them.
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.
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) 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.