CIS 2015 User Managed Access - George Fletcher

User Managed Access George Fletcher

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


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


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


UMA and Privacy by Design


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



UMA v1.0 The Protocol

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


Protection API


•  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


{ "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


•  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


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


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


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”


Let’s Make it Real

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



Use Case Actors

authZ4me (UMA AS)

scheduleMe (cal client)

myCals (cal srvc)

Alice

Bob


Alice registers protection for her calendar

authZ4me (UMA AS)


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



Alice defines authorization policy

authZ4me (UMA AS)


myCals (cal srvc)

Alice

Bob

AuthZ Policy: Must be Bob Perm: view_busy schedule_normal

Alice sends Bob an email


Hi Bob, Please view my calendar and schedule the meeting we spoke about today. https://mycals.example.com/cal/alice/work Thanks, Alice


Bob meets claims to access Alice’s calendar

authZ4me (UMA AS)


myCals (cal srvc)

Alice

Bob

OAuth2 Flow {AAT}


Bob subscribes to Alice’s calendar

authZ4me (UMA AS)


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



Meeting added to Alice’s calendar

authZ4me (UMA AS)


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


UMA Use Cases

Health Financial Education Personal Government Media Enterprise


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


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


Appendix


•  Text is Arial Narrow 28pt. •  Use Red for Emphasis


CIS 2015 User Managed Access - George Fletcher

Technology

Transcript of CIS 2015 User Managed Access - George Fletcher