Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
User-Managed Access (UMA)
in the ACE Context
Eve Maler, chair
@UMAWG | @xmlgrrl
13 January 2015
tinyurl.com/umawg
1
Agenda
•  UMA’s design center, progress, and status
•  A quick “UMA 101” primer
•  Measuring UMA against ACE use cases
•  ...
OpenID
Connect
UMA
OAuth 2.0
The “new Venn” of web access control and consent
The marvelous spiral of controlled
personal data/access sharing
4
Interoperable, RESTful
authorization-as-a-service
5
Has standardized APIs
for privacy and
“selective sharing”
Outsources p...
Use-case domains
Health
Financial
Education
Personal
Government
Media
Behavioral
Enterprise
Web
Mobile
API
IoT
Web/API identity and security
specification progress in context
7
Protect	
  
Serve	
  
UMA	
  Core,	
  Resource	
  Set	
 ...
Other major news items
•  EIC award in
Munich
•  HEART WG at
OpenID
Foundation
•  New open-source
community:
OpenUMA at
Fo...
Agenda
•  UMA’s design center, progress, and status
•  A quick “UMA 101” primer
•  Measuring UMA against ACE use cases
•  ...
OAuth architecture
10
OAuth experience
11
Under the hood, UMA is “OAuth++”
Loosely coupled to enable
an AS to onboard multiple
RS’s, residing in any security
domain...
The RS
exposes
whatever
value-add API
it wants,
protected by
an AS
The RPT is the main
“access token” and (by
default – it...
The AS
exposes an
UMA-
standardized
protection
API to the RS
The PAT protects the
API and binds the RO,
RS, and AS
Protect...
The AS
exposes an
UMA-
standardized
authorization
API to the
client
The AAT protects the
API and binds the RqP,
client, an...
The AS can collect requesting party claims or
otherwise elevate trust to assess policy
A “claims-aware” client can
proacti...
The RO and RqP have opposite consent/
privacy relationships with the AS
17
How an individual user might experience
setting sharing preferences
18
demo!
Default burdens on apps
Resource server
•  Gets client creds from AS
•  Gets RO-specific access token
(PAT) from AS
•  Reg...
Profiling and extensibility enable
efficiencies and non-HTTP bindings
•  “Protection API extensibility profile” for AS-RS ...
Subject
or
UMA Binding Obligations
•  Distributed authorization across domains? Scary!
•  This “legal” spec enables partie...
Agenda
•  UMA’s design center, progress, and status
•  A quick “UMA 101” primer
•  Measuring UMA against ACE use cases
•  ...
Strong architectural matches
þ  Owner grants different resource
access rights to different parties
•  U1.1, U2.3, U.3.2, ...
Potential profiling/extension
opportunities
q Constrained device might not always be
able to reach the Internet
•  U1.9, ...
Potential user experience and
system configuration opportunities
q Spontaneous device provisioning
•  U2.1
q Spontaneous...
Apparent OOS challenges
q  Sensor data integrity
•  U1.2
q  Sensor data confidentiality
•  U1.2
q  Client-RS messages f...
Agenda
•  UMA’s design center, progress, and status
•  A quick “UMA 101” primer
•  Measuring UMA against ACE use cases
•  ...
Questions? Thank you!
Eve Maler, chair
@UMAWG | @xmlgrrl
13 January 2015
tinyurl.com/umawg
28
Nächste SlideShare
Wird geladen in …5
×

UMA for ACE

3.428 Aufrufe

Veröffentlicht am

UMA is a profile and application of OAuth that defines how resource owners can control resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. Recent investigations have shown promise for applying UMA to Internet of Things authorization use cases.

This is a presentation by Eve Maler for the IETF ACE working group.

Veröffentlicht in: Technologie
  • Link to Original Hannes T. webpost with link to recording of the exposition: http://www.tschofenig.priv.at/wp/?p=1057
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

UMA for ACE

  1. 1. User-Managed Access (UMA) in the ACE Context Eve Maler, chair @UMAWG | @xmlgrrl 13 January 2015 tinyurl.com/umawg 1
  2. 2. Agenda •  UMA’s design center, progress, and status •  A quick “UMA 101” primer •  Measuring UMA against ACE use cases •  Discussion and next steps 2
  3. 3. OpenID Connect UMA OAuth 2.0 The “new Venn” of web access control and consent
  4. 4. The marvelous spiral of controlled personal data/access sharing 4
  5. 5. Interoperable, RESTful authorization-as-a-service 5 Has standardized APIs for privacy and “selective sharing” Outsources protection to a centralizable authorization server “authz   provider”   (AzP)   “authz   relying   party”   (AzRP)   iden9ty   provider   (IdP)   SSO  relying   party   (RP)  
  6. 6. Use-case domains Health Financial Education Personal Government Media Behavioral Enterprise Web Mobile API IoT
  7. 7. Web/API identity and security specification progress in context 7 Protect   Serve   UMA  Core,  Resource  Set  Registra9on   OAuth  1.0,  1.0a   WRAP   OpenID  AB/Connect   Open   ID   OpenID  Connect   OAuth  2.0   ‘08 ‘09 ‘10 ‘11 ‘13 ‘12 ‘14 ‘15 Dynamic  Client  Reg,  Token   Introspec9on…   Binding   Obs…   5  Jan  ‘15:  45-­‐day  public   review  of  “V1.0   candidate”  specs  begun:   9nyurl.com/umacore  &   oauthrsr   Interop  test  suite   development   under  way  
  8. 8. Other major news items •  EIC award in Munich •  HEART WG at OpenID Foundation •  New open-source community: OpenUMA at ForgeRock.org 8
  9. 9. Agenda •  UMA’s design center, progress, and status •  A quick “UMA 101” primer •  Measuring UMA against ACE use cases •  Discussion and next steps 9
  10. 10. OAuth architecture 10
  11. 11. OAuth experience 11
  12. 12. Under the hood, UMA is “OAuth++” Loosely coupled to enable an AS to onboard multiple RS’s, residing in any security domains This concept is new, to enable asynchronous party-to-party sharing driven by RO policy vs. run-time consent
  13. 13. The RS exposes whatever value-add API it wants, protected by an AS The RPT is the main “access token” and (by default – it’s profilable) is associated with time-limited, scoped permissions App-specific API UMA-enabled client RPT requesting party token
  14. 14. The AS exposes an UMA- standardized protection API to the RS The PAT protects the API and binds the RO, RS, and AS ProtectionAPI Protectionclient PAT protection API token •  Resource registration endpoint •  Permission registration endpoint •  Token introspection endpoint
  15. 15. The AS exposes an UMA- standardized authorization API to the client The AAT protects the API and binds the RqP, client, and AS The client may be told: “need_info” Authorization API Authorization client AAT authorization API token •  RPT endpoint
  16. 16. The AS can collect requesting party claims or otherwise elevate trust to assess policy 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 access federation’s 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.
  17. 17. The RO and RqP have opposite consent/ privacy relationships with the AS 17
  18. 18. How an individual user might experience setting sharing preferences 18 demo!
  19. 19. Default burdens on apps Resource server •  Gets client creds from AS •  Gets RO-specific access token (PAT) from AS •  Registers protected resources at AS as required (PUT) •  Registers permissions at AS for unauthorized client access attempts (POST) •  Introspects clients’ RPTs at AS (GET) Client •  Learns AS location and endpoints •  Gets client creds from AS •  Gets RqP-specific access token (AAT) from AS •  Requests authz data from AS (POST) •  Pushes user claims (optional) or redirects user to AS 19 •  All REST •  All JSON on both request and response sides •  Endpoints all TLS- and OAuth-protected
  20. 20. Profiling and extensibility enable efficiencies and non-HTTP bindings •  “Protection API extensibility profile” for AS-RS interactions •  “Authorization API extensibility profile” for AS-client interactions •  “Resource interface extensibility profile” for resource server- client interactions –  E.g., to replace HTTP/TLS with CoAP/DTLS or co-locate entities •  RPT profiling –  E.g., to enable disconnected token introspection or AS “hunt list” •  JSON extensibility all over the place –  E.g., to enable general experimentation and escape hatches •  Claim token format profiling –  E.g., to enable a variety of deployment-specific trust frameworks 20
  21. 21. Subject or UMA Binding Obligations •  Distributed authorization across domains? Scary! •  This “legal” spec enables parties operating and using software entities (and devices) to distribute rights and obligations fairly in access federation trust frameworks 21 Individual! Non- person entity Authorizing Party Requesting Party Resource Server Operator Client Operator Requesting Party Agent Authorization Server Operator Important  state   changes  when  new   pairwise  obliga9ons   tend  to  appear:   •  Token  issuance   •  Token  status  checks   •  Permission   registra9on   •  Claims  gathering   •  Access  requests   •  Successful  access  
  22. 22. Agenda •  UMA’s design center, progress, and status •  A quick “UMA 101” primer •  Measuring UMA against ACE use cases •  Discussion and next steps 22
  23. 23. Strong architectural matches þ  Owner grants different resource access rights to different parties •  U1.1, U2.3, U.3.2, (U3.3) þ  Owner grants different access rights for different resources on a device (including read, write, admin) •  U1.3, U4.4, U5.2 þ  Owner not always present at time of access •  U1.6, U5.5 þ  Owner grants temporary access permissions to a party •  U1.7 þ  Owner applies verifiable context-based conditions to authorizations •  U2.4, U4.5, U6.3 þ  Owner grants temporary access permissions to a party •  U1.7 þ  Owner preconfigures access rights to specific data •  U3.1, U6.3 þ  Owner adds a new device under protection •  U4.1 þ  Owner puts a previously owned device under protection •  U4.2 þ  Owner removes a device from protection •  U4.3 þ  Owner preconfigures access rights to specific data •  U3.1 þ  Owner revokes permissions •  U4.6 þ  Owner grants access only to authentic, authorized clients •  U7.1, U7.2 23
  24. 24. Potential profiling/extension opportunities q Constrained device might not always be able to reach the Internet •  U1.9, U5.4, U6.5, U7.3 •  Or proxy/gateway approach q Impossible or inefficient to contact all affected devices directly when policies are updated •  U5.6 24
  25. 25. Potential user experience and system configuration opportunities q Spontaneous device provisioning •  U2.1 q Spontaneous/dynamic policy changes •  U2.2, U6.1 q Secure-by-default policies •  U2.6, U3.6 q Easy-to-edit policies •  U2.7, U2.9, U2.10, U3.6, U6.2 25
  26. 26. Apparent OOS challenges q  Sensor data integrity •  U1.2 q  Sensor data confidentiality •  U1.2 q  Client-RS messages forwarded over multiple hops? •  U1.8, U5.7 q  Smart home devices communicate with different control devices •  U2.5 q  Owner prevents eavesdroppers on home network •  U2.8 q  Prevent (all) DoS •  U3.7 q  High security to prevent owner fatalities •  U3.8 q  Multicast protocol? •  U4.8 q  Physical device security •  U5.1 q  Wired and wireless •  U7.4 q  Mitigate risk of financial damage •  U7.5 •  UMA Binding Obligations spec helps do this 26
  27. 27. Agenda •  UMA’s design center, progress, and status •  A quick “UMA 101” primer •  Measuring UMA against ACE use cases •  Discussion and next steps 27
  28. 28. Questions? Thank you! Eve Maler, chair @UMAWG | @xmlgrrl 13 January 2015 tinyurl.com/umawg 28

×