Date post: | 08-Jan-2017 |
Category: |
Technology |
Upload: | razib-shahriar |
View: | 230 times |
Download: | 0 times |
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