REST Service Authetication with TLS & JWTs
•Als PPTX, PDF herunterladen•
6 gefällt mir•7,984 views
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.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie REST Service Authetication with TLS & JWTs
Ähnlich wie REST Service Authetication with TLS & JWTs (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
REST Service Authetication with TLS & JWTs
- 1. Jon Todd @JonToddDotCom REST Service Auth with JWTs Wils Dawson @WilsDawson
- 2. About Okta Okta is the foundation for secure connections between people and technology
- 3. Used in 185 countries
- 4. Our stack
- 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
- 6. 1 Background • Concepts • The service auth problem 2 Service Auth 3 User Auth
- 7. Concepts
- 8. Verifying you are who you say you are (AuthN) Authentication
- 9. What you are allowed to do (AuthZ) Authorization
- 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
- 13. OK, I get claims. But why use JWTs?
- 14. Service protocol shift to REST
- 15. JSON <…/> {…}
- 16. JSON Object Signing & Encryption (JOSE) Working group: https://datatracker.ietf.org/wg/jose/charter/ • JWS – JSON Web Signatures • JWT – JSON Web Token (pronounced “jot”) • JWE – JSON Web Encryption • JWA – JSON Web Algorithms • JWK – JSON Web Key { "iss": "https://example.okta.com", "sub": "00ugrenMeqvYla4HW0g3", "aud": "w255HEWiSU4AuNxEjeij", "iat": 1446305282, "exp": 1446308882, "amr": [ "pwd" ], "auth_time": 1446305282, "email": "karl@example.com", "email_verified": true } Claims
- 17. Single authentication trusted across multiple separate systems Examples: WS-Federation, SAML, OpenID Connect Federation
- 18. Federation example • At ticket counter trade credentials for ticket (authentication broker) • Passport • Driver’s license • Agent at counter verifies credentials • ID issued by trusted source (trust) • Scans barcode and verifies photo (authentication) • Verifies flight is paid for and seat assigned (authorization) • Agent issues ticket (claims) • Ticket is accepted by multiple, independent parties (federation) • Security line entry • TSA check • Gate agent
- 20. Federation standards shift https://www.flickr.com/photos/robbies/693510178 • JWS – JSON Web Signatures • JWT – JSON Web Token • JWE – JSON Web Encryption • JWA – JSON Web Algorithms • JWK – JSON Web Key JW-
- 21. Use cases Delegated access OAuth 2.0 Identity claims JOSE OpenID ConnectFederation
- 22. OAuth 2 Framework RFC 6749 Assertion Framework RFC 7521 Token Introspection RFC 7662 Token Revocation RFC 7009 Dynamic Client Registration RFC 7591 JSON RFC 7159 JSON Web Token Bearer Assertion RFC 7523 Proof Key for Code Exchange (PKCE) RFC 7636 Simple Authentication and Security Layer (SASL) RFC 7628 Token Exchange Draft SAML 2.0 Bearer Assertion RFC 7522 Proof of Possession Draft JSON Web Token (JWT) RFC 7519 JSON Web Signature (JWS) RFC 7515 JSON Web Encryption (JWE) RFC 7516 JSON Web Key (JWK) RFC 7517 Bearer Token RFC 6750
- 23. The service auth problem
- 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
- 30. TLS overview
- 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
- 32. TLS handshake Client Server 2 Server Hello (with cert) 4 Finished 5 Finished Secured Channel Client Hello 1 3 Calculate Symmetric Key 3 • Hello • Key Exchange • Finished https://upload.wikimedia.org/wikipedia/commons/thumb/4/46/Diffie- Hellman_Key_Exchange.svg/2000px-Diffie-Hellman_Key_Exchange.svg.png
- 33. Who’s authenticated? Event ServiceUser Service Homepage Service Hello Hello, here’s my certificate Secured Channel User Service
- 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
- 37. Adding AuthZ
- 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
- 40. TLS client authentication for internal services http://developer.okta.com/blog/ More info?
- 41. Demo
- 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
- 44. JOSE
- 45. JWT format { "alg": "RS256" } { "iss": "https://example.okta.com", "sub": "00ugrenMeqvYla4HW0g3", "aud": "w255HEWiSU4AuNxEjeij", "iat": 1446305282, "exp": 1446308882, "amr": [ "pwd" ], "auth_time": 1446305282, "email": "joe@example.com", "email_verified": true } Header Claims Signature
- 46. JWT encoding base64url(Header) + “.” + base64url(Claims) + “.” + base64url(Signature) eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2V4YW 1wbGUub2t0YS5jb20iLCJzdWIiOiIwMHVncmVuTWVxdll sYTRIVzBnMyIsImF1ZCI6IncyNTVIRVdpU1U0QXVOeEV qZWlqIiwiaWF0IjoxNDQ2MzA1MjgyLCJleHAiOjE0NDYz MDg4ODIsImFtciI6WyJwd2QiXSwiYXV0aF90aW1lIjoxN DQ2MzA1MjgyLCJlbWFpbCI6ImthcmxAZXhhbXBsZS5jb 20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZX0.XcNXs4C7Dq pR22LLti777AMMVCxM7FjEPKZQndAS_Cc6R54wuQ5EA puY6GVFCkIlnfbNmYSbHMkO4HL3uoeXVOPQmcqhNPD LLEChj00jQwZDjhPD9uBoNwGyiZ9_YKwsRpzbg9NEeY8 xEwXJFIdk6SRktTFrVNHAOIhEQsgm8 Header Claims Signature
- 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
- 51. In practice
- 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
- 55. JWT Java Libraries https://openid.net/developers/libraries/#jwt • Jose4j • Nimbus JOSE + JWT • Java JWT • Resteasy • Apache Oltu - JOSE
- 56. Demo
- 57. Final thoughts
- 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
- 60. Thank You Jon Todd @JonToddDotCom Wils Dawson @WilsDawson
Hinweis der Redaktion
- 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