User Managed Access - UMA

From IIW

Issue/Topic: User-Managed Access (UMA)

Monday – Session 3 - E

Convener: Eve Maler

Notes-taker(s): Tom Holodnik

Tags: #UMA #authorization #user-centric #OAuth #JSON #Python #policy #claims

Discussion Notes:

For complete details, please see: http://kantarainitiative.org/confluence/display/uma/Home

The protocol flow is described here: http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol

Here’s a friendly overview: http://kantarainitiative.org/confluence/display/uma/UMA+Explained

Session slides: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf

History:

ProtectServe evolved into UMA. Last IIW, WRAP was presented; it overturned some OAuth dependencies that UMA had had.

UMA:

Influences:

  • policy-decision making
  • privacy
  • informational self-determination
  • data portability
  • the "open stack"
  • volunteered personal information
  • personal data stores

outcomes:

  • a dashboard that allows you to control access
  • engaged data sharing
  • a protocol headed toward IETF applications area
  • a set of draft specs free for anyone to implement
  • multiple implementations under way
  • simple, OAuth-based, identifier agnostic, RESTful, modular, generative (can be used to build more things) and developed rapdily
  • targeting delivery as a spec (to IETF) in the August time frame

The players:

  • Authorizing user - a web user who config's the AM with policies to control how to make access control decisions)
  • Host (protected resource server) - enforces access to the protected resources it hosts
  • Authorization Manager (AM) - carries out an authorizing users policies
  • Requester - an entity that wants to access the AU's resources

Compare OAuth and UMA models:

  • the UMA model is different from the OAuth model in subtle ways; it establishes a contract for access management
  • the UMA AM may also usefully be co-located with IdP and discovery

participants:

  • there is one resource owner and consumer in OAuth; the UMA user may be granting access to an autonomous party
  • resource server respects tokens from its authz server; the host outsources authz jobs to an authz manager chosen by the user
  • the authz server issues tokens based on the client's ability to authN; the authZ manager ussues tokens based on user policy and clienams coneryned by the requester

provisioning:

  • client and server must meet outside the OAuth context to provision trust; the requester can walk up to a protected reseource and attempt to get access without registering first

dynamic trust:

  • the resource server meets its authz server ahead of time and is coupled with it; the authz user can mediate the introduction of each of the hosts to the authz manager we wants to use
  • the resource server validates tokens in an unspecified manner, assumed locally; the host has the option to ask the authZ manager to validate tokens in real time

protocol:

  • OAuth: get a token, use a token; uma: intro, get token, use token
  • user delegation flows and automous flows; UMA: profiles of OAuth flows

relationship with OAuth: based on OAuth 2.

UMA Protocol Details: (reference the links at the top of the notes)

Establishing trust; passing a handle to the protected resources

  • could establish trust on first use (TOFU)

Policies:

  • unilateral - e.g. allow access for a week
  • claims-requiring - "allow anyone access who agrees to my licensing terms" or allow access to someone who can prove themselves to to bob@mailco.com, or allow access to anyone 18 years old or more.

Claims 2.0 are by default JSON based claims that establish attributes about a user; they don't have to be issued by the requester, but they could be issued by an IdP associated with the requester.

Demos and Implementations in progress:

SMART at Newcastle University: This illustrates how to issue and manage simple kinds of claims: http://kantarainitiative.org/confluence/download/attachments/38371737/SMARTOverview.pdf http://kantarainitiative.org/confluence/display/uma/SMART+project+user+experience

Christian Scholz: This illustrates how we might create policies and provision access to resources we want to protect with an UMA AM: Prototype: http://bitbucket.org/mrtopf/uma Demo: http://host.clprojects.net/

Comment: if the token does not contain information about the resource (and to whom it was issued), it's vulnerable to confused deputy

claims confirmation could be as simple as "confirm that you are over 18" or "confirm that you will abide by the terms of Creative Commons..." - enforceable legally, or could be supported by claims issued through CardSpace/InfoCards, could be a URL of a BBB statement, or a URL pointing to other indepedent assertion of claims.

Retrieved from "https://iiw.idcommons.net/index.php?title=User_Managed_Access_-_UMA&oldid=3655"