In this talk we discuss key architecture patterns for designing authentication and authorization solutions in complex microservices environments. We focus on the key advantages and capabilities of AWS Cognito User Pools and Federated Identities and explore how this service can address the challenges of implementing client to service, service to service and service to infrastructure auth. In addition, we discuss patterns and best practices around building a highly available and resilient decentralised authorization solution in a microservices environment based on fine-grained permissions and end to end automation.

1. Complex architectures for
authentication and
authorization on AWS
Boyan Dimitrov
Director Platform Engineering @ Sixt @nathariel
July 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
IDM
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
AWS Cloud
S3
EC2
Federate
AuthorizeFederate

6. Tip #1If 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. Auth challenges in complex architectures
• I already 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 ?

11. Tip #2Consider 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

15. Authorization
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:all
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
• Externalied 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:all
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:all
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:all
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. So far we covered…
Service
?
Authenticate
& Authorize
Service
Service
Autenticate
& Authorize
Service
Service
Service
IDP
Autenticate
& Authorize

28. Service 2 Service Auth

29. Tip #5
Give identity to your applications

30. 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

31. Authorization
Service Service Service Service
Amazon Cognito
Internal Perimeter
SAML
OIDC
External Perimeter
Auth Service
S3
?

32. (AWS) Infra Auth

33. 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

34. That’s all
Service
?
Authenticate
& Authorize
Service
Service
Autenticate
& Authorize
Service
Service
Service
IDP
Autenticate
& Authorize

35. Thank you!