Trust Elevation: Implementing an OAuth2 Infrastructure using OpenID Connect & UMA


Published on

Increased trust in an online identity = increased mitigation of the risk of fraud. As an enterprise interacts with a person via the Internet, it may be prudent, for certain transactions, to have more evidence of that person’s identity. Web Access Management systems include some proprietary features to force “stepped-up authentication.” But luckily, new OAuth2 profiles like UMA and OpenID Connect offer a standards based approach to achieve inter-domain trust elevation. This slideshows includes a high level overview of the Enterprise UMA use case and some of the useful OpenID Connect features that can be leveraged to create centralized authentication policies.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Trust Elevation: Implementing an OAuth2 Infrastructure using OpenID Connect & UMA

  1. 1. Trust Elevation Implementing an OAuth 2.0 Infrastructure using the OpenID Connect & UMA profiles By: Michael Schwartz
  2. 2. What is trust elevation? “Trust Elevation methods increase the mitigation of risk of false assertion of identity in order to allow the subject to engage in a transaction.” OASIS Trust-EL TC Authentication Step-Up Protocol and Metadata Version 1.0-Draft 3
  3. 3. Don’t use 2FA, unless you have to... “Civilization advances by extending the number of important operations which we can perform without thinking about them.” Albert North Whitehead English Mathematician and Philosopher (1861 - 1947)
  4. 4. Authentication Involves Tradeoffs
  5. 5. Agenda 1. What tools do we have for person identification? 2. OAuth2 for trust elevation? 3. Inter-domain trust elevation? 4. New challenges!
  6. 6. Who am I: Founded & Sold ISP: ‘95-’99 IAM Integrator: ‘98-’09 Founder / CEO Gluu: ‘09 - Present Dad, hacker, pigeon enthusiast
  7. 7. Part I: Identification electron → meat correlation… How do we know who is on the other side of that digital transaction?
  8. 8. Cognitive Something you know or something your browser saved.
  9. 9. Biometric Something you are or… something you can’t change.
  10. 10. Token Something you have.
  11. 11. Mobile Some device you control.
  12. 12. Smart Card Something you probably don’t have a reader for...
  13. 13. Wearables / NFC Something you have on.
  14. 14. FIDO: Second Factor Experience Some U2F device that you have.
  15. 15. FIDO: Passwordless Experience Some UAF that device you have.
  16. 16. Context and Behavior Some way you use your phone or browser.
  17. 17. Risk Scores Some big-data footprint you’re not even aware of..
  18. 18. Contextual Combinations Complicate Relative Scale ● Is the IP address a known hacker? ● Was the device rooted? ● Is a browser cookie present? ● Is the device running virus protection? ● Is the location recognized? ● When was credential issued? ● What is the time of day?
  19. 19. According to Microsoft research (page 11), every authentication scheme does worse than passwords on deployability. Pick your poison:
  20. 20. Part II: OAuth2 How do apps use all these crazy authentication methods? ● Deployability = cost ● Less Cost = consolidation ● No “one-offs”!
  21. 21. A brief history in Web Authentication Standards
  22. 22. Developers want JSON REST API’s for authentication.
  23. 23. OpenID Connect Only one protected endpoint: “user_info” which returns id_token
  24. 24. UMA The requesting party must provide a valid RPT Token to the resource server.
  25. 25. How does the app know what kind of authn happened?
  26. 26. id_token User claims + info about authentication event
  27. 27. OpenID Provider Discovery GET host + /.well-known/openid-configuration
  28. 28. OpenID Dynamic Client Registration
  29. 29. Authentication Request That is a space delimited string
  30. 30. Scope based Not ABAC policies!
  31. 31. Best Practice: Centralize Policy Management
  32. 32. UMA provides the PDP
  33. 33. What kind of policies can you make?
  34. 34. Return Hint... You are Forbidden because you need acr...
  35. 35. Part III Federations for inter-domain trust
  36. 36. EDURoam for wifi
  37. 37. SAML Federations Normalize legal and technical details for trust.
  38. 38. SAML Federation Metadata
  39. 39. Many SAML Federations publish user schema
  40. 40. Domains need to collaborate on the values for acr’s and amr’s
  41. 41. So what values should we use for amr and acr?
  42. 42. SAML Federations Identity Providers and Websites (SP)
  43. 43. OAuth2 has new entities and new jargon
  44. 44. OAuth2 Schema, not just attributes
  45. 45. Open Trust Taxonomy for OAuth2 (OTTO) Enter...
  46. 46. Where do we need federations?
  47. 47. Part IV: New Challenges
  48. 48. Who’s that knocking at my door?
  49. 49. IOT Challenges
  50. 50. New Services like Data Federation Not “can you access?” But “what can you access?”
  51. 51. Summary
  52. 52. Questions? @GluuFederation