Extending the Power of Consent with User-Managed Access & OpenUMA

2,100 views

Published on

At HIMSS 2015 Kantara Initiative will focus on the User Managed Access (UMA) initiative with a networking breakfast held on April 15th sponsored by ForgeRock and MedAllies. More information about HIMSS15 and registration.

Existing notice-and-consent paradigms of privacy have begun to fail dramatically — and as recent Pew surveys have demonstrated, people have begun to (ahem) notice. The discipline of privacy engineering aspires to “craft”, but finds it hard to break out the “compliance” rut. The User-Managed Access (UMA) standard and the OpenUMA open-source project are stepping into the breach with two essential elements that change the game: asynchronous consent and centralized consent management.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,100
On SlideShare
0
From Embeds
0
Number of Embeds
365
Actions
Shares
0
Downloads
64
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Extending the Power of Consent with User-Managed Access & OpenUMA

  1. 1. Extending the Power of Consent with User-Managed Access & OpenUMA FORGEROCK.COM Eve Maler VP Innovation & Emerging Technology eve.maler@forgerock.com @xmlgrrl April 15, 2015 Warren Strange Director, Sales Engineering warren.strange@forgerock.com
  2. 2. 2 ■  Provides strategic vision and real-world innovation for digital identity transformation ■  Connects business, governments, research, and education ■  Non-profit founded 2009 ■  Open and transparent ■  @KantaraNews to get involved
  3. 3. 3 ■  Offers the expertise and resources to help physicians with application and meaningful use of health information tech collection, secure transmission and reporting of critical clinical information
  4. 4. 4 Personal data sharing challenges
  5. 5. 5 Some apps are still in the Web 1.0 dark ages ■  Provisioning user data by hand ■  Provisioning it by value ■  Oversharing ■  Lying!
  6. 6. 6 Some other apps are still in the Web 2.0 dark ages ■  The “password anti-pattern” – a third party impersonates the user ■  It’s a honeypot for shared secrets ■  B2B partners are in the “gray market”
  7. 7. 7 Apps using OAuth and OpenID Connect hint at a better (if not perfect) way
  8. 8. 8 What about selective party-to-party sharing?
  9. 9. 9 Our choices: send a private URL… ■  Handy but insecure ■  Unsuitable for really sensitive data
  10. 10. 10 …or require impersonation…
  11. 11. 11 …or implement a proprietary access management system
  12. 12. 12 Killing – or even wounding – the password kills impersonation
  13. 13. 13 We have tough requirements for delegated authorization ■  Lightweight for developers ■  Robustly secure ■  Privacy-enhancing ■  Internet-scalable ■  Multi-party ■  Enables end-user convenience
  14. 14. 14 The solution space
  15. 15. 15 The new “Venn” of access control
  16. 16. 16 UMA in a nutshell ■  It’s a protocol for lightweight access control ■  It’s a profile and application of OAuth2 ■  It’s a set of authorization, privacy, and consent APIs ■  It’s a Kantara Initiative Work Group ■  It’s two V1.0 Recommendations (standards) ■  It’s not an “XACML killer” ■  Founder, chair, and “chief UMAnitarian”:
  17. 17. 17 JWT   UMA standardization in context 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   V1.0  completed;  interop   tes:ng  under  way;  trust   framework  efforts   beginning  
  18. 18. 18 UMA-enabled systems can respect policies such as… Only let my tax preparer with ID TP1234@gmail.com and using client app TaxThis access my bank account data if they have authenticated strongly, and not after tax season is over. Let my health aggregation app, my doctor’s office client app, and the client for my husband’s employer’s insurance plan get access to my wifi-enabled scale API and my fitness wearable API to read the results they generate. When a person driving a vehicle with an unknown ID comes into contact with my Solar Freakin’ Driveway, alert me and require my access approval.
  19. 19. 19 UMA brings Privacy by Design to loosely coupled services I want to share this stuff 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
  20. 20. 20 Subject or UMA Binding Obligations ■  Distributed authorization across domains? Scary! ■  This spec contains legalese so parties operating and using software entities (and devices) can distribute rights and obligations fairly ■  Trust frameworks = Access federations 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”
  21. 21. 21 HEART in a nutshell ■  It’s for patient-centric RESTful health data sharing ■  It’s international, but spurred by HHS ONC and VA ■  It’s primarily about “profiling the Venn” ■  It’s an OpenID Foundation Working Group ■  Its security profiles are interesting outside health ■  Its semantic profiles will be FHIR-specific ■  Co-chairs:
  22. 22. 22 Plan and “decision tree” for HEART profiles ■  Health project or not, A is probably valuable! ■  Using FHIR API? Then X (and, if C, then Y). ■  Need single sign-on? Then B. ■  Need strong client app authentication? Then probably B. ■  Users absent at resource access time? Then C. ■  Valuable to centralize API scope management? Then probably C. Security and interop Semantics
  23. 23. 23 What is OpenUMA?
  24. 24. 24 What about the user experience? Introducing the world-premiere demonstration of ForgeRock’s OpenUMA for RESTful patient-centric health data sharing use cases
  25. 25. 25 Dramatis personae ■  Individual ■  Graduate of Unseen University ■  (Nurse in real life) ■  New patient of Dr. Bob’s BlueHealth practice, with heart troubles ■  Doctor Alice Dr. Bob
  26. 26. 26 The identity and attribute perspective “The” user Unseen University’s identity and attribute provider BlueHealth’s portal that accepts UProtect logins and attributes as a relying party Alice Register, log in (federated), consent to sharing attributes HappyHeart’s app for viewing and managing ICD data that accepts UProtect logins as a relying party
  27. 27. 27 The data sharing perspective Alice Dr. Bob Alice These outsource protection to the UProtect AS These consume data/ access on behalf of requesting parties, as allowed by Aliceother clients
  28. 28. 28 About ForgeRock
  29. 29. 29 Identity as an enabler of business critical value and top-line revenue. Seamless experience across users, devices and “things.” Enables customer-focused services that extend reach to new, untapped populations. Your IRM foundation is what gives you an edge over competitors and enables rapid time to market. Identity Relationship Management
  30. 30. 30 COMMON API FOR ALL IDENTITY SERVICES Line of business 1 Line of business 2 Line of business 3 SINGLE CUSTOMER VIEW SINGLE CUSTOMER VIEW Identity Relationship Management Platform
  31. 31. 31 Products surrounding the “CREST API”
  32. 32. 32 ForgeRock IRM success…
  33. 33. Thank you! FORGEROCK.COM Eve Maler VP Innovation & Emerging Technology eve.maler@forgerock.com @xmlgrrl
  34. 34. 34 Appendix: Gory UMA details
  35. 35. 35 Authorization services architecture for low-scale environments Application (Requesting client) PEP (Policy Enforcement Point) PDP (Policy Decision Point) PAP (Policy Administration Point) Authorization Policies Request authorization Permit, Deny NotApplicable Indeterminate Centralized Policy Enforcement Receives Decision Monolithic   resource  owner   Enforcement   points  mediate   all  interac:ons   Decisions  are   fine-­‐grained  but   “cooked  down”   No  automated   mechanism  for   onboarding   partners   PIP (Policy Information Point)
  36. 36. 36 Why an OAuth-based architecture instead?
  37. 37. 37 “User-centric, constrained, delegated, RESTful WS- Security” J It’s about more than “eliminating the password anti-pattern” ■  Gets client apps out of the business of storing passwords ■  “Teaches” clients to rotate secrets ■  Friendly to authentication methods and user devices ■  Allows per-client tracking and revocation ■  Allows for scoped access ■  Captures user consent ■  Lowers development cost ■  Generative for a wider variety of design patterns
  38. 38. 38 Some interesting properties of this authorization services architecture that contribute to higher scale Application (Requesting client) Cloud/On-prem Authorization Server Policy Administration (Scope/Consent Administration Point) Resource Server Scopes Consents Authorization Server “Consent” to release Protect requested Scope Entitlements returned Tokens Consent Local entitlement enforcement Requesting party Resource Owner Attributes Entitlements Resource Server Resource Administration Registration Manage Consent Manage Resource  owner   is  prepared  to  be   an  individual   Decision  point   hands  out   en:tlements…   …directly  to   client  apps  
  39. 39. 39 UMA is about interoperable, RESTful authorization-as-a-service Has standardized APIs for privacy and “selective sharing” Outsources protection to a centralizable authorization server “authz provider” (AzP) “authz relying party” (AzRP) identity provider (IdP) SSO relying party (RP)
  40. 40. 40 Under the hood, it’s “OAuth++” Loosely coupled to enable an AS to onboard multiple RS’s, residing in any security domains This concept is new, to enable party-to-party sharing driven by RO policy vs. run-time consent
  41. 41. 41 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 The RPT is a tuple of these four entities; it may potentially span ROs because it’s centered on the RqP’s extent of authorization
  42. 42. 42 Comparing plain OAuth access tokens to UMA RPTs ■  OAuth access tokens: –  Profilable; no standardized form on the wire, though a signed JWT is sometimes used –  Token introspection at runtime is getting standardized; a JWT gets returned ■  UMA RPTs: –  Profilable; default form on the wire (“bearer”) is opaque and required to be introspected at runtime using the draft standard –  What’s returned is an enhanced JWT with a new “permissions” claim that binds scopes to named resource sets –  These are machine-readable, scope-grained, dynamic consent directives – entitlements – that an RS must act on
  43. 43. 43 The AS exposes an UMA-standardized protection API to the RS •  Resource registration endpoint •  Permission registration endpoint •  Token introspection endpoint The PAT (OAuth token) protects the API and binds the RO, RS, and AS
  44. 44. 44 The AS exposes an UMA-standardized authorization API to the client •  RPT endpoint The AAT (OAuth token) 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)
  45. 45. 45 These are embedded OAuth flows to protect UMA-standard security APIs ■  The “PAT” and “AAT” are our names for plain old OAuth tokens – representing important UMA concepts! –  Alice’s consent to federate authorization –  Bob’s consent to share claims to win access ■  Many “binding obligations” will hinge on their issuance
  46. 46. 46 The significance of resource set registration ■  The AS is authoritative for Alice’s policy ■  But the RS is authoritative for what its API can do – its “verbs” and “objects”, and what Alice has created there ■  Resource set registration allows the RS to remain authoritative in this fashion, and allows RS:AS to be an n:m relationship
  47. 47. 47 The AS can elevate requesting party 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. If the AAT was minted with too- weak authentication, the AS can request step-up for it as well
  48. 48. 48 The significance of trust elevation and claims gathering ■  Informing a requesting party that a resource is available for them to attempt to access (e.g. through email) is not a “magic entitlement” ■  This area of the UMA protocol has variability and requires profiling and ecosystem agreement ■  True “upstream” step-up authentication is possible, ensuring the entire chain is high-assurance
  49. 49. 49 Authorization services architecture for high-scale environments Application (Requesting client) Cloud/On-prem Authorization Server Policy Administration (Scope/Consent Administration Point) Resource Server Scopes Consents Authorization Server “Consent” to release Protect requested Scope Entitlements returned Tokens Consent Local entitlement enforcement Requesting party Resource Owner Attributes Entitlements Resource Server Resource Administration Registration Manage Consent Manage “Virtualized”   resource  owner   op:ons   Decision  point   hands  out   en:tlements…   …directly  to   client  apps   RS  is  authorita:ve  for   protected  objects  and   scopes  (verbs);  AS   maps  to  subjects  
  50. 50. 51 UMA enables business logic centralization, even for “classic” access management ■  Company X contracts with SaaS1.com ■  Employees SSO in from web or native app, passing in role/group attributes ■  Company X’s policies at SaaS1 govern what features users can access ■  Company Y does the same at SaaS1, etc. ■  Company X does the same at SaaS2, etc. ■  Company X runs an UMA AS ■  SaaS1’s UMA RS onboards to that AS and respects UMA tokens issued by it, containing entitlements based on Company X’s policies ■  Company X’s keeps central policies for SaaS1, SaaS2, etc. (authoritative “AzP” respected by each “AzRP”) ■  Company Y keeps central policies for SaaS1, SaaS2, etc. (a different authoritative “AzP” respected by each “AzRP”) Business SaaS SSO today: Central authz tomorrow:
  51. 51. 52 Appendix: IoT implications of UMA
  52. 52. 53 Analysis against ACE use cases: many strong matches þ  Owner grants different resource access rights to different parties •  U1.1, U2.3, U.3.2 þ  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
  53. 53. 54 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 RS-client interactions –  E.g., to replace HTTP/TLS with CoAP/DTLS ■  RPT profiling –  E.g., to enable disconnected token introspection ■  JSON extensibility all over the place –  E.g., to enable experimentation and escape hatches ■  Claim token format profiling –  E.g., to enable a variety of deployment-specific trust frameworks

×