User-Managed Access

The Kantara Initiative's UMA Work Group[4] held its first meeting[5] 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 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.

The UMA group conducts its work in the Kantara Initiative[6] 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,[7] served as input for the more generalized mechanism ultimately developed for OAuth.[8]

The UMA core protocol has several implementations,[9] including several open source implementations. Sources of active and available open-source implementations include ForgeRock,[10] Gluu,[11] IDENTOS Inc.,[12] MITREid Connect,[13] Atricore, Node-UMA,[14] Roland Hedberg,[15] Keycloak.[16] and WSO2 Identity Server.[17] 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".[18]

UMA-enabled products are available from Gluu,[19] Jericho Systems,[20] ForgeRock,[21] IDENTOS Inc.[22] and WSO2 Identity Server [17]

This diagram provides a high level overview of the entities and relationships involved in the UMA specification.

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.

UMA's architecture can serve a variety of consumer-facing and enterprise-facing use cases. The UMA group collects case studies on its wiki.[3]

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)[23] 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.

• UMA FAQ
• User-Managed Access (UMA) Profile of OAuth 2.0 Recommendation
• OAuth 2.0 Resource Set Registration Recommendation
• UMA Implementations