Successfully reported this slideshow.
Your SlideShare is downloading. ×

muCon 2016: Authentication in Microservice Systems By David Borsos

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 55 Ad

muCon 2016: Authentication in Microservice Systems By David Borsos

Download to read offline

Software security is hard. Software security in Microservice Systems is even harder. Microservice-style software architectures have steadily been gaining popularity in recent years. They offer many benefits over traditional monolithic software products, however they also introduce new challenges - one of these being security.

In recent years David has worked on this problem in several independent projects, and this talk will draw on his learnings within the topic of authenticating end-users. David will describe, compare and evaluate several authentication options from the perspective of how secure they are and how well they comply with the qualities of a well-designed microservice system. You will leave the talk with suggested evaluation criteria and guidance for implementation based on their use cases.

Software security is hard. Software security in Microservice Systems is even harder. Microservice-style software architectures have steadily been gaining popularity in recent years. They offer many benefits over traditional monolithic software products, however they also introduce new challenges - one of these being security.

In recent years David has worked on this problem in several independent projects, and this talk will draw on his learnings within the topic of authenticating end-users. David will describe, compare and evaluate several authentication options from the perspective of how secure they are and how well they comply with the qualities of a well-designed microservice system. You will leave the talk with suggested evaluation criteria and guidance for implementation based on their use cases.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to muCon 2016: Authentication in Microservice Systems By David Borsos (20)

More from OpenCredo (13)

Advertisement

Recently uploaded (20)

muCon 2016: Authentication in Microservice Systems By David Borsos

  1. 1. @davib0 Authentication in Microservice Systems David Borsos
  2. 2. @davib0 Authentication and Authorisation in Microservice Systems David Borsos
  3. 3. @davib0 Authentication and Authorisation in Microservice Systems David Borsos
  4. 4. @davib0 End-user Authentication and Authorisation in Microservice Systems David Borsos
  5. 5. @davib0 Introduction David Borsos Joined OpenCredo in 2013 Working on microservices since then Email: david.borsos@opencredo.com Twitter: @davib0 http://www.opencredo.com
  6. 6. @davib0 Why?
  7. 7. @davib0 Traditional “monolithic” architecture
  8. 8. @davib0 Traditional “monolithic” architecture
  9. 9. @davib0 Traditional “monolithic” architecture
  10. 10. @davib0 μServices!
  11. 11. @davib0 μServices! ● Composing functionality ● Self-contained services ● “Bounded context” ● Independent scaling ● Independent deployment ○ Containers ○ Schedulers ■ Kubernetes ■ Mesos + Marathon ○ PaaS(es) ■ CloudFoundry ● Localized failures ● Prefer statelessness ○ Don’t rely on HTTP Sessions
  12. 12. @davib0 μServices
  13. 13. @davib0 μServices - Let’s try the same pattern
  14. 14. @davib0 μServices - Let’s try the same pattern Problem #1 - shared user database
  15. 15. @davib0 μServices are distributed
  16. 16. @davib0 μServices Problem #1 - shared user database
  17. 17. @davib0 μServices Problem #1 - shared user database Solution #1 - distribute!
  18. 18. @davib0 μServices Problem #1 - shared user database Solution #1 - distribute! Problem #2 - who owns the credentials?
  19. 19. @davib0 Single Responsibility
  20. 20. @davib0 μServices Problem #1 - shared user database Solution #1 - distribute! Problem #2 - who owns the credentials?
  21. 21. @davib0 μServices Problem #1 - shared user database Solution #1 - distribute! Problem #2 - who owns the credentials? Solution #2 - Authentication Service
  22. 22. @davib0 μServices Problem #1 - shared user database Solution #1 - distribute! Problem #2 - who owns the credentials? Solution #2 - Authentication Service Problem #3 - switching services
  23. 23. @davib0 Authenticate every time?
  24. 24. @davib0 Obviously not
  25. 25. @davib0 Aiming for transparency vs.
  26. 26. @davib0 μServices - what do we want? ● “Secure” ○ Security is complex ○ Client-side ○ Sharing secrets? ● Stateless services ○ Multiple instances ● No single point of failure ○ On every request ○ When switching services ● No inherent bottlenecks ● Transparency ● Logout? ● Integration with μServices ● Simple to implement
  27. 27. @davib0 μServices 1. Use SSO solutions 2. Distributed session 3. Client-side token 4. Client-side token + API Gateway
  28. 28. @davib0 1. Using SSO
  29. 29. @davib0 Detour: how do these work?
  30. 30. @davib0 A common SSO pattern 1. User requests access 2. Not authenticated 3. User authenticates with SSO Server 4. Authentication successful, grant token 5. User uses token 6. Application uses token to get user details 7. Auth Server returns details +1 Auth server maintains “global login” +2 Application maintains “local login”
  31. 31. @davib0 Using SSO solutions ● SSO “login” state is usually opaque ● SSO Service becomes SPOF ● Chatty traffic ● Every switch potentially requires SSO ○ Optimise with local “login” caching
  32. 32. @davib0 Using SSO solutions Security As good as the chosen SSO ✔ Secret sharing No ✔ Statelessness Relies on HTTP sessions ✘ SPOF @ service switch Authentication server ✘ Bottlenecks Authentication server (switch only) ! Transparent Yes ✔ Logout Complex ✘ Technologies CAS, OAuth2* ✔ Integration Good library support ✔ Implementation Fairly high complexity ✘
  33. 33. @davib0 2. Distributed sessions
  34. 34. @davib0 Distributed sessions 1. User requests access 2. Not authenticated 3. User authenticates with Auth Service 4. Authentication successful a. Write state to distributed Session Store i. User X is logged in ii. Sets TTL b. Sets Session ID on client side 5. User uses Session ID 6. μService read distributed Session Store a. Refresh TTL
  35. 35. @davib0 Distributed sessions Security Opaque, rotatable Session ID ✔ Secret sharing Access to session store ✘ Statelessness Shared state ✔ SPOF @ service switch Session store* ! Bottlenecks Session store (every request) ✘ Transparent Yes ✔ Logout Trivial - delete shared session ✔ Technologies Redis, Cassandra, Hazelcast, Riak ✘ Integration Custom implementation ✘ Implementation Medium/High complexity !
  36. 36. @davib0 3. Client-side tokens
  37. 37. @davib0 3. “Poor man’s certificates”
  38. 38. @davib0 Client side tokens 1. User requests access 2. Not authenticated 3. User authenticates with Auth Server 4. Authentication successful a. Set ID token on the client side i. Self-contained ii. Signed iii. TTL 5. Services understand ID token a. Can parse user ID b. Can verify token i. Check signature ii. Check TTL
  39. 39. @davib0 Detour: JSON Web Tokens (JWT)
  40. 40. @davib0 JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzd WIiOiJteVVzZXJJZCIsIm5hbWUiOiJKb2huIERv ZSJ9.00q6RI76-oOyQIoshomTVIfmebQPGoDV 2znTErEJjjo Header { "alg": "HS256", "typ": "JWT" } Body { "sub": "myUserId", "name": "John Doe" } Signature
  41. 41. @davib0 JWT ● Standard ● Simple ● Extensible ● Can use a variety of signatures (SHA or RSA) ● Good library support ● Symmetric or Public/Private key signatures ● http://jwt.io
  42. 42. @davib0 Client side tokens 1. User requests access 2. Not authenticated 3. User authenticates with Auth Server 4. Authentication successful a. Set ID token on the client side i. Self-contained ii. Signed iii. TTL 5. Services understand ID token a. Can parse user ID b. Can verify token i. Check signature ii. Check TTL
  43. 43. @davib0 But...
  44. 44. @davib0 ...token is valid until TTL...
  45. 45. @davib0 ...and μServices accept it...
  46. 46. @davib0 … so, logout?
  47. 47. @davib0 Client-side tokens: Logout ● Remove token from client-side store ● Periodically check with Auth Service (“renew token”) ● CRL-style revocation ○ Maintain list of revoked tokens ○ Distribute list across μServices (messaging middleware) ● Use short-lived (15m) tokens
  48. 48. @davib0 Client-side tokens Security Potentially exposing User IDs ! Secret sharing Depends on signature algorithm ! Statelessness Completely stateless ✔ SPOF @ service switch None ✔ Bottlenecks None ✔ Transparent Yes ✔ Logout Complex* (for server-side) ! Technologies JWT, OpenID Connect ✔ Integration Good library support ✔ Implementation Simple ✔
  49. 49. @davib0 4. Client-side tokens + API Gateway
  50. 50. @davib0 Client-side tokens + API Gateway 1. User requests access 2. Not authenticated 3. User authenticates with Auth Server 4. Authentication successful a. Set ID token on the client side i. Self-contained ii. Signed iii. TTL 5. API Gateway translates to opaque token 6. API Gateway resolves to ID token 7. Services understand ID token a. Can parse user ID b. Can verify token i. Check signature ii. Check TTL
  51. 51. @davib0 API Gateways ● Proxying all user-facing communication ● Fairly simple ● Needs data store (for this use-case) ● Not a distributed session ○ μServices don’t interact with token store ○ μServices are not API Gateway-aware ● Logout ○ Revoke tokens in API Gateway’s token store
  52. 52. @davib0 Client-side tokens + API Gateway Security Opaque, rotatable Session ID ✔ Secret sharing Depends on signature algorithm ! Statelessness Some state held in API GW ! SPOF @ service switch None ✔ Bottlenecks API Gateway ! Transparent Yes ✔ Logout Trivial ✔ Technologies JWT, nginx, distributed DB, Kong ! Integration Good library support ✔ Implementation Fairly high complexity ✘
  53. 53. @davib0 Summary
  54. 54. @davib0 SSO Distributed Session JWT API GW Security ✔ ✔ ! ✔ Secret sharing ✔ ✘ ! ! Statelessness ✘ ✔ ✔ ! SPOF @ service switch ✘ ! ✔ ✔ Bottlenecks ! ✘ ✔ ! Transparent ✔ ✔ ✔ ✔ Logout ✘ ✔ ! ✔ Technologies ✔ ✘ ✔ ! Integration ✔ ✘ ✔ ✔ Implementation ✘ ! ✔ ✘
  55. 55. @davib0 Email: david.borsos@opencredo.com Twitter: @davib0 http://www.opencredo.com Questions?

×