Auth in the extended enterprise - Keynote for MIT Legal Hack A Thon 2013 (original) (raw)

• 1. Justin Richer, The MITRE Corporation January 2013 Approved for Public Release; Distribution Unlimited. 13-0239 ©2013 The MITRE Corporation

• 2. } OAuth2 } OpenID Connect } MITREid Connect open source project } Trust Frameworks ©2013 The MITRE Corporation 2

• 3. Delegated Authorization ©2013 The MITRE Corporation

• 4. ©2013 The MITRE Corporation 4

• 5. ©2013 The MITRE Corporation

• 6. } Authorization protocol framework } Built on deployment experience with OAuth 1, SAML, OpenID, and others } IETF Standard (as of 10/2012) ◦ RFC6749, RFC6750 } Built for HTTP APIs } Mobile friendly } REST-friendly ◦ Not RESTful itself ©2013 The MITRE Corporation 6

• 7. Refresh Token (Lets client ask for Resource Owner access tokens (Controls stuff) User Agent without bugging the (Web browser) user again) Access Token Client Protected (Lets client (Wants stuff) Resource Authorization Server get stuff) (Has stuff) (Issues tokens) ©2013 The MITRE Corporation 7

• 8. ©2013 The MITRE Corporation 8

• 9. } Authorization Code ◦ Very secure ◦ Most common ◦ Good for web server and native apps } Implicit ◦ Good for apps inside the browser } Client Credentials ◦ When there’s no user involved } Resource Owner Credentials ◦ Bootstrap username/password systems ©2013 The MITRE Corporation 9

• 10. } Refresh token ◦ Get more access tokens without bothering the user } Assertion ◦ Extension ◦ Uses structured tokens: JWT, SAML } Chain/redelegation ◦ Extension ◦ Trade one access token for another ©2013 The MITRE Corporation 10

• 11. The most common OAuth2 Pattern ©2013 The MITRE Corporation

• 12. Resource Owner & User Agent Authorization Server Client Protected Resource ©2013 The MITRE Corporation 12

• 13. UA AS C PR ©2013 The MITRE Corporation 13

• 14. UA AS C PR ©2013 The MITRE Corporation 14

• 15. UA AS C PR ©2013 The MITRE Corporation 15

• 16. UA AS C PR ©2013 The MITRE Corporation 16

• 17. UA AS C PR ©2013 The MITRE Corporation 17

• 18. UA AS C PR ©2013 The MITRE Corporation 18

• 19. UA AS C PR ©2013 The MITRE Corporation 19

• 20. UA AS C PR ©2013 The MITRE Corporation 20

• 21. UA AS C PR ©2013 The MITRE Corporation 21

• 22. UA AS C PR ©2013 The MITRE Corporation 22

• 23. UA AS C PR ©2013 The MITRE Corporation 23

• 24. } Avoiding password proliferation ◦ User’s credentials never go to the client } API protection ◦ Hundreds of thousands of sites, projects, and systems … and growing } Mobile access to server systems } Authentication (sign-on) protocols ◦ Facebook Connect, Log In With Twitter, etc. ©2013 The MITRE Corporation 24

• 25. ©2013 The MITRE Corporation

• 26. No, it isn’t. ©2013 The MITRE Corporation

• 27. No, it REALLY isn’t. ©2013 The MITRE Corporation

• 28. Chocolate Fudge Metaphor from: http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx ©2013 The MITRE Corporation 28

• 29. } Delicious on its own } Versatile ingredient ◦ Useful in many circumstances } Can be used to make fudge ©2013 The MITRE Corporation 29

• 30. } A confection with several ingredients } Can be made with chocolate ◦ But needs more than just chocolate ◦ Could be made without chocolate ©2013 The MITRE Corporation 30

• 31. } Create an identity API, protect it with OAuth ◦ Authorization Server becomes Identity Provider ◦ Client becomes Relying Party } Standardized user profiles ◦ Name, email, picture, etc. } Session management ◦ Is the user still logged in? ◦ Log out } Step up to high levels of authentication } Keep compatibility with basic OAuth2 ©2013 The MITRE Corporation 31

• 32. ©2013 The MITRE Corporation

• 33. Why hasn’t anyone done that? ©2013 The MITRE Corporation

• 34. Distributed identity at internet scale ©2013 The MITRE Corporation

• 35. } OpenID Connect (OIDC) is built on experience with OpenID 2, OAuth, SAML, Facebook Connect, etc. } Developed by the OpenID Foundation ◦ http://openid.net/connect ©2013 The MITRE Corporation 35

• 36. } OAuth 2 authorization ◦ Authorization Server becomes Identity Provider ◦ Client becomes Relying Party } JSON Web Tokens ◦ Structured token format } Can work in fully-distributed mode ◦ Dynamic discovery and registration ◦ Self-issued identities } “Make the simple things simple, make the difficult things possible.” ©2013 The MITRE Corporation 36

• 37. } Use OAuth2 to get a regular access token, as well as an ID token } Use access token to call User Info Endpoint ◦ Standardized user profile ◦ Standardized scopes } Parse and use ID token to manage current session and user information ©2013 The MITRE Corporation 37

• 38. } Higher levels of assurance ◦ Signed and encrypted requests ◦ Signed and encrypted responses } Fine-grained claims management } Distributed and aggregated claims } Self-issued identities } IdP-initiated login ◦ Kicks off the standard flow “remotely” } Can get very complex if you want it to ◦ “SAML with curly braces” ©2013 The MITRE Corporation 38

• 39. } OAuth 2 in the wild } Real-life interoperability testing } Real deployments, large and small } Generalization of protocols ◦ OIDC Discovery -> Webfinger ◦ OIDC Registration -> OAuth 2 Dynamic Client Registration ◦ JWT Claims – Subject, audience, authorized presenter ©2013 The MITRE Corporation 39

• 40. ©2013 The MITRE Corporation

• 41. 41

• 42. 42

• 43. 43

• 44. https://github.com/mitreid-connect ©2013 The MITRE Corporation

• 45. } Server and client built on Spring Security } Supports key features: ◦ Signed tokens ◦ Request objects ◦ Authorization code and implicit flows } Interoperability testing with working group ◦ Nomura Research Institute (PHP client) ◦ OIDC-PHP (PHP Client) ◦ IBM (Java client) ◦ Nov Matake (Ruby client and server) ◦ OIDC test suite (Python) ◦ … and others ©2013 The MITRE Corporation 45

• 46. } Enterprise-friendly platform (Java Spring) } Administration consoles } Programmable API } Modern UI } Event and action logging } General-purpose OAuth 2.0 service ◦ Support the wider MITRE Partnership Network effort ◦ More than just single-sign-on ©2013 The MITRE Corporation 46

• 47. ©2013 The MITRE Corpora3on 47

• 48. ©2013 The MITRE Corpora3on

• 49. ©2013 The MITRE Corpora3on

• 50. ©2013 The MITRE Corpora3on

• 51. Per-server overlays Server A Server B … (not public) MITREid Connect Hosted on GitHub Open Source Project SECOAUTH Open Source, owned by VMWare Spring Spring Security Java ©2013 The MITRE Corporation 51

• 52. Please join us! ©2013 The MITRE Corporation

• 53. ©2013 The MITRE Corporation

• 54. } A legally binding document signed by affected parties } Dictates the rules in three dimensions ◦ Business, Legal, and Technical } Core to National Strategy for Trusted Identities in Cyberspace (NSTIC) ◦ Identity Ecosystem ©2013 The MITRE Corporation 54

• 55. } Technology is only part of the problem } Distributed work is commonplace ◦ Policies and guidance haven’t kept up ◦ What defines the “normal” case? ◦ How do you handle the exceptional cases? } Built on whitelist/blacklist/graylist construct ◦ Explicitly allow for interactions that haven’t been previously vetted } Technology centered around OpenID ◦ Support for 2.0 based on FICAM profile ◦ Support for Connect based on draft standard ©2013 The MITRE Corporation 55

• 56. It’s good for you! ©2013 The MITRE Corporation

• 57. } First time through, ask: ◦ “You’ve never allowed this before. This is what I can say about them, is that OK?” } Subsequent times through: ◦ “I’m reasonably sure this is the same thing that you’ve said OK to before, let it through” ©2013 The MITRE Corporation 57

• 58. Whitelist Trusted partners, business contracts, customer organizations, trust frameworks Graylist User-based trust decisions Follow TOFU model, keep logs Blacklist Very bad sites we don’t want to deal with, ever ©2013 The MITRE Corporation 58

• 59. Whitelist Trusted partners, business contracts, customer organizations, trust frameworks Organizations decide these decide these End-users Graylist User-based trust decisions Follow TOFU model, keep logs Blacklist Very bad sites we don’t want to deal with, ever ©2013 The MITRE Corporation 59

• 60. } Security must be usable by regular people } We need multiple models, together ◦ It’s a continuum } Let organizations decide: ◦ What organizations/sites to trust automatically ◦ Who to sue if something goes wrong ◦ Who to block completely } Let users decide: ◦ If they trust things the organization is silent about ◦ (It’s easy to forget about this one) ©2013 The MITRE Corporation 60

• 61. What security folks say to do What users actually do ©2013 The MITRE Corporation 61

• 62. - Eve Maler ©2013 The MITRE Corporation

• 63. ©2013 The MITRE Corporation

• 64. } It’s a real live IETF standard (family) ◦ RFC6749, RFC6750 } Many, many web APIs use it ◦ Many more on the way } Extensions to core OAuth functionality helping it find use in new places ◦ Replacing old-style SOA authorization systems ©2013 The MITRE Corporation 64

• 65. } Cracking open enterprise identity ◦ Federation over direct authentication ◦ Derived credentials over primary credentials } Large scale internet identity platforms ◦ Google fully behind it ◦ Implementations from Ebay, IBM, Microsoft, others } Implementer’s draft available now ©2013 The MITRE Corporation 65

• 66. } Security MUST be usable by “normal people” } People will find way around things they perceive to get in their way ◦ Even if it’s “good for them” ©2013 The MITRE Corporation 66

• 67. Justin Richer jricher@mitre.org ©2013 The MITRE Corporation

• 68. Here there be dragons ©2013 The MITRE Corporation

• 69. ©2013 The MITRE Corporation

• 70. UA AS C PR ©2013 The MITRE Corporation 70

• 71. UA AS C PR ©2013 The MITRE Corporation 71

• 72. } OAuth doesn’t define what goes into the token string itself } Define a parseable format for moving data within the token: JSON Web Tokens (JWT) ◦ http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06 } Clients and protected resources can verify the token through signatures (JOSE) ◦ http://datatracker.ietf.org/wg/jose/ ©2013 The MITRE Corporation 72

• 73. {"iss":"joe", {"typ":"JWT", "alg":"HS256"} + "exp":1300819380, "http://example.com/is\_root":true} + (signature) = eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ 9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA 4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlL mNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CV P-mB92K27uhbUJU1p1r_wW1gFWFOEjXk ©2013 The MITRE Corporation 73

• 74. } Unstructured or opaque tokens ◦ “I have a token, what is it good for?” } Token in, JSON out } http://tools.ietf.org/html/draft-richer-oauth-introspection-01 { "valid": true, "client_id":"s6BhdRkqt3", "scope": ["read", "write", "dolphin"], "subject": "2309fj32kl", "audience": "http://example.org/protected-resource/\*" } ©2013 The MITRE Corporation 74

• 75. http://tools.ietf.org/html/draft-richer-oauth-chain-00 http://tools.ietf.org/html/draft-hunt-oauth-chain-01 ©2013 The MITRE Corporation

• 76. UA AS ? C PR1 PR2 ©2013 The MITRE Corporation 76

• 77. UA AS C PR1 PR2 ©2013 The MITRE Corporation 77

• 78. UA AS C PR1 PR2 ©2013 The MITRE Corporation 78

• 79. UA AS C PR1 PR2 ©2013 The MITRE Corporation 79