Web Blog_blogentry_260715_1


OAuth, OpenID Connect and User Manage Access is allowing IDAM to become decentralized which allows the ability to scale and allow agile federation.#


OAuth 2.0 has three Entities #

- Is responsible to be or Authorization server to the PIP

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.

In User Managed Access, the Resource Server may outsource protection to a centralized Control Console.

In User Managed Access, the Authorization Server implements standardized APIs for privacy and selective Sharing.

User Managed Access adds an additional Entity the Requesting Party (Bob). The usage case was what if Alice wants to share with Bob.

The User Managed Access specification further defines relationships between the Entities:#

Resource Server and OAuth Client#

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.

Authorization Server and Resource Server#

In 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.

The Resource Server may have a one-to-many relationship(s) with Authorization Servers.

Resource Owner (Alice) must consent to the Authorization Server and Resource Server working on her behalf which is done with via the Protection API Token.

Authorization Server and OAuth Client#

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

In User Managed Access

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 ManagementUser Managed Access
Complex and feature-richRESTful and simpler
Usually proprietaryStandard interop baseline
Mobile/API ??Mobile/API-Friendly
Brittle deployment architecture (Agents)Just call Endpoints
NOT agnostice to Authentication methodagnostic to Authentication Method and federation
Hard to source distributed Policiesflexible in policy expressions and sourcing
Usually coarse-grainedLeverages 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

More Information#

There might be more information for this subject on one of the following: ...nobody