Auth in the extended enterprise - Keynote for MIT Legal Hack A Thon 2013

4,417 views
4,381 views

Published on

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

No Downloads
Views
Total views
4,417
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
80
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Auth in the extended enterprise - Keynote for MIT Legal Hack A Thon 2013

  1. 1. Justin Richer, The MITRE Corporation January 2013Approved for Public Release;Distribution Unlimited. 13-0239©2013 The MITRE Corporation
  2. 2. }  OAuth2 }  OpenID Connect }  MITREid Connect open source project }  Trust Frameworks©2013 The MITRE Corporation 2
  3. 3. Delegated Authorization©2013 The MITRE Corporation
  4. 4. ©2013 The MITRE Corporation 4
  5. 5. ©2013 The MITRE Corporation
  6. 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. 7. Refresh Token (Lets client ask for Resource Owner access tokens (Controls stuff) User Agent without bugging the (Web browser) user again) Access TokenClient Protected (Lets client(Wants stuff) Resource Authorization Server get stuff) (Has stuff) (Issues tokens) ©2013 The MITRE Corporation 7
  8. 8. ©2013 The MITRE Corporation 8
  9. 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. 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. 11. The most common OAuth2 Pattern©2013 The MITRE Corporation
  12. 12. Resource Owner & User Agent Authorization Server Client Protected Resource©2013 The MITRE Corporation 12
  13. 13. UA AS C PR©2013 The MITRE Corporation 13
  14. 14. UA AS C PR©2013 The MITRE Corporation 14
  15. 15. UA AS C PR©2013 The MITRE Corporation 15
  16. 16. UA AS C PR©2013 The MITRE Corporation 16
  17. 17. UA AS C PR©2013 The MITRE Corporation 17
  18. 18. UA AS C PR©2013 The MITRE Corporation 18
  19. 19. UA AS C PR©2013 The MITRE Corporation 19
  20. 20. UA AS C PR©2013 The MITRE Corporation 20
  21. 21. UA AS C PR©2013 The MITRE Corporation 21
  22. 22. UA AS C PR©2013 The MITRE Corporation 22
  23. 23. UA AS C PR©2013 The MITRE Corporation 23
  24. 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. 25. ©2013 The MITRE Corporation
  26. 26. No, it isn’t.©2013 The MITRE Corporation
  27. 27. No, it REALLY isn’t.©2013 The MITRE Corporation
  28. 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. 29. }  Delicious on its own }  Versatile ingredient ◦  Useful in many circumstances }  Can be used to make fudge©2013 The MITRE Corporation 29
  30. 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. 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. 32. ©2013 The MITRE Corporation
  33. 33. Why hasn’t anyone done that?©2013 The MITRE Corporation
  34. 34. Distributed identity at internet scale©2013 The MITRE Corporation
  35. 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. 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. 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. 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. 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. 40. ©2013 The MITRE Corporation
  41. 41. 41
  42. 42. 42
  43. 43. 43
  44. 44. https://github.com/mitreid-connect©2013 The MITRE Corporation
  45. 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. 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. 47. ©2013  The  MITRE  Corpora3on   47  
  48. 48. ©2013  The  MITRE  Corpora3on  
  49. 49. ©2013  The  MITRE  Corpora3on  
  50. 50. ©2013  The  MITRE  Corpora3on  
  51. 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. 52. Please join us!©2013 The MITRE Corporation
  53. 53. ©2013 The MITRE Corporation
  54. 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. 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. 56. It’s good for you!©2013 The MITRE Corporation
  57. 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. 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. 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. 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. 61. What security folks say to do What users actually do©2013 The MITRE Corporation 61
  62. 62. - Eve Maler©2013 The MITRE Corporation
  63. 63. ©2013 The MITRE Corporation
  64. 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. 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. 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. 67. Justin Richer jricher@mitre.org©2013 The MITRE Corporation
  68. 68. Here there be dragons©2013 The MITRE Corporation
  69. 69. ©2013 The MITRE Corporation
  70. 70. UA AS C PR©2013 The MITRE Corporation 70
  71. 71. UA AS C PR©2013 The MITRE Corporation 71
  72. 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. 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. 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. 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. 76. UA AS ? C PR1 PR2©2013 The MITRE Corporation 76
  77. 77. UA AS C PR1 PR2©2013 The MITRE Corporation 77
  78. 78. UA AS C PR1 PR2©2013 The MITRE Corporation 78
  79. 79. UA AS C PR1 PR2©2013 The MITRE Corporation 79

×