Complex architectures for authentication and authorization on AWS - - PowerPoint PPT Presentation

Complex architectures for authentication and authorization

• n AWS

Boyan Dimitrov Director Platform Engineering @ Sixt @nathariel September 2019

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

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 Cognito User Pools AWS Cognito Federated Identities

Identity providers

Social Identity Providers Other Identity Providers

SAML OIDC S3 EC2

Federate Authorize Federate

Tip #1 If 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 auth

function 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-Prem

auth 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 #2 Consider IdP Federation to simplify your problem

Authentication: Common Identity Format

Amazon Cognito

Internal Perimeter

SAML OIDC federate Standard Access Token

External Perimeter

Service Service Service Service

Authenticate

Define your authorization strategy

ACL MAC DAC RBAC ADAC PBAC …

Tip #3 If 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

SAML OIDC

External Perimeter

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

If role ==„finance_controller“...

X

Amazon API Gateway

Tip #4 Do 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 /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?

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

Centralised Auth Service Optimisations: automate permission discovery

User Service Auth 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

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 Service Auth Service

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

Role Permission

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 Service Auth Service

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 … }

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

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" }, { … }]}

Authorization

Service Service Service Service Amazon Cognito

Internal Perimeter

SAML OIDC

External Perimeter

Auth Service

“Decentralised“ authorisation

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

DEMO

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 Webapp Admin 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 with

requests

Tip #5 Give 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

SAML OIDC

External Perimeter

Auth Service

S3

?

(AWS) Infra Auth

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

That’s all

Service ?

Authenticate & Authorize

Service Service

Autenticate & Authorize

Service Service Service

IdP

Autenticate & Authorize

Thank you!