Consent Management using UMA: Introduction to the · © 2007-2014 The MIT Kerberos & Internet Trust...

© 2007-2014 The MIT Kerberos & Internet Trust Consortium. All Rights Reserved.

Consent Management using UMA: Introduction to the

User Managed Access Protocol

Thomas Hardjono MIT Kerberos & Internet Trust Consortium

February 19, 2014

MIT CSAIL Security Seminar


Contents •  The Problem •  OAuth2.0 Overview •  UMA Overview

2


Data Sharing Today The Problem

3


The Problem…

•  Provisioning by hand

•  Provisioning by value

•  Oversharing •  Lying!

4

The “data price” for online service is too high: typing…


The Problem…

•  Meaningless consent to unfavorable terms

•  Painful, inconsistent, and messy access management

•  Oblivious oversharing

5

The “data price” for online service is too high: connecting…


The Problem…

•  Handy but insecure

•  Unsuitable for really sensitive data

6

The “data price” for online service is too high: private URLs…

© 2007-2014 The MIT Kerberos & Internet Trust Consortium. All Rights Reserved. 7

Data “sharing” today

Image source: http://informationanswers.com/?p=283

Mostly back-channel and unconsented


Privacy Issues

•  Web 2.0 access control is inconsistent and unsophisticated

•  To share with others, you have to list them literally

•  You have to keep rebuilding your “circles” in new apps

•  You can’t advertise content without giving it away

•  You can’t get a global view of who accessed what

•  You can unify access control under a single app

•  Your access policies can test for claims like “over 18”

•  You can reuse the same policies with multiple sites

•  You can control access to stuff with public URLs

•  You can manage and revoke access from one place

8

Privacy is about context, control, choice and respect – so UMA enables a “digital footprint control console”

Web 2.0 User-Centric


OAuth 2.0 Overview The Building Block

9


OAuth 2.0 (RFC6749) •  OAuth 2.0 is an “authorization framework” •  Primary use-case:

–  allow a Client (Web-Application) to get access to data at a Resource Server by getting an authorization token from an Authorization Server (AS)

•  Presumes authentication occurs elsewhere •  Design constraints:

–  RESTful Web-APIs –  Over HTTP/S –  JSON, JWT, JOSE Encryption/Signing –  Minimal (no) session management –  Browser (User Agent)

10


OAuth2.0 Typical Use-Case

Travel Management Web Application (OAuth Client)

Airline Itinerary (Resource

Server)

11

Resource Owner

(ALICE)

Authorization Server

Alice wants to authorize her TripIt account to have access to her Airline account


User Managed Access (UMA)

12


UMA: User-Centric Resource Sharing

13


Goals of UMA •  Develop model & protocol for user-centric

web access control management – Single-point of policy/rule configuration – For multiple Protected Resources – Across multiple Resource Servers – All legally “owned” by the User –  Internet-scale – Based on OAuth2.0 (and its constraints)

•  Identify points in the protocol flows at which legal obligations can be established

14


UMA Features •  UMA best seen as overlay above OAuth2.0

–  “Profiles” of OAuth2.0 and OpenID-Connect •  UMA defines additional functions:

– Requesting Party & Client – Three (3) types of OAuth2.0 Tokens – Several new endpoints/APIs – Authorization Server (Authorization Manager) – Resource Sets

•  UMA WG in the Kantara Initiative

15


Recall OAuth2.0 Entities (RFC6749)

16

Alice gives authorization to the Client (her account) to access data at the Resource Server (also her account)

OAuth2.0 addresses primarily “Alice-to-Alice” sharing


UMA Entities

17

Alice uses the UMA Authorization Server to set access-policy For her resources

Bob (Browser) uses the Client to access Alice’s resources

The Client is a Web-Application (same as OAuth Client)


UMA Phase-1: Alice registers resource

18

(1)

(2)

(1) Alice registers her Resource (e.g. files) Stored at RS to the AS & sets access Policy

(2) Alice “introduces” the RS entity to the AS entity (3)

(3) AS authenticates RS and issues a PAT token to the RS for future interactions


UMA Phase-2: Client gets authorization token

19

(1) (2)

(1) & (2) Bob uses Client to attempt access to Alice’s resources at the RS. (3) Client is redirected to the AS. (4) Client authenticates to AS and is issued an AAT token

(3)

(4)


UMA Phase-3: Bob gets authorization token

20

(1)

(2)

(3)

(4)

(5)

(1) Bob uses Client to attempt access to RS. (2) Client uses its AAT to attempts access to RS. (3) Client & Bob redirected to AS. (4) AS authenticates Bob and issues an RPT token to Bob. (5) Client may cache RPT token in Bob’s account for future access.


UMA Phase-3: Bob accesses Alice’s files

21

(1)

(2)

(3)

(4)

(1) & (2): Bob uses Client to access resource at RS, presenting RPT and AAT token. (3) & (4): RS returns resource to Client and Bob

UMA by design recognizes that the Client and Resource Server may be operated by separate entities (e.g. commercial operators)


UMA Defines 3 Types of OAuth Tokens •  AAT Tokens: Authorization API Tokens

–  Used by the Client to prove (to the Authorization Server) that it has authorization to access the APIs at the Authorization Server.

•  PAT Tokens: Protection API Tokens –  Used by the Resource Server to prove (to the

Authorization Server) that the Resource Owner (e.g. Alice) has authorized it to register resource at the Authorization Server.

•  RPT Tokens: Requesting Party Tokens –  Provides authorization for the Requesting Party to

access resources at the Resource Server.

22


UMA Key Implementations

23

•  SMARTAM.net (running authorization service from Cloud Identity UK)

•  Puma (Python libraries for RS- and client-enabling web apps) from ditto

•  Fraunhofer AISEC open-source implementation in Java

•  Gluu OX open-source implementation for Access Management 2.0 use cases


UMA WG & Specification •  UMA Core:

–  http://docs.kantarainitiative.org/uma/draft-uma-core.html –  IETF draft-hardjono-oauth-umacore-08

•  UMA Binding Obligations: –  http://docs.kantarainitiative.org/uma/draft-uma-trust.html –  IETF draft-maler-oauth-umatrust-02.txt

•  UMA Claims Profile –  Rev 01 very soon

24


Mission Statement

“The Mission of the MIT-KIT is to develop the basic building blocks for the Internet's emerging personal data ecosystem in which people, organizations, and computers can manage access to their data more efficiently and equitably.”

website: kit.mit.edu


Contact Information The MIT Kerberos & Internet Trust (KIT) Consortium 77 Massachusetts Avenue W92-152 Cambridge, MA 02139 USA

kit.mit.edu

Thomas Hardjono, PhD. Technical Lead & Executive Director Email: [email protected] Mobile: +1 781 729 9559 Twitter: @FindThomas Web: kit.mit.edu

26


BACKUP SLIDES

27


UMA: Relationship with OAuth2.0 & OIDC

28

Source: Eve Maler & UMA WG


Phase 1: protect a resource

29

UMA Flows


Phases 2 and 3: get authorization and access resource 1 of 3

30

UMA Flows



31

UMA Flows

Consent Management using UMA: Introduction to the · © 2007-2014 The MIT Kerberos & Internet Trust...

Documents

Transcript of Consent Management using UMA: Introduction to the · © 2007-2014 The MIT Kerberos & Internet Trust...