User-Managed Access

Last updated

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]

Contents

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. User Managed Access entities and relationships.png
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.

Related Research Articles

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.

SIMPLE, the Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, is an instant messaging (IM) and presence protocol suite based on Session Initiation Protocol (SIP) managed by the Internet Engineering Task Force.

Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL. Authentication mechanisms can also support proxy authorization, a facility allowing one user to assume the identity of another. They can also provide a data security layer offering data integrity and data confidentiality services. DIGEST-MD5 provides an example of mechanisms which can provide a data-security layer. Application protocols that support SASL typically also support Transport Layer Security (TLS) to complement the services offered by SASL.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of ID and password joined by a single colon :.

<span class="mw-page-title-main">OpenID</span> Open and decentralized authentication protocol standard

OpenID is an open standard and decentralized authentication protocol promoted by the non-profit OpenID Foundation. It allows users to be authenticated by co-operating sites using a third-party identity provider (IDP) service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log in to multiple unrelated websites without having to have a separate identity and password for each. Users create accounts by selecting an OpenID identity provider, and then use those accounts to sign on to any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites.

The eXtensible Access Control Markup Language (XACML) is an XML-based standard markup language for specifying access control policies. The standard, published by OASIS, defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies.

WHOIS is a query and response protocol that is used for querying databases that store an Internet resource's registered users or assignees. These resources include domain names, IP address blocks and autonomous systems, but it is also used for a wider range of other information. The protocol stores and delivers database content in a human-readable format. The current iteration of the WHOIS protocol was drafted by the Internet Society, and is documented in RFC 3912.

Attribute-based access control (ABAC), also known as policy-based access control for IAM, defines an access control paradigm whereby a subject's authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment attributes.

OAuth is an open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is used by companies such as Amazon, Google, Meta Platforms, Microsoft, and Twitter to permit users to share information about their accounts with third-party applications or websites.

<span class="mw-page-title-main">OpenSocial</span> Public specification aimed at social networking applications

OpenSocial is a public specification that outlines a set of common application programming interfaces (APIs) for web applications. Initially designed for social network applications, it was developed collaboratively by Google, MySpace and other social networks. It has since evolved into a runtime environment that allows third-party components, regardless of their trust level, to operate within an existing web application.

SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.

Security Assertion Markup Language (SAML) is a set of specifications that encompasses the XML-format for security tokens containing assertions to pass information about a user and protocols and profiles to implement authentication and authorization scenarios. This article has a focus on software and services in the category of identity management infrastructure, which enable building Web-SSO solutions using the SAML protocol in an interoperable fashion. Software and services that are only SAML-enabled do not go here.

<span class="mw-page-title-main">Kantara Initiative</span> Digital identity organization

Kantara Initiative, Inc. is a non-profit trade association that works to develop standards for identity and personal data management. It focuses on improving the trustworthy use of identity and personal data in digital identity management and data privacy.

JSON Web Token is a proposed Internet standard for creating data with optional signature and/or optional encryption whose payload holds JSON that asserts some number of claims. The tokens are signed either using a private secret or a public/private key.

<span class="mw-page-title-main">Automatic Certificate Management Environment</span> Communications protocol for automating interactions between certificate authorities and web servers

The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users' servers, allowing the automated deployment of public key infrastructure at very low cost. It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service.

Web API security entails authenticating programs or users who are invoking a web API.

<span class="mw-page-title-main">Well-known URI</span>

A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with /.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.

Token Binding is a proposed standard for a Transport Layer Security (TLS) extension that aims to increase TLS security by using cryptographic certificates on both ends of the TLS connection. Current practice often depends on bearer tokens, which may be lost or stolen. Bearer tokens are also vulnerable to man-in-the-middle attacks or replay attacks. In contrast, bound tokens are established by a user agent that generates a private-public key pair per target server, providing the public key to the server, and thereafter proving possession of the corresponding private key on every TLS connection to the server.

HIE of One is a free software project developing tools for patients to manage their own health records. HIE stands for Health Information Exchange, an electronic network for sharing health information across different organizations, hospitals, providers, and patients. This is one of a growing number of tools for encrypted data exchange within the healthcare sphere.

References

  1. Maler, E.; Machulak, M.; Richer, J. (2018-01-07). "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization". docs.kantarainitiative.org. Retrieved 2024-01-11.
  2. "UMA telecon 2015-02-23 - WG - User Managed Access - Kantara Initiative". kantara.atlassian.net. Retrieved 2024-01-11.
  3. 1 2 "User Managed Access Work Group". Kantara Initiative: Trust through ID Assurance. Retrieved 2024-01-11.
  4. "Case Studies - WG - User Managed Access - Kantara Initiative". kantara.atlassian.net. Retrieved 2024-01-11.
  5. CIS 2015 Tuesday, June 9 - George Fletcher, AOL , retrieved 2024-01-11
  6. "UMA telecon 2009-08-06 - WG - User Managed Access - Kantara Initiative". kantara.atlassian.net. Retrieved 2024-01-11.
  7. "WG - User Managed Access - Kantara Initiative". kantara.atlassian.net.
  8. 1 2 Richer, Justin; Jones, Michael B.; Bradley, John; Machulak, Maciej; Hunt, Phil (July 2015). OAuth 2.0 Dynamic Client Registration Protocol (Report). Internet Engineering Task Force.
  9. "Web Authorization Protocol (oauth)". datatracker.ietf.org. Retrieved 2024-01-11.
  10. "IETF104 - oauth WG - meeting minutes".
  11. "UMA Implementations - WG - User Managed Access - Kantara Initiative".
  12. "Digital Identity for Consumers and Workforce | ForgeRock".
  13. "Mission Critical Authentication and Authorization - Open Source vs On Demand". Archived from the original on 2014-02-09. Retrieved 2024-01-19. Gluu OSS implementation of UMA
  14. IDENTOS Inc. Federated Privacy Exchange (FPX)
  15. "An OpenID Connect reference implementation in Java on the Spring platform". github.com. Retrieved 2024-01-19.
  16. Atricore OSS implementation of UMA for Node.js
  17. "Rohe/Pyuma". GitHub . 22 January 2018.
  18. "Keycloak 4.0.0.Final". Archived from the original on 2019-03-06. Retrieved 2019-03-05.
  19. 1 2 "User Managed Access - Identity Server 5.8.0 latest - WSO2 Documentation".
  20. "Home - WG - User-Managed Access Developer Resources - Kantara Initiative". Archived from the original on 2016-02-16. Retrieved 2015-08-13.
  21. "Web Access Management | the Gluu Server for SSO, WAM, & 2FA | Gluu". Archived from the original on 2015-08-05. Retrieved 2015-08-13.
  22. "Jericho Systems Corporation Announces the Release of Consentral™ on FHIR for the Control of Sensitive Health Information". Archived from the original on 2019-06-15.
  23. "User-Managed Access (UMA) - ForgeRock".
  24. "Federated Privacy Exchange - by IDENTOS".
  25. "All Posts about OpenUMA" . Retrieved 2024-01-19.
  26. "ForgeRock Access Management" . Retrieved 2024-01-19.
  27. "Gluu - Open Source". Archived from the original on 2015-09-24. Gluu OSS implementation of UMA
  28. "Case Studies - WG - User Managed Access - Kantara Initiative".
  29. "HEART WG | OpenID". 27 October 2014.

Further reading