User-Managed Access adds three main concepts and corresponding structures and flows.
First, User-Managed Access defines a standardized API at the Authorization Server, called the Protection API, that the Resource Server speaks to; this enables multiple Resource Server’s to communicate with one Authorization Server and vice versa, and because the Protection API is itself secured with OAuth 2.0, allows for formal trust establishment between each pair. This also allows an Authorization Server to present an Resource Owner with a centralized user interface.
Second, User-Managed Access defines a formal notion of a Requesting Party (RqP) that is autonomous from an Resource Owner, enabling party-to-party sharing and delegation of access authorization. An Resource Owner need not consent to token issuance at run time but can set policy at an Authorization Server, allowing an Requesting Party to attempt access with an asynchronous Operation.
Third, User-Managed Access 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.
User-Managed Access compiles with the Law of User Control and Consent#User-Managed Access 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
User-Managed Access defines how resource Owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of Resource Servers, and where a centralized Authorization Server governs access based on Resource Owner policies. Resource Owners configure authorization Servers with access policies that serve as asynchronous authorization Grants.
User-Managed Access serves numerous use cases where a Resource Owner uses a dedicated service to manage authorization for access to their resources, potentially even without the run-time presence of the Resource Owner. A variety of use cases can be found in UMA-usecases and UMA-casestudies.
Practical control of access among loosely coupled parties requires more than just messaging protocols. This specification defines only the "technical contract" between UMA-conforming entities. Work is ongoing to define recommendations for developing agreements about the rights and responsibilities of parties operating and using these entities on a contractual or legal level (see, for example, UMA-obligations). Parties operating entities that claim to be UMA-conforming should provide documentation of any rights and obligations between and among them.
In enterprise settings, application Access Control sometimes involves letting back-office applications serve only as Policy Enforcement Points (PEPs), depending entirely on access decisions coming from a central Policy Decision Point (PDP) to govern the access they give to requesters. This separation eases auditing and allows policy administration to scale in several dimensions. User-Managed Access makes use of a separation similar to this, letting the Resource Owner serve as a policy administrator crafting authorization strategies for resources under their control.
In order to increase interoperable communication among the Authorization Server, Resource Server, and OAuth Client, User-Managed Access leverages two purpose-built APIs related to the outsourcing of authorization, themselves protected by OAuth 2.0 (or an OAuth-based authentication protocol) in embedded fashion.
User-Managed Access allows a user to make demands of the requesting side in order to test their suitability for receiving authorization. These demands can include requests for information (such as "Who are you? or "Are you over 18?") and promises (such as “Do you agree to these non-disclosure terms?” or “Can you confirm that your privacy and data portability policies match my requirements?”).
User-Managed Access has enterprise implications as well as "user-centric" implications. Companies are using it for coordinating the protection of enterprise APIs in much the way that today's WEB Access Management (WAM) systems protect corporate web apps. As well, since it is a system for distributing authorization responsibilities, User-Managed Access has contractual and legal implications.
Further Explanations #User-Managed Access defines how Resource Owners can control protected-resource access by OAuth Clients operated by arbitrary Requesting parties, where the resources reside on any number of Resource Servers, and where a centralized Authorization Server governs access based on Resource Owner Policies.
A corresponding specification defines obligations of legally responsible parties that engage in UMA-conforming interactions. The effort to incubate the development of UMA as a web standard is taking place in the Kantara Initiative organization.
The purpose of the UMA Work Group (Kantara Initiative Charter) is to develop specs that let an individual control the authorization of data sharing and service access made between online services on the individual's behalf, and to facilitate interoperable implementations of the specs.
The most recent specifications for User-Managed Access 1.0 can be found at: https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol
Undergoing interoperability testing and increased OpenID Connect integration.
A Working Group of the Kantara Initiative free for anyone to join and contribute.
Simple OAuth based,
- Able for rapid-deployment
Contributed to the Standards for consideration:#Tokens:
- Protection API Token or PAT - An Entity seeking protection API access MUST have the OAuth Scope "uma_protection". An Access Token with at least this scope is called a Protection API Token (PAT) and an Entity that can acquire an Access Token with this OAuth Scope is by definition a Resource Server.
- Requesting Party Token or RPT - the Token that a client presents to a Resource Server when trying to access a Protected Resource.
- Authorization API Token or AAT - An Entity seeking authorization API access MUST have the OAuth Scope "uma_authorization". An Access Token with at least this scope is called an Authorization API Token or AAT and an Entity that can acquire an Access Token with this OAuth Scope is by definition a client.
More Information#There might be more information for this subject on one of the following:
- 10 Reasons Why OpenID Connect
- Access Control Models
- Auth 2.0 Resource Set Registration
- Authorization API
- Authorization Server
- Best Practices Password
- Best Practices for LDAP Security
- Consent Mechanism
- Consent Standards
- Federated Identity Management
- Gluu Server
- Health Relationship Trust
- Identity Provider (IDP)
- Life Management Platform
- Need to know
- Neo-Security Stack
- OAuth 2.0 Dynamic Client Registration Protocol
- OAuth 2.0 Profiles
- OAuth Scopes
- OAuth Token Profile
- OpenID Connect
- OpenID Connect Flows
- OpenID Connect Scopes
- Privacy Enhancing Technologies
- Protection API
- Protection API Token
- REST Profile of XACML
- Remember Me
- Requesting Party
- Requesting Party Token
- Requesting Party Token Endpoint
- Resource Set
- Target Resource
- The Laws of Relationships
- UMA 2.0
- User-Managed Access Profile
- WEB Access Management
- Web Authentication
- Web Blog_blogentry_030117_1
- Web Blog_blogentry_170617_1
- Web Blog_blogentry_260715_1
- Why OAuth 2.0