Many companies are adopting micro-services architectures to promote decoupling and separation of concerns in their applications. One inherent challenge with breaking applications up into small services is that now each service needs to deal with authenticating and authorizing requests made to it. We present a clean way to solve this problem Json Web Tokens (JWT) and TLS using Java.
5. Goals
1. Demystify claims based auth with Json Web Tokens (JWT)
2. Learn how we solve service auth @Okta
3. Real world code example using Dropwizard
11. Identity attributes about a user provided by a trusted issuer
Examples: kerberos ticket, SAML assertion, JWT
Claims
12. Boarding pass is a signed set of claims made
by the airline about you
• Issued by airline
• Claims
• Name (authentication)
• Flight Date/Time, Number and Seating
Priority (authorization)
• Bar code/magnetic strip (signature)
• Proves that the pass was issued by the
airline and is not a forgery (authenticity).
Claims example
24. Monolithic auth model
Security Interceptors
C
o
n
t
e
x
t
GET https://myapplication.com/home
AuthN
Module
Mobile Web API
25. Monolithic auth model
GET https://myapplication.com/home
Security Interceptors
C
o
n
t
e
x
tUser
Module
Events
Module
AuthN
Module
Homepage
Module
Log eventsLookup user
Mobile Web API
26. Services auth model - context
Event Service
Security Interceptors
User Service
Security Interceptors
AuthN Service
Security Interceptors
Homepage Service
Security Interceptors
Authorization: Bearer <token>
GET https://myapplication.com/home
Authorization: Bearer <token>
Authorization: Bearer<token>
C
o
n
t
e
x
t
Lookup user ID with token
Mobile Web API
27. Services auth model - claims
Event Service
Security Interceptors
User Service
Security Interceptors
AuthN Service
Security Interceptors
Homepage Service
Security Interceptors
Authorization: Bearer <jwt> Authorization: Bearer <jwt>
Authorization: Bearer <jwt>
{
“userId”:”…”,
“tenantId”:”...”,
“scope”:”PROFILE_READ”
}
Issues access jwt after authN
Claims example
Concepts
• Claims
• Authentication broker
• Federation
Mobile Web API
28. Layers of security
Perimeter
Service
Event Service
Security Interceptors
User Service
Security Interceptors
AuthN Service
Security Interceptors
Homepage Service
Security Interceptors
Authorization: Bearer <claims_token>
User
29. 1 Background 2 Service Auth
• TLS overview
• Adding AuthZ
• Demo
3 User Auth
31. What is TLS?
• Secure Sockets Layer (SSL)
Transport Layer Security (TLS)
• Symmetric cryptography for data encryption
• Protection against failure via MAC
• Identity of communicating parties via asymmetric cryptography
34. TLS
client authentication
Client Server
2
Client Certificate Request
4
Certificate Verify
5
Calculate Key and Finish
Secured Channel
Hello
1
3
Client Certificate
1
5
• Client talking to authentic server
• Server talking to known client
• Requires client to have certificate
35. That’s a lot of certificates
Event ServiceUser Service
Homepage Service
• Enable support for multiple acceptable public keys
• Consider using a key hierarchy
• Rotating User CA requires change only to User Service
• Enable revocation checking
Root CA
(offline)
User CA Event CA
Homepage
CA
36. Problem solved?
Event ServiceUser Service
Homepage Service
User Service
ISS: Root CA
Event Service
ISS: Root CA
Homepage
Service
ISS: Root CA
38. Hostname verification
• Standard (RFC 2818)
• Match hostname of client to certificate
• Hard when services share hosts like in a cluster manager
Subject:
C=US,
ST=California,
L=San Francisco,
O=Acme Inc,
OU=Engineering,
CN=homepage03.internal.acme.com
Homepage
Service
39. Service-name verification
• Tie certificates to services rather than hosts
• Better portability
• Simpler deployments
• No standard
• Application level
Subject:
C=US,
ST=California,
L=San Francisco,
O=Acme Inc,
OU=Engineering,
CN=dev.homepage-service
Homepage
Service
42. So we’re done right?
Event Service
Security Interceptors
User Service
Security Interceptors
AuthN Service
Security Interceptors
Homepage Service
Security Interceptors
Mobile Web API
43. 1 Background 2 Service Auth 3 User Auth
• JOSE
• In practice
• Demo
47. JWA - signature types
HMAC
(Symmetric)
Digital Signature
(Asymmetric)
48. JWS – symmetric keys
Event Service
Security Interceptors
User Service
Security Interceptors
AuthN Service
Security Interceptors
Homepage Service
Security Interceptors
Symmetric Key
49. JWS – asymmetric keys
Event Service
Security Interceptors
User Service
Security Interceptors
AuthN Service
Security Interceptors
Homepage Service
Security Interceptors
Public key
Private key
50. JOSE onion
claims
signed claims
encrypted claims
• JWS – JSON Web Signatures
• JWT – JSON Web
• JWE – JSON Web Encryption
• JWA – JSON Web Algorithms
• JWK – JSON Web Key
JWT – Composes: JWA & JWK
JWS
JWE
Reference
52. Iterative rollout
Mobile Web API
Security Interceptors
C
o
n
t
e
x
tEvents
Module
AuthN
Module
Homepage
Module
User Service
Security Interceptors
Authorization: Bearer <JWT>
Generate JWT
53. Iterative rollout
Security Interceptors
AuthN Service
User Service
Security Interceptors
Authorization: Bearer <JWT>
Event Service
Security Interceptors
Homepage Service
Security Interceptors
Authorization: Bearer <JWT>
Authorization: Bearer <JWT>
Cookie / Token
Mobile Web API
54. Key Rotation
• Enable support for multiple acceptable public keys
• Consider using a key hierarchy
• Rotating AuthN CA requires change only AuthN service
• Enable revocation checking
Root CA
(offline)
Auth CA
Event Service
Security Interceptors
User Service
Security Interceptors
AuthN Service
Security Interceptors
Homepage Service
Security Interceptors
Public key
Private key
58. Recap
• Service auth with TLS
• Transport level privacy and authentication
• Service level authorization
• User auth with JWTs
• JWT
• Stateless
• Scalable
• Authentication broker
• Converts existing external identity attributes
into internal claims
• Internal claims enable federation across
microservices
• Code: https://github.com/wdawson/dropwizard-auth-
example
59. How can Okta help?
Universal Directory
Single Sign-On
Provisioning
Adaptive Multi-factor Authentication
Social Authentication
Inbound Federation
AD and LDAP Integration
Use the right tool for the job
Backend server stack is almost entirely Java with use of Jetty and Dropwizard to get a flavor of some of the tools
Transition: OK, I get claims. So if claims have been around in for such a long time why do people care about JWTs?
Clean
The concept of federation is very broad
As it relates to microservices/SOA, the idea is that as you break a system up, federation provides a model for services to
Just as we’ve traded in angle brackets for curlies the industry has moving from WS-* to OIDC
It’s starting to look like the Deathstar isn’t it?
The OpenID space isn’t without it’s own comical abbreviations:
But they certainly are more appetizing
Security interceptors
Validates AuthN is still valid
Validates user in context has correct permissions to access resource (AuthZ)
Context supplies authenticated user in context and permissions to all the other code in the monolith
AuthN module – code which knows how to authenticate a user. If interceptor determines user’s needs authentication AuthN module
Notice how AuthN is typically centralize but AuthZ decisions are distributed across the codebase
REST is stateless, we have no more shared context so how are we going to pass User info along to each service?
Naive approach is with the same random token we’ve been using
We can solve the context problem with baking important attributes into the claims token to prevent lookups
Now that we have a centralized AuthN service, we can extend the federation with claims
For the remainder of the talk we’re going focus on applying this federated claims based approach to auth.
In particular, we’re going to focus on backend service auth and we’re going to make the assumption that your services are talking HTTP
Important to note that while we are addressing client auth scenarios in this talk, the model we’ll be putting place naturally extends to the client following the OAuth model
Layers:
Perimeter – outside the scope of this presentation
Host – host level authentication and transport level security with TLS
User -
SSL predecessor
Secure key exchange = symmetric data exchange use symmetric
Message Authentication Code
Public key crypto for authentication
Hello = what do we support?
Key exchange = Where the magic happens, cipher dependent. “Master secret” & paint
Finished = encrypted test
Back to our services… What just happened?
Cert offering = authentication
Could be anyone:
Another service
An attacker
So what can we do?
Client extra step = verify can access private key
Trust root is better than client, rotation
opens attack vector
Quick word about certificates… How do we manage those certificates? A few things to consider, eveyone is different.
Multiple acceptable keys means rotation is easier
Key hierarchy means rotation is easier
Multiple ways to do this
For this talk, we’ll assume offline root, services underneath that
Revocation checking = easier rotation & required for rotation
Ok so, we’ve given our services each their own certificate that has a trust chain up to our root. Let’s go back to the TLS client authentication
Not quite.
Since they are all signed by the root, and that’s what we’re trusting, Event Service can still talk.
Ways around this, like not trusting root, but then we have rotation issues like I just talked about.
What are my options if I want to trust the root, but don’t want the event service to talk?
AuthZ: We’ve estabilished “Who you are” now we want to know “What can you do?”
”HTTP over TLS” standard RFC
Client Server && Server Client
If your services share hosts = harder
Wildcard or subjectAltName extension
Depending on environment, don’t solve the problem
Portability any host works
Deployments no special config per host
No standard .. sadface
Application level
Regex
Authoritative, omnipotent service
We can solve the context problem with baking important attributes into the claims token to prevent lookups
Now that we have a centralized AuthN service, we can extend the federation with claims
Audience question: What’s a security drawback of the symmetric key approach?
Walk the flow
Clients continue to use existing auth mechanism
AuthN Module converts external session / token representations into internal JWT
Potential future updates
Consider OpenID Connect at the client level
Remove homepage service entirely
Generate service specific access tokens up in the client (Oauth 2.0)
There are a number of great options
We use Nimbus JWT
Add our own policy on certificate revocation checking
JWT
Stateless
no need for a DB user info
Scalable
No need to query a DB to check if the token is valid
No need to call other services for data already computed in the token
At the core we make it easier to adopt cloud
3000 customers using Okta to connect with cloud apps
Adobe developer built the creative cloud auth on top of Okta for federated enterprise authentication
Companies already have their own AD or LDAP. Okta makes getting on to using CC faster and easier
Advent
Universal directory per customer