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

Complex architectures for authentication and authorization on AWS Boyan Dimitrov Director Platform Engineering @ Sixt @nathariel September 2019

Our Focus Today ? Authenticate • Key patterns for authentication & Authorize and authorization - Client to service - Service to service - Service to Infra • Focusing on the application and Service more complex microservices environments

? Our Focus Today Authenticate & Authorize Autenticate & Authorize Service Service Service IdP Autenticate Service & Authorize Service Service

Before we begin: The Foundations OIDC ( OpenID Connect ) - a protocol OAUTH 2.0 – for Authentication built on top of a protocol for Authorization OAuth 2.0

Before we begin: AWS Cognito Identity providers Social Identity Providers Federate Federate Authorize S3 Other Identity Providers AWS Cognito AWS Cognito User Pools Federated Identities SAML OIDC EC2

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 Auth Service Custom Authorizer 6b. Invoke custom auth function 6a. Check token scope 3. Invoke API with JWT Service 7. Forward request Amazon API Gateway 1. Authenticate via Mobile credentials 5. Return validity Client 4. Validate JWT 2. Receive JWT Amazon Cognito

We live in a complex world… Service Service Service auth auth Elastic Load Balancer On-Prem Service auth auth Service auth Service Amazon API Gateway auth Service Service auth Service Amazon Cognito

Auth challenges in complex architectures 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 ? •

Tip #2 Consider IdP Federation to simplify your problem

Authentication: Common Identity Format SAML OIDC Standard Access Token Authenticate federate External Perimeter Amazon Cognito Internal Perimeter Service Service Service Service

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 "name": "John Doe", "email": "john.doe@foo.com", Primer "roles": ["finance_controller"] … } SAML OIDC External Perimeter Amazon Cognito X Internal Perimeter Amazon API Gateway If role ==„finance_controller“... Service Service Service Service

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 API Contract { "name": "John Doe", POST /users "email": "john.doe @foo.com", GET /users/<id> "roles": ["finance_controller"], PUT /users/<id> “user_id": 343242, DELETE /users/<id> … } User Service Associated Permissions GET /users/343242 users:create:any users:read:any Authorised? users:read:own users:update:any users:update:own users:delete:own Role users:delete:any Permission Auth finance_controller -> users:read:own Service

Centralised Auth Service Advantages • Externalised auth decisions and business roles management • Easier to manage and change User Service • Single source of truth Disadvantages Another synchronous dependency • Auth • Additional latency Service • Single point of failure? • Manual effort in keeping permissions up to date

Centralised Auth Service Optimisations: automate permission discovery Service:Permissions Map Associated Permissions Register permissions on startup com.x.service.user users:create:any users:create:any com.x.service.user users:read:any users:read:any com.x.service.user users:read:own Auth users:read:own User Service com.x.service.user users:update:any Service users:update:any com.x.service.user users:update:own users:update:own com.x.service.user users:delete:own users:delete:own com.x.service.user users:delete:any users:delete:any

Centralised Auth Service Optimisations: caching associated roles Role Permission finance_controller -> com.x.service.user users:read:own Associated Permissions users:create:any users:read:any users:read:own Auth User Service users:update:any Service users:update:own users:delete:own users:delete:any

Centralised Auth Service Optimisations: caching associated roles Role Permission finance_controller ALLOW com.x.service.user users:read:own Associated Permissions and Roles users:create:any users:read:any finance_controller -> users:read:own Auth User Service users:update:any Service users:update:all users:delete:own 1. On Startup user service caches relevant users:delete:any roles for its permissions 2. Receive live updates during runtime

Centralised Auth Service Optimisations: caching auth result { "name": "John Doe", "email": "john.doe @foo.com", "roles": ["finance_controller"], Associated Permissions “user_id": 343242, “jti“: 21312e1d123 users:create:any … users:read:any } users:read:own users:update:any users:update:all User Service users:delete:own users:delete:any Auth Service

Centralised Auth Service Optimisations: caching auth result { "name": "John Doe", "email": "john.doe @foo.com", "roles": ["finance_controller"], Permissions and Cached Policy Result “user_id": 343242, “jti“: 21312e1d123 users:create:any … users:read:any } 21312e1d123 -> users:read:own users:update:any users:update:all User Service users:delete:own users:delete:any 1. Authorize operation 2. Cache authorization response with TTL Auth Service

Bonus: Local token validation { { "name": "John Doe", “keys": [{ "email": "john.doe @foo.com", “kid": "5689example", "roles": ["finance_controller"], “alg": "RS256" … }, { “kid": "5689example" … } }]} User Service Amazon Cognito Cache the access token JWK for local validation

Authorization SAML OIDC External Perimeter Amazon Cognito Internal Perimeter Auth Service “Decentralised“ authorisation Service Service Service Service

Centralised Auth Service Advantages • Externalised auth decisions and business roles management • Easier to manage and change • Single source of truth User Service • Decentralised token validation and auth Disadvantages Another synchronous dependency • Auth • Additional latency Service • Single point of failure? • Manual effort in keeping permissions up to date

DEMO

Demo Architecture Register a user & Authenticate Admin Webapp Demo Webapp Amazon Cognito User Pool Manage Permissions Authorize hello request Fetch IdP JWK Auth Service Hello World Service • Automated permission registration • Auth rules caching • Decentralised authorization • Local token validation

? So far we covered… Authenticate & Authorize Autenticate & Authorize Service Service Service IdP Autenticate Service & Authorize Service Service

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 Service Permission com.x.service.user ALLOW com.x.service.email email:send:any { “service":“com.x.service.user, Amazon Cognito … Auth Service } 1. Auth using creds 2. Get an identitiy User Service Email Service 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 SAML OIDC External Perimeter Amazon Cognito Internal Perimeter S3 ? Auth Service Service Service Service Service

(AWS) Infra Auth

Cognito Federated Identities to the rescue User Service Amazon Cognito 1. Get Identity 2. Exchange Amazon Cognito User Pool Token Token for Identity Federation IAM Creds 3. Access AWS Services

That’s all ? Authenticate & Authorize Autenticate Service & Authorize Service Service IdP Autenticate Service & Authorize Service Service

Thank you!