Complex architectures for authentication and authorization on AWS
1 like1,165 views
This document discusses complex architectures for authentication and authorization on AWS, focusing on microservices environments and the use of Amazon Cognito and OpenID Connect. It outlines various strategies for client-to-service, service-to-service, and infrastructure authentication, along with tips for implementing centralized and decentralized authorization techniques. The document emphasizes the importance of managing permissions effectively, optimizing performance, and automating credential management.
![RBAC Authorization
Primer
Service Service Service Service
Amazon Cognito
Internal Perimeter
SAML
OIDC
External Perimeter
{
"name": "John Doe",
"email": "john.doe@foo.com",
"roles": ["finance_controller"]
…
}
If role ==„finance_controller“...
X
Amazon API Gateway](https://image.slidesharecdn.com/awscommunitydayhamburg2019-190910215830/85/Complex-architectures-for-authentication-and-authorization-on-AWS-15-320.jpg)
![Delegate auth to a central auth service
User Service
POST /users
GET /users/<id>
PUT /users/<id>
DELETE /users/<id>
API Contract
Associated Permissions
users:create:any
users:read:any
users:read:own
users:update:any
users:update:own
users:delete:own
users:delete:any
{
"name": "John Doe",
"email": "john.doe @foo.com",
"roles": ["finance_controller"],
“user_id": 343242,
…
}
Auth
Service
GET /users/343242
finance_controller -> users:read:own
Role Permission
Authorised?](https://image.slidesharecdn.com/awscommunitydayhamburg2019-190910215830/85/Complex-architectures-for-authentication-and-authorization-on-AWS-17-320.jpg)
![Centralised Auth Service Optimisations: caching auth result
User Service
Auth
Service
Associated Permissions
users:create:any
users:read:any
users:read:own
users:update:any
users:update:all
users:delete:own
users:delete:any
{
"name": "John Doe",
"email": "john.doe @foo.com",
"roles": ["finance_controller"],
“user_id": 343242,
“jti“: 21312e1d123
…
}](https://image.slidesharecdn.com/awscommunitydayhamburg2019-190910215830/85/Complex-architectures-for-authentication-and-authorization-on-AWS-22-320.jpg)
![User Service
Auth
Service
1. Authorize operation
2. Cache authorization response
with TTL
Permissions and Cached Policy Result
users:create:any
users:read:any
21312e1d123 -> users:read:own
users:update:any
users:update:all
users:delete:own
users:delete:any
{
"name": "John Doe",
"email": "john.doe @foo.com",
"roles": ["finance_controller"],
“user_id": 343242,
“jti“: 21312e1d123
…
}
Centralised Auth Service Optimisations: caching auth result](https://image.slidesharecdn.com/awscommunitydayhamburg2019-190910215830/85/Complex-architectures-for-authentication-and-authorization-on-AWS-23-320.jpg)
![Bonus: Local token validation
User Service
Cache the access token JWK
for local validation
Amazon Cognito
{
"name": "John Doe",
"email": "john.doe @foo.com",
"roles": ["finance_controller"],
…
“kid": "5689example"
}
{
“keys": [{
“kid": "5689example",
“alg": "RS256"
}, {
…
}]}](https://image.slidesharecdn.com/awscommunitydayhamburg2019-190910215830/85/Complex-architectures-for-authentication-and-authorization-on-AWS-24-320.jpg)
Complex architectures for authentication and authorization on AWS
- 1. Complex architectures for authentication and authorization on AWS Boyan Dimitrov Director Platform Engineering @ Sixt @nathariel September 2019
- 2. Our Focus Today Service ? Authenticate & Authorize • Key patterns for authentication and authorization - Client to service - Service to service - Service to Infra • Focusing on the application and more complex microservices environments
- 3. Our Focus Today Service ? Authenticate & Authorize Service Service Autenticate & Authorize Service Service Service IdP Autenticate & Authorize
- 4. Before we begin: The Foundations OIDC ( OpenID Connect ) - a protocol for Authentication built on top of OAuth 2.0 OAUTH 2.0 – a protocol for Authorization
- 5. Before we begin: AWS Cognito AWS Cognito User Pools AWS Cognito Federated Identities Identity providers Social Identity Providers Other Identity Providers SAML OIDC S3 EC2 Federate AuthorizeFederate
- 6. Tip #1 If you are starting a new project on AWS involving auth and you need IdP, Use Cognito
- 7. Client to service auth
- 8. Auth primer Mobile Client Amazon API Gateway Custom Authorizer Amazon Cognito 1. Authenticate via credentials Service 2. Receive JWT 3. Invoke API with JWT 4. Validate JWT 6a. Check token scope 5. Return validity 6b. Invoke custom auth function Auth Service 7. Forward request
- 9. We live in a complex world… Amazon API Gateway Amazon Cognito Service Service Service Service Service Service Service Service Service On-Prem auth auth auth auth auth auth auth Elastic Load Balancer
- 10. • I already have a / multiple IdPs, how to integrate all of that ? • Where do we do authentication & token validation in a heterogeneous environment with various ingress points ? • How do we do authorization and on what level ? • What about service to service auth? • What about infrastructure auth ? Auth challenges in complex architectures
- 11. Tip #2 Consider IdP Federation to simplify your problem
- 12. Authentication: Common Identity Format Amazon Cognito Internal Perimeter SAML OIDC federate Standard Access Token External Perimeter Service Service Service Service Authenticate
- 13. Define your authorization strategy ACL MAC DAC RBAC ADAC PBAC …
- 14. Tip #3 If Authorization requirements are unclear, start with RBAC and complicate as needed ACL MAC DAC RBAC ADAC PBAC …
- 15. RBAC Authorization Primer Service Service Service Service Amazon Cognito Internal Perimeter SAML OIDC External Perimeter { "name": "John Doe", "email": "john.doe@foo.com", "roles": ["finance_controller"] … } If role ==„finance_controller“... X Amazon API Gateway
- 16. Tip #4 Do not embed volatile business roles into your applications – implement access controls around service capabilities instead
- 17. Delegate auth to a central auth service User Service POST /users GET /users/<id> PUT /users/<id> DELETE /users/<id> API Contract Associated Permissions users:create:any users:read:any users:read:own users:update:any users:update:own users:delete:own users:delete:any { "name": "John Doe", "email": "john.doe @foo.com", "roles": ["finance_controller"], “user_id": 343242, … } Auth Service GET /users/343242 finance_controller -> users:read:own Role Permission Authorised?
- 18. Centralised Auth Service User Service Auth Service Advantages • Externalised auth decisions and business roles management • Easier to manage and change • Single source of truth Disadvantages • Another synchronous dependency • Additional latency • Single point of failure? • Manual effort in keeping permissions up to date
- 19. Centralised Auth Service Optimisations: automate permission discovery User ServiceAuth Service Associated Permissions users:create:any users:read:any users:read:own users:update:any users:update:own users:delete:own users:delete:any Register permissions on startup Service:Permissions Map com.x.service.user users:create:any com.x.service.user users:read:any com.x.service.user users:read:own com.x.service.user users:update:any com.x.service.user users:update:own com.x.service.user users:delete:own com.x.service.user users:delete:any
- 20. Centralised Auth Service Optimisations: caching associated roles Associated Permissions users:create:any users:read:any users:read:own users:update:any users:update:own users:delete:own users:delete:any User ServiceAuth Service finance_controller -> com.x.service.user users:read:own Role Permission
- 21. Centralised Auth Service Optimisations: caching associated roles Associated Permissions and Roles users:create:any users:read:any finance_controller -> users:read:own users:update:any users:update:all users:delete:own users:delete:any finance_controller ALLOW com.x.service.user users:read:own Role Permission 1. On Startup user service caches relevant roles for its permissions 2. Receive live updates during runtime User ServiceAuth Service
- 22. Centralised Auth Service Optimisations: caching auth result User Service Auth Service Associated Permissions users:create:any users:read:any users:read:own users:update:any users:update:all users:delete:own users:delete:any { "name": "John Doe", "email": "john.doe @foo.com", "roles": ["finance_controller"], “user_id": 343242, “jti“: 21312e1d123 … }
- 23. User Service Auth Service 1. Authorize operation 2. Cache authorization response with TTL Permissions and Cached Policy Result users:create:any users:read:any 21312e1d123 -> users:read:own users:update:any users:update:all users:delete:own users:delete:any { "name": "John Doe", "email": "john.doe @foo.com", "roles": ["finance_controller"], “user_id": 343242, “jti“: 21312e1d123 … } Centralised Auth Service Optimisations: caching auth result
- 24. Bonus: Local token validation User Service Cache the access token JWK for local validation Amazon Cognito { "name": "John Doe", "email": "john.doe @foo.com", "roles": ["finance_controller"], … “kid": "5689example" } { “keys": [{ “kid": "5689example", “alg": "RS256" }, { … }]}
- 25. Authorization Service Service Service Service Amazon Cognito Internal Perimeter SAML OIDC External Perimeter Auth Service “Decentralised“ authorisation
- 26. Centralised Auth Service User Service Auth Service Advantages • Externalised auth decisions and business roles management • Easier to manage and change • Single source of truth • Decentralised token validation and auth Disadvantages • Another synchronous dependency • Additional latency • Single point of failure? • Manual effort in keeping permissions up to date
- 27. DEMO
- 28. Demo Architecture Auth Service Hello World Service Amazon Cognito User Pool Register a user & Authenticate Authorize hello request • Automated permission registration • Auth rules caching • Decentralised authorization • Local token validation Fetch IdP JWK Demo WebappAdmin Webapp Manage Permissions
- 29. So far we covered… Service ? Authenticate & Authorize Service Service Autenticate & Authorize Service Service Service IdP Autenticate & Authorize
- 30. Service 2 Service Auth
- 31. Why do we need S2S Auth? • Authorize service calls without user context ( batch jobs, async operations..) • Protect applications storing senstive information for internal actors too • Multi-tenant environments
- 32. Service to service auth User Service Amazon Cognito Email Service 1. Auth using creds { “service":“com.x.service.user, … } Auth Service com.x.service.user ALLOW com.x.service.email email:send:any Service Permission 2. Get an identitiy 3. Send identity token with requests
- 33. Tip #5 Give identity to your applications and automate the credential management!
- 34. Client 2 Service and Service 2 Service Auth Service Service Service Service Amazon Cognito Internal Perimeter SAML OIDC External Perimeter Auth Service S3 ?
- 35. (AWS) Infra Auth
- 36. Cognito Federated Identities to the rescue User Service Amazon Cognito User Pool Amazon Cognito Identity Federation 1. Get Identity Token 2. Exchange Token for IAM Creds 3. Access AWS Services
- 37. That’s all Service ? Authenticate & Authorize Service Service Autenticate & Authorize Service Service Service IdP Autenticate & Authorize
- 38. Thank you!