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

32
© 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

Transcript of 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

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

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

2

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

Data Sharing Today The Problem

3

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

The Problem…

•  Provisioning by hand

•  Provisioning by value

•  Oversharing •  Lying!

4

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

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

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…

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

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

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

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

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

OAuth 2.0 Overview The Building Block

9

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

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

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

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

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

User Managed Access (UMA)

12

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

UMA: User-Centric Resource Sharing

13

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

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

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

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

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

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

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

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)

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

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

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

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)

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

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.

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

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)

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

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

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

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

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

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

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

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

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

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

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

BACKUP SLIDES

27

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

UMA: Relationship with OAuth2.0 & OIDC

28

Source: Eve Maler & UMA WG

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

Phase 1: protect a resource

29

UMA Flows

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

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

30

UMA Flows

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

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

31

UMA Flows

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

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

UMA Flows