Post on 12-Aug-2015
transcript
My History with UMA
• 2009 Internet Identity Workshop session • Person-to-person protected sharing • Auto-updating digital photo frame • Charter member of the working group
Copyright © 2015 Cloud Identity Summit. All rights reserved. 3
Standards Timeline
Copyright © 2015 Cloud Identity Summit. All rights reserved. 4
JWT
Protect Serve UMA Core, OAuth Resource Set Registra:on
OAuth 1.0, 1.0a WRAP
OpenID AB/Connect Open ID
OAuth 2.0
08 09 10 11 13 12 14 15
Dynamic Client Reg (from UMA/OIDC contribu5ons)
OpenID Connect
User Managed Access Actors
Copyright © 2015 Cloud Identity Summit. All rights reserved. 5
resource owner
resource server authorization server
client
protected resources
(unnamed till now)
What is User Managed Access?
• Owner definition and control of access authorization policies for protected resources
• Access requests from arbitrary clients • Centralized authorization policy • Resource servers enforce policy decisions • Binding obligations • Profile of OAuth2
Copyright © 2015 Cloud Identity Summit. All rights reserved. 6
UMA and Privacy by Design
Copyright © 2015 Cloud Identity Summit. All rights reserved. 7
I want to share data and access selectively• Among my own apps• With family and friends• With organizations
I want to protect this stuff from being seen by everyone in the world
I want to control access proactively, not just feel forced to consent over and over
tinyurl.com/umapbd
Why is this important?
• Next evolution beyond consent • Consent not required at run-time • Much richer set of policy components • Audit and transparency • Mutual consent between parties
Copyright © 2015 Cloud Identity Summit. All rights reserved. 8
Steps of the UMA Flow
1. Protect a resource • Register endpoints and permissions
2. Obtain an authorization token • Identify parties • Negotiate claims
3. Access the resource
Copyright © 2015 Cloud Identity Summit. All rights reserved. 10
Protection API
Copyright © 2015 Cloud Identity Summit. All rights reserved. 11
• Resource registration endpoint• Permission registration endpoint• Token introspection endpoint
The PAT protects the API and binds the RO, RS, and AS
Resource set registration
• OAuth2 proposed extension • Outsource authorization policy of RS endpoints to AS • RS is final authority for releasing access
Copyright © 2015 Cloud Identity Summit. All rights reserved. 12
{ "name" : ”Calendar", "icon_uri" : "http://mycals.example.com/icons/cal.png", "scopes" : [ "http://mycals.example.com/dev/scopes/view_busy", "http://mycals.example.com/dev/scopes/sched_normal" ], "type" : "http://www.example.com/rsets/calendar" }
Authorization API
Copyright © 2015 Cloud Identity Summit. All rights reserved. 13
• RPT endpoint
The AAT protects the API and binds the RqP, client, and AS
The client may be told: “need_info”, necessitating trust elevation for authentication or CBAC (or, through extension, ABAC)
Claims negotiation
Copyright © 2015 Cloud Identity Summit. All rights reserved. 14
A “claims-aware” client can proactively push an OpenID Connect ID token, a SAML assertion, a SCIM record, or other available user data to the AS per the operative trust framework
A “claims-unaware” client can, at minimum, redirect the requesting party to the AS to log in, press an “I Agree” button, fill in a form, follow a NASCAR for federated login, etc.
If the AAT was minted with too-weak authentication, the AS can request step-up for it as well
Protected Resource
Copyright © 2015 Cloud Identity Summit. All rights reserved. 15
The RPT is the main “access token” and (by default – it’s profilable) is associated with time-limited, scoped permissions
The RPT is a tuple of these four entities; it may potentially span ROs because the C or RqP should not know which RO controls which resource.
Binding Obligations
Copyright © 2015 Cloud Identity Summit. All rights reserved. 16
Subject or Individual
Non-person entity
Authorizing Party
Requesting Party
Resource Server Operator
Client Operator
Requesting Party Agent
Authorization Server Operator
New obligations (and rights) tend to appear at important protocol “state changes”
Detailed use case
• Alice needs to coordinate a meeting with an important client Bob
• Alice wants to allow Bob to view her calendar so he can pick a time that works for both of them
• Bob can schedule over normal calendar events but not ones designated as high priority
Copyright © 2015 Cloud Identity Summit. All rights reserved. 18
Copyright © 2015 Cloud Identity Summit. All rights reserved. 19
Use Case Actors
authZ4me (UMA AS)
scheduleMe (cal client)
myCals (cal srvc)
Alice
Bob
Copyright © 2015 Cloud Identity Summit. All rights reserved. 20
Alice registers protection for her calendar
authZ4me (UMA AS)
scheduleMe (cal client)
myCals (cal srvc)
Alice
Bob
OAuth2 Flow {PAT}
Register Calendar endpoints and permissions
Alice registers UMA protection of her calendar
• Standard OAuth2 flow between myCals and authZ4me to obtain a “PAT”
• myCals registers Alice’s calendar • https://mycals.example.com/cal/alice/work
• View, view_busy, delete, update, download, publish • Schedule_all, schedule_normal
Copyright © 2015 Cloud Identity Summit. All rights reserved. 21
Copyright © 2015 Cloud Identity Summit. All rights reserved. 22
Alice defines authorization policy
authZ4me (UMA AS)
scheduleMe (cal client)
myCals (cal srvc)
Alice
Bob
AuthZ Policy: Must be Bob Perm: view_busy schedule_normal
Alice sends Bob an email
Copyright © 2015 Cloud Identity Summit. All rights reserved. 23
Hi Bob, Please view my calendar and schedule the meeting we spoke about today. https://mycals.example.com/cal/alice/work Thanks, Alice
Copyright © 2015 Cloud Identity Summit. All rights reserved. 24
Bob meets claims to access Alice’s calendar
authZ4me (UMA AS)
scheduleMe (cal client)
myCals (cal srvc)
Alice
Bob
OAuth2 Flow {AAT}
Copyright © 2015 Cloud Identity Summit. All rights reserved. 25
Bob subscribes to Alice’s calendar
authZ4me (UMA AS)
scheduleMe (cal client)
myCals (cal srvc)
Alice
Bob
Subscribe {RPT}
Calendar View
Select Mtg Time
Bob schedules a meeting with Alice
• Scheduleme POST’s to • https://mycals/cal/alice/work/meeting
• Date, time, location • Passes RPT in the HTTP Authorzation header
Copyright © 2015 Cloud Identity Summit. All rights reserved. 26
Copyright © 2015 Cloud Identity Summit. All rights reserved. 27
Meeting added to Alice’s calendar
authZ4me (UMA AS)
scheduleMe (cal client)
myCals (cal srvc)
Alice
Bob
Add Mtg {RPT}
Mtg Scheduled
Select Mtg Time
Use case take-aways
• Resource set and permission/scope definition very flexible and extensible • Resource server defined not AS defined
• Fine grained authorization across domains • Rich set of authorization policy options {trust elev} • Provides transparency for Alice as Bob walks through
the process
Copyright © 2015 Cloud Identity Summit. All rights reserved. 28
UMA Use Cases
Health Financial Education Personal Government Media Enterprise
Copyright © 2015 Cloud Identity Summit. All rights reserved. 29
tinyurl.com/umacase tinyurl.com/umaiiot tinyurl.com/umaam20
Web
Mobile
API
IoT
UMA Working Group
• 1.0 core released • RSR submitted to the OAuth2 working group • Looking for implementations • Testing suite in the works
Copyright © 2015 Cloud Identity Summit. All rights reserved. 30
1.0
Q&A
• UMA working group URL • tinyurl.com/umawg
• UMA CORE spec URL • tinyurl.com/umav1
• OAuth2 resource set reg URL • https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html
• UMA Use cases URL • tinyurl.com/umacase
Copyright © 2015 Cloud Identity Summit. All rights reserved. 31
• Text is Arial Narrow 28pt. • Use Red for Emphasis
Copyright © 2015 Cloud Identity Summit. All rights reserved. 33