Microservices Manchester: Authentication in Microservice Systems by David Borsos
-
Upload
opencredo -
Category
Technology
-
view
713 -
download
1
Transcript of Microservices Manchester: Authentication in Microservice Systems by David Borsos
Introduction
David Borsos
With OpenCredo since 2013
Working on microservices since then
Email: [email protected]
Twitter: @davib0
http://www.opencredo.com
μ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
μServicesProblem #1 - shared user databaseSolution #1 - distribute!
Problem #2 - who owns the credentials?
μServicesProblem #1 - shared user databaseSolution #1 - distribute!
Problem #2 - who owns the credentials?
μServicesProblem #1 - shared user databaseSolution #1 - distribute!
Problem #2 - who owns the credentials?Solution #2 - Authentication Service
μServicesProblem #1 - shared user databaseSolution #1 - distribute!
Problem #2 - who owns the credentials?Solution #2 - Authentication Service
Problem #3 - switching services
μServices - what do we want?● “Secure”
○ Security is complex (Nicki’s talk)
○ Client-side
○ Sharing secrets?
● Stateless services
○ Multiple instances
● No single point of failure
○ On every request
○ When switching services
● No inherent bottlenecks
● Transparent login
● Ability to log out
● Integration with μServices
● Simple to implement
μServices
1. Use SSO solutions
2. Distributed session
3. Client-side token
4. Client-side token + API Gateway
SSO mechanism1. 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 μServices maintain local “login”
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
Using SSO solutionsSecurity 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 ✘
Distributed sessions1. 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
Distributed sessionsSecurity 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 !
Client side tokens1. 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
JWTeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJteVVzZXJJZCIsIm5hbWUiOiJKb2huIERvZSJ9.00q6RI76-oOyQIoshomTVIfmebQPGoDV2znTErEJjjo
Header{ "alg": "HS256", "typ": "JWT"}
Body{ "sub": "myUserId", "name": "John Doe"}
Signature
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
Client side tokens1. 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
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
Client-side tokensSecurity 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 ✔
Client-side tokens + API Gateway1. 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
API Gateways
● Proxying all user-facing communication
● Fairly simple
● Needs data store
● 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
Client-side tokens + API GatewaySecurity 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 ✘
SSO Distributed Session JWT API GW
Security ✔ ✔ ! ✔
Secret sharing ✔ ✘ ! !
Statelessness ✘ ✔ ✔ !
SPOF @ service switch
✘ ! ✔ ✔
Bottlenecks ! ✘ ✔ !
Transparent ✔ ✔ ✔ ✔
Logout ✘ ✔ ! ✔
Technologies ✔ ✘ ✔ !
Integration ✔ ✘ ✔ ✔
Implementation ✘ ! ✔ ✘