Complex architectures for authentication and authorization on AWS

Boyan DimitrovDirector Platform Engineering @ Sixt @natharielSeptember 2019

Our Focus Today

Service

?

Authenticate& Authorize

• Key patterns for authenticationand authorization

- Client to service- Service to service- Service to Infra

• Focusing on the application andmore complex microservicesenvironments

Our Focus Today

Service

?

Authenticate& Authorize

Service

Service

Autenticate& Authorize

Service

Service

Service

IdP

Autenticate& Authorize

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

Before we begin: AWS Cognito

AWS CognitoUser Pools

AWS CognitoFederated Identities

Identity providers

Social Identity Providers

Other Identity Providers

SAMLOIDC

S3

EC2

Federate

AuthorizeFederate

Tip #1If you are starting a new project on AWS involving auth and you need IdP, Use Cognito

Client to service auth

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 authfunction

Auth Service

7. Forward request

We live in a complex world…

Amazon API Gateway

Amazon Cognito

Service

Service

Service

Service

Service

Service Service

Service

Service

On-Premauth

auth

auth

auth

auth

auth

auth

Elastic Load Balancer

• 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

Tip #2Consider IdP Federation to simplify your problem

Authentication: Common Identity Format

Amazon Cognito

Internal Perimeter

SAMLOIDC

federate

StandardAccess Token

External Perimeter

Service Service Service Service

Authenticate

Define your authorization strategy

ACL MAC DAC RBAC ADAC PBAC …

Tip #3If Authorization requirements are unclear, start with RBAC and complicate as needed

ACL MAC DAC RBAC ADAC PBAC …

RBAC Authorization Primer

Service Service Service Service

Amazon Cognito

Internal Perimeter

SAMLOIDC

External Perimeter

{"name": "John Doe","email": "john.doe@foo.com","roles": ["finance_controller"]…}

If role ==„finance_controller“... XAmazon API Gateway

Tip #4Do not embed volatile business roles into your applications – implement access controls around service capabilities instead

Delegate auth to a central auth service

User Service

POST /usersGET /users/<id>PUT /users/<id>DELETE /users/<id>

API Contract

Associated Permissions

users:create:anyusers:read:anyusers:read:ownusers:update:anyusers:update:ownusers:delete:ownusers:delete:any

{"name": "John Doe","email": "john.doe @foo.com","roles": ["finance_controller"],“user_id": 343242,…}

AuthService

GET /users/343242

finance_controller -> users:read:own

Role Permission

Authorised?

Centralised Auth Service

User Service

AuthService

Advantages

• Externalised auth decisions andbusiness 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

Centralised Auth Service Optimisations: automate permissiondiscovery

User ServiceAuthService

Associated Permissions

users:create:anyusers:read:anyusers:read:ownusers:update:anyusers:update:ownusers:delete:ownusers:delete:any

Register permissions on startupService:Permissions Mapcom.x.service.user users:create:anycom.x.service.user users:read:anycom.x.service.user users:read:owncom.x.service.user users:update:anycom.x.service.user users:update:owncom.x.service.user users:delete:owncom.x.service.user users:delete:any

Centralised Auth Service Optimisations: caching associated roles

Associated Permissionsusers:create:anyusers:read:anyusers:read:ownusers:update:anyusers:update:ownusers:delete:ownusers:delete:any

User ServiceAuthService

finance_controller -> com.x.service.user users:read:own

Role Permission

Centralised Auth Service Optimisations: caching associated roles

Associated Permissions and Roles

users:create:anyusers:read:any

finance_controller -> users:read:ownusers:update:anyusers:update:allusers:delete:ownusers: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 ServiceAuthService

Centralised Auth Service Optimisations: caching auth result

User Service

AuthService

Associated Permissionsusers:create:anyusers:read:anyusers:read:ownusers:update:anyusers:update:allusers:delete:ownusers:delete:any

{"name": "John Doe","email": "john.doe @foo.com","roles": ["finance_controller"],“user_id": 343242,“jti“: 21312e1d123…}

User Service

AuthService

1. Authorize operation2. Cache authorization responsewith TTL

Permissions and Cached Policy Result

users:create:anyusers:read:any

21312e1d123 -> users:read:ownusers:update:anyusers:update:allusers:delete:ownusers: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

Bonus: Local token validation

User Service

Cache the access token JWKfor local validation

Amazon Cognito

{"name": "John Doe","email": "john.doe @foo.com","roles": ["finance_controller"],…“kid": "5689example"}

{“keys": [{

“kid": "5689example",“alg": "RS256"

}, {…}]}

Authorization

Service Service Service Service

Amazon Cognito

Internal Perimeter

SAMLOIDC

External Perimeter

Auth Service “Decentralised“ authorisation

Centralised Auth Service

User Service

AuthService

Advantages

• Externalised auth decisions andbusiness 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

DEMO

Demo Architecture

Auth Service Hello World Service

Amazon CognitoUser 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

So far we covered…

Service

?

Authenticate& Authorize

Service

Service

Autenticate& Authorize

Service

Service

Service

IdP

Autenticate& Authorize

Service 2 Service Auth

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

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 withrequests

Tip #5Give identity to your applications and automate the credential management!

Client 2 Service and Service 2 Service Auth

Service Service Service Service

Amazon Cognito

Internal Perimeter

SAMLOIDC

External Perimeter

Auth Service

S3

?

(AWS) Infra Auth

Cognito Federated Identities to the rescue

User ServiceAmazon Cognito

User Pool Amazon CognitoIdentity Federation

1. Get Identity Token

2. Exchange Token forIAM Creds

3. Access AWS Services

That’s all

Service

?

Authenticate& Authorize

Service

Service

Autenticate& Authorize

Service

Service

Service

IdP

Autenticate& Authorize

Thank you!