ASAPAtlassian S2S Authentication Protocol

Diego Berrueta - Razib ShahriarSydney Microservices Meetup - 24 Feb 2016

http://s2sauth.bitbucket.org/

Motivation

What problem are we trying to solve?

Service authentication today

Service C Service DHTTP(S) Basic Auth

(shared secret)

Service A Service BAnonymous HTTP

What options do we have to solve this?

○ Network security

○ HTTP Basic Auth (password)

○ Two way SSL / Client certificates

○ OAuth 1.0a / OAuth 2.0

○ OpenID / OpenID Connect

○ SAML

○ WS-Security & WS-* Family

○ Kerberos

○ Spotify’s CRTAUTH

○ Trusted Apps (deprecated)

○ Atlassian Connect JWT

Why write our own Protocol?

Why write our own protocol

● Simple use cases deserve simple protocols

○ Lightweight payload

○ Simple interactions

○ Less moving parts

● Shared secrets are difficult to distribute and

keep secret

● JSON Web Token (JWT) becoming the de facto

token standard

eyJraWQiOiI1IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwKImV4cCI6MTM1NzI1NTc4OCwKImF1ZCI6Imh0dHBzOlwvXC9zcC5leGFtcGxlLm9yZyIsCiJqdGkiOiJ0bVl2WVZVMng4THZONzJCNVFfRWFjSC5fNUEiLAoiYWNyIjoiMiIsCiJzdWIiOiJCcmlhbiJ9.SbPJIx_JSRM1wluioY0SvfykKWK_yK4LO0BKBiESHu0GUGwikgC8iPrv8qnVkIK1aljVMXcbgYnZixZJ5UOArg

<Assertion Version="2.0" IssueInstant="2013-01-03T23:34:38.546Z” ID="oPm.DxOqT3ZZi83IwuVr3x83xlr" xmlns="urn:oasis:names:tc:SAML:2.0:assertion” xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <Issuer>https://idp.example.com</Issuer> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/> <ds:Reference URI="#oPm.DxOqT3ZZi83IwuVr3x83xlr"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>8JT03jjlsqBgXhStxmDhs2zlCPsgMkMTC1lIK9g7e0o=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>SAXf8eCmTjuhV742blyvLvVumZJ+TqiG3eMsRDUQU8RnNSspZzNJ8MOUwffkT6kvAR3BXeVzob5p08jsb99UJQ==</ds:SignatureValue> </ds:Signature> <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">Brian</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData NotOnOrAfter="2013-01-03T23:39:38.552Z" Recipient="https://sp.example.org"/> </SubjectConfirmation> </Subject> <Conditions NotOnOrAfter="2013-01-03T23:39:38.552Z" NotBefore="2013-01-03T23:29:38.552Z"> <AudienceRestriction> <Audience>https://sp.example.org</Audience> </AudienceRestriction> </Conditions> <AuthnStatement AuthnInstant="2013-01-03T23:34:38.483Z" SessionIndex="oPm.DxOqT3ZZi83IwuVr3x83xlr"> <AuthnContext> <AuthnContextClassRef>2</AuthnContextClassRef> </AuthnContext> </AuthnStatement></Assertion>

JWT

SAML

More on JWT(RFC 7519)

JSON Web Token (JWT)

JWT is a compact & self-contained means of representing claims.

JWT is part of the JOSE family of specifications

○ JWS - Signature (RFC7515)

○ JWT - Token (RFC7519)

○ JWE - Encryption (RFC7516)

○ JWA - Algorithm (RFC7518)

○ JWK - Key (RFC7517)JSON

JWKJWEJWSJWA

JWT

JSON Web Token (JWT)

● JWT contains three parts separated by dots:

○ Header

○ Claims

○ Signature

{"alg": "RS256", "kid": "billing/key1"}.{"iss": "billing", "aud": "payment", "exp": 1424698839, "iat": 1424695239, “jti”: 38912}.[Signature]

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOjEyMzQ1Njc4OTAsIm5hbWUiOiJKb2huIERvZSIsImFkbWluIjp0cnVlfQ.eoaDVGTClRdfxUZXiPs3f8FmJDkDE_VCQFXqKxpLsts

● Header and claims are serialised to UTF-8 and then encoded as Base64url

● Signature is computed using JWA algorithm with the Base64url Header &

Claims as the input.

Introducingthe ASAP protocol

ASAP in one slide

Token-based Service Authentication with asymmetric cryptography

Token is self-issued by the Client○ Encoded as JSON Web Token (JWT) ○ Signed with client’s private key using JSON Web Signature (JWS)○ Included as part of the request

Resource Server verifies the Access Token using Client’s public key○ Public key lookup in from a web server (e.g. S3) ○ Bearer Token & Self-verifiable

Sequence diagram

{"alg": "RS256", "kid": "billing/key1"}.{"iss": "billing", "aud": "payment", "exp": 1424698839, "iat": 1424695239, "jti": "93871"}.[RS256 Signature]

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJiaWxsaW5nIiwiYXVkIjoiaG9yZGUiLCJleHAiOjE0MjQ2OTg4MzksImlhdCI6MTQyNDY5NTIzOSwianRpIjoiOTM4NzEifQ.eoaDVGTClRdfxUZXiPs3f8FmJDkDE_VCQFXqKxpLsts

I want to use it, ASAP!

Current Status

Current Status

Step by step

Set up a public key repository (e.g., S3 bucket)

Using ASAP as a client

1. Generate a RSA key pair

2. Upload the public key to the key repository

3. Generate the token, sign it and include it with the request (use the libraries!)

Using ASAP as a resource server

1. Add an authentication filter (use the libraries!)

2. Configure the location of the public key repository

Performance

Performance

Several factors may influence performance, common ones:

● Signing algorithm

● JVM Architecture

● Caching

● Security Software/Hardware

● Network, e.t.c.

Performance - Algorithms

ASAP supports the asymmetric subset of JWA algorithms (RFC7518)

Performance - Algorithms

Effect of signing algorithm on Throughput

Performance - JVM Architecture

Effect of JVM Architecture on Performance

Performance - Caching

Effect of Key Caching on Performance

Key management

Key management

● How many keys?○ Per client service○ Per service pair○ Per environment○ Per tenant

● Who generates the keys?

● How to publish the public keys?○ Manual upload○ Managed via platform○ Key discovery via callback

● How to rotate the keys?

● How to expire a compromised key?

● How to feed the private key to the client?○ Obvious advice: don’t check

private keys in version control or bundle them in deployables!

Lessons learned

Lessons learned

● Make sure your clocks are in sync

● AWS regions can fail

● Balance between security and convenience (e.g. error messages)

● Public key distribution can be hard

● HTTP caching is elegant and effective

Thank you!

http://s2sauth.bitbucket.org/

dberrueta@atlassian.commshahriar@atlassian.com