OAuth, OpenID Connect and User Manage Access is allowing IDAM to become decentalized which allows the ability to scale and allow agile federation.#https://kantarainitiative.org/confluence/display/uma/Privacy+by+Design+Implications+of+UMA
- Resource Owner (Alice)
- Authorization Server
In OAuth 2.0 there is no specification as to how the Authorization Server and the Resource Server communicate. Typically is assumed they are within the same security domain, often on the same server, and the communication is proprietary.
The User Managed Access specification further defines relationships between the Entities:#Resource Server exposes whatever it wants and is protected by the Authorization Server, Just like in OAuth 2.0 The Requesting Party Token maybe thought of as the Access Token from OAuth 2.0 with a few extra properties which make it more flexible and is presented to the Authorization Server Requesting Party Token Endpoint. User Managed Access the Authorization Server has to Interact with the Resource Server perhaps over the Internet as they could be operated by different companies.
The Authorization Server exposes a Protection API which is protected by the Protection API Token which allows the Resource Server to inform the Authorization Server via the Resource Set Registration Endpoint of which Resources need protected and which OAuth Scopes are applicable to each Resource. This communication is defined within the Auth 2.0 Resource Set Registration.
The Authorization Server is the authoritative source for the Resource Owner (Alice), but, the Resource Server is authoritative for what it's API can dp and what the Resource Owner (Alice) has created there.User Managed Access exposes a Authorization API protected by an Authorization API Token or AAT for the OAuth Client. In User Managed Access the Authorization Server can consume User Managed Access, SAML or OpenID Connect based Claims for Authorization.
Requesting Party (Bob) must consent to the OAuth Client working with the Authorization Server as "claims" about him may need to be revealed to pemit his access to the Resource Server which is done via the Authorization API Token.
Authorization Server and Requesting Party (Bob)#If the Requesting Party (Bob) can prsent
Key Use Cases for User Managed Access http://bigdata.csail.mit.edu/
Managing Personal Data Store Access#Where Alice the owner of the Personal Data Store determines others Authorization.
Protected Resource Sharing#
Blue Button (http://www.healthit.gov/patients-families/blue-button/about-blue-button)#
Tradiional WAM vs User Managed Access#
|Traditional WEB Access Management||User Managed Access|
|Complex and feature-rich||RESTful and simpler|
|Usually proprietary||Standard interop baseline|
|Brittle deployment architecture (Agents)||Just call Endpoints|
|NOT agnostice to Authentication method||agnostic to Authentication Method and federation|
|Hard to source distributed Policies||flexible in policy expressions and sourcing|
|Usually coarse-grained||Leverages API's "scope-grained Authorization"|
Enterprise User Managed Access case study
Out-Of-Band Actions that are not in the specifications Alice decides what resources are protected which is not in the specifications. Alice also sets the policies in regards to protections of Resources.
Some References for user Managed Access