Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Implementing Microservices Security Patterns & Protocols with Spring

SpringOne Tour Toronto 2018 by Pivotal
Implementing Microservices Security Patterns & Protocols with Spring - Adib Saikali

Implementing Microservices Security Patterns & Protocols with Spring

  1. 1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 Dec 13 2018 Adib Saikali - @asaikali 2.5 hour version of theis talk https://www.youtube.com/watch?v=nrmQH5SqraA https://github.com/jgrandja/oauth2-protocol-patterns Implementing Microservices Security Patterns & Protocols with Spring Security 5
  2. 2. ● Who has used OAuth 2.0 and/or OpenID Connect 1.0? ● Who has used Spring Security? ● Who has tried the OAuth 2.0 Client features in Spring Security 5.1? ● Who has tried the OAuth 2.0 Resource Server features in Spring Security 5.1? Quick Survey
  3. 3. So you want to build secure cloud native applications!
  4. 4. The Security Toolbox
  5. 5. It’s easy to get confused
  6. 6. Goal for this talk is to organize the security toolbox
  7. 7. So you can build secure cloud native applications
  8. 8. So you can work better with your infosec team
  9. 9. Cover w/ Image The plan is to explore security patterns and protocols through a series of use cases with examples on how to implement them with Spring Security 5
  10. 10. Let’s start from the beginning
  11. 11. Your company has 1 application App 1 Database App 1 Server Simple and easy to implement using Spring Security but ● Application collects credentials and thus can leak credentials ● Validates credentials against the credentials tables in the database ● Need to implement forgot password functionality ● Need to implement user management functionality ● A server side bug / security vulnerability can compromise user tables ● Authentication logic changes less frequently than application features
  12. 12. How to allow users to use the credentials with app 1 and app 2? Your company grows and now has 2 applications
  13. 13. Extract user tables into its own database App 2 Database App 2 Server App 1 Database App 1 Server User Database
  14. 14. Extract user tables into its own database App 2 DB App 2 Server App 1 DB App 1 Server User DB Challenges ● 2 application collects credentials and thus can leak credentials ● Duplicate implementation of login / user management / forgot password functionality across apps ● A server side bug / security vulnerability can compromise user tables ● Authentication logic changes less frequently than application features ● Requires coordination between app 1 and app 2 when making changes to user tables.
  15. 15. Company wants to use a 3rd party application App 2 DB App 2 Server App 1 DB App 1 Server User DB 3rd Party Application Challenges ● 3rd party app does not understand the database schema we are using to manage the users ● 3rd party app does not support the database app 1 and app 2 use ● Integrating 3rd party app into the company requires modifying the code for the 3rd party app which is not practical!
  16. 16. Introduce a directory service App 2 DB App 2 Server App 1 DB App 1 Server LDAP directory Service Standards based directory server enables in house apps and 3rd apps to access the user database using a common protocol and schema ● Widely deployed in the enterprise ● Improvement over a custom shared SQL DB ● Easy to implement with Spring Security LDAP But ● Every app must collect a user credentials and can leak them through a vunerability / bad code / malicious intent ● Optimized for username / password creds. What about multifactor authentication ● Only works inside the corporate boundary, can’t easily extend to external parties 3rd Party Application
  17. 17. Don’t trust apps with user credentials
  18. 18. Simplistic Web Application Security App 1 Database App 1 Server Simple and easy to implement using Spring Security but ● Application collects credentials and thus can leak credentials ● Validates credentials against the credentials tables in the database ● Need to implement forgot password functionality ● Need to implement user management functionality ● A server side bug / security vulnerability can compromise user tables ● Authentication logic changes less frequently than application features
  19. 19. Use OpenID Connect to Authenticate Users App 2 DB App 2 Server App 1 DB App 1 Server OpenID Connect Server OIDC DB All applications will redirect users to the SSO server to be authenticated. The SSO server will authenticate users and provide the app with the user’s identity. ● Apps don’t see user credentials ● Easy to implement with Spring Security ● Widely deployed standards Kerberos / SAML / OpenID Connect But ● Lots of products that provide SSO server ● The standards can be complex to work with ● Lots of ways that the standards and products can be configured
  20. 20. UAA OpenID Connect Server Demo ● CloudFoundry User Account and Authentication (UAA) Server ● Open Source Apache Licensed ● Used to secure the Cloud Foundry Ecosystem ● Designed to be embedded inside a larger system ● Easy to use as a development OIDC server ● https://github.com/cloudfoundry/uaa
  21. 21. Spring Security 5 OpenID Connect Support Demo Configure the OIDC Provider ● Register client with UAA ● Obtain a client id and secret from UAA ● Note the UAA oauth2/oidc endpoints
  22. 22. How can my new cloud native application integrate with the existing corporate standard Active Directory / LDAP / SAML infrastructure?
  23. 23. Introduce OpenID Connect to LDAP Bridge ● Configure the OpenID Connect Server to use LDAP when Authenticating users ● The Cloud Foundry UAA can be used as a bridge to LDAP / Active Directory / SAML and other OpenID Connect Servers ● The PCF SSO leverages the UAA to offer applications running on PCF easy access to OpenID Connect and OAuth from the cf marketplace App 1 DB App 1 Server OpenID Connect Server OIDC DB LDAP Server SAML Idp
  24. 24. What are the standards that underpin OpenID Connect?
  25. 25. Javascript Object Signing and Encryption (jose) OpenID Connect Standards Layer Cake JSON Web Algorithms (JWA) & JSON Web Key (JWK) JSON Web Signature (JWS) JSON Web Encryption (JWE) JSON Web Token (JWT) OAuth 2 OpenID Connect
  26. 26. JSON Web Signature (JWS) ● JWS is a data format for representing content secured with digital signatures or Message Authentication Codes ● Given a JWS document you can answer two questions about the JSON payload of the document ○ Has this JSON object been changed since it was created? ○ Who created this JSON object? “JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.” RFC 7515
  27. 27. JWS Format Header Payload Signature { “typ” : “JWT”, “alg” : “HS256” } { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true } TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFO NFh7HgQ
  28. 28. Example JWS Document eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwI iwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2c Bab30RMHrHDcEfxjoYZgeFONFh7HgQ base64url(header).base64url(payload).base64url(signature)
  29. 29. JWS Features ● A JWS document encoded in the compact serialization format can be safely included in URLs or HTTP authorization headers ● Anyone can decode and view the payload of the document ● It is easy to verify that the payload was not tampered with ● It is easy to determine who created the document via shared secret or a certificate ● Useful to anyone wanting to transmit or store JSON objects
  30. 30. Validating a JWS Demo ● Get the UAA certificate used to sign the JWS object ● Decode the JWS on jwt.io ● Validate that the JWS is not tampered with and was issued by the localhost UAA
  31. 31. OAuth 2.0 Authorization Framework ● Is a framework for allowing users to authorize applications to access their data ○ An invoicing application might request permission to allow it to send emails containing invoices and payment reminders from your gmail account ● Authorized applications get an access token that they can use to call a service ○ invoicing app gets an access token it can use to call gmail to send an email but can’t use the token to delete emails or read them ● Does not tell the authorized application anything about the identity of the user ○ The invoicing app can’t find out profile or other information about the user that authorized the invoicing app to send emails via gmail ● Does not specify a token format. ● Expects other frameworks to extend it
  32. 32. OAuth 2 by itself is not enough “OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations. In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery). Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate. This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.” - RFC 6749
  33. 33. 4 Key OAuth Concepts / Terms ● Resource Server ○ a network accessible service ○ typically a web application or an api ● Resource Owner ○ An entity that can agree to provide access to a protected resource ○ typically a person ● Client ○ an application making requests to a resource server ○ Typically web application calling an api or an api calling an api ● Authorization Server ○ Ask the resource owner if they will allow a client to access a resource server on their behalf ○ Issues access tokens allowing client to call the resource server
  34. 34. Getting an Access Token from an OAuth2 Server App 1 Server aka Client Resource Server X Authorization Server please ask the owner if I can access resource server x Do you want to allow app 1 do access resource server x? yes AT AT Resource Owner
  35. 35. Resource Owner Password Credentials Grant Give me an access token because I know the users password On the Roadmap for Spring security 5.2
  36. 36. Client Credentials There is no user Give me a token to act on my own behalf here is my client id and client secret Supported by Spring Security 5.1
  37. 37. Implicit Grant Go ask the user if I can access their resources By the way be warned I can’t be trusted to keep the token secure so give me a temporary access token Not applicable to spring since there is no server side code in this flow.
  38. 38. Authorization Code Grant Go ask the user if I can access their resources By the way I can keep all my tokens secure. When the access token expires I want to renew it without bothering the user so give me a refresh token too Supported by Spring Security 5
  39. 39. OpenID Connect ● Authentication protocol built on top of OAuth2, JWT and TLS ● Defines a standardized user identity token as JWT with required fields ● Defines a userinfo endpoint that clients can call to learn details about the user such as email address, profile, contact info … etc. ● Most OAuth2 servers also implement OpenID Connect ● Large scale implementations exist
  40. 40. ✅ Javascript Object Signing and Encryption (jose) OpenID Connect Standards Layer Cake ✅ JSON Web Algorithms (JWA) & JSON Web Key (JWK) ✅ JSON Web Signature (JWS) ✅ JSON Web Encryption (JWE) ✅ JSON Web Token (JWT) ✅ OAuth 2 ✅ OpenID Connect
  41. 41. How is a single microservice secured?
  42. 42. Microservices talk to each other
  43. 43. Essence of the solution Every request to a microservice must include a security token that the microservice can easily validate and use for making authentication / authorization decisions.
  44. 44. What protocol does your microservice speak? ● HTTP (REST, SOAP) ● AMQP (Messaging) ● Apache Thrift (Remote Procedure Call Framework) ● gRPC (Remote Procedure Call Framework) ○ A high performance, open source, general RPC framework that puts mobile and HTTP/2 first from Google. ● Custom TCP protocol
  45. 45. Key Idea: There is no one “best” protocol! ● There is no one best protocol to use ● Protocols will evolve over time so it’s best to make sure that any security solution can work with current and future protocols
  46. 46. What format should the security token use? ● Is the token format standardized? ● Can the token be used with any protocol? ● Is the token easy to parse? ● Can the token be included in a URL parameter? ● Does the token support HTTP? ● Can the token be used with non HTTP protocols? ● Are there lots of libraries in lots of programming languages for working with the token? ● Is the token format considered “easy” to work with?
  47. 47. Standard Security Token Formats ● To get a Kerberos ticket you need a Kerberos server ● To get a SAML token you need a SAML server / protocol ● To get a JWT you need something that can give it to you Token Standard Format Protocol Specific Year of Standardization Kerberos Ticket Binary Yes, Kerberos 1993 SAML Token XML Yes, SAML 2002 JWT Token JSON NO 2015
  48. 48. Use JWT Tokens ● Every request to a microservice must include a security token that the microservice can easily authenticate and use for making authorization decisions. ● Your HTTP only microservices will likely evolve to support support other protocols such as AMQP, Thrift, or gRPC ● JWT is a simple and useful security token format with libraries available in most programming languages ● JWT is protocol agnostic Microservice A Microservice B JWT
  49. 49. Demo ● Implementing a Resource Server Implementing a Resource Server with Spring Security 5.1
  50. 50. Multiple Microservices
  51. 51. How should the UI code interact with microservices? A B C Browser What about CORS? What about a Native Mobile Clients? What about Server Side Rendering for a Web UI?
  52. 52. Monolithic Edge Gateway Make a UI Microservice that is exposed to end users and have it serve up the UI? UI Native Mobile Browser A B C
  53. 53. Backend For Frontend (BFF) Extend each UI experience with a dedicated backend component for UI http://samnewman.io/patterns/architectural/bff/ WEB BFF Browser iPhone MobileiPhone BFF A B C
  54. 54. The Big Picture Native Mobile App Single Page App Desktop App Microservice Microservice Microservice GUI Layer Edge Microservices Internal Microservices Problem: How can we secure the call chain between different microservices?
  55. 55. Bearer Token Relay ● The access and id tokens are passed from the edge microservice to the downstream microservices. ● Token must have all the scopers required by the BFF, A, B ● Very easy to implement but not very secure ● Bearer tokens have many well known attacks against them. Collaborate with your infosec team on a solution that takes your specific context into account before BFF A B Oauth2 Server Get token
  56. 56. Bearer Token Cautionary Tale Facebook hack of 50 million accounts “The perpetrator’s ultimate aim was to steal what are known as “OAuth bearer tokens.” Essentially, these tokens prove the Facebook user is the rightful owner of an account and denote what they have access to. As Shadwell describes them: “OAuth tokens are like car keys, if you're holding them you can use them, there's no discrimination of the holder.” And in the context of this attack, those keys unlocked not just Facebook accounts, but any site that affected users accessed with a Facebook login. That might include Instagram or news websites.” -- Forbes Arcticle @ https://www.forbes.com/sites/thomasbrewster/2018/09/29/how-facebook-was-hacked-and- why-its-a-disaster-for-internet-security/#5a1b65a20336
  57. 57. Token Relay ● How to implement Token Relay with Spring Security 5
  58. 58. Bearer Token Exchange ● At every hop of the microservice call chain we exchange the token we got for a new token to use with downstream services ● Allows for tokens with a narrower scope ● Standards in this space for OAuth2 are emerging ● Bearer tokens have many well known attacks against them. Collaborate with your infosec team on a solution that takes your specific context into account before BFF A B Oauth2 Server Get token Get token
  59. 59. Token Exchange ● How to implement Token Exchange with Spring Security 5
  60. 60. Service Username / Password ● At every hop of the microservice call chain we exchange the token we got for a new token to use with downstream services ● Standards in this space for OAuth2 are emerging ● Bearer tokens have many well known attacks against them. Collaborate with your infosec team on a solution that takes your specific context into account before using token exchange. BFF A B Oauth2 Server Get token
  61. 61. Client Credentials ● How to use Client Credentials with Spring Security 5
  62. 62. PCF and Microservice Security
  63. 63. PCF and Microservice Security ● PCF provides three features that are useful when implementing microservices security ○ Route Services ○ Container to Container networking ○ Container Instance Identity ● Pushing complexity out of your code into the platform.
  64. 64. Route Services ● Cloud Foundry Route services enable the processing of requests before they reach the application ● Can be used to route requests through an api gateway where security policies can be enforced ● https://docs.cloudfoundry.org/servic es/route-services.html
  65. 65. Container-to-Container Networking ● Enables direct communication between application containers on Cloud Foundry ● Enables the definition of fine grained policies about how apps are allowed to talk to each other ● Policies can be defined via cf cli so easy to incorporate into your pipelines no need for tickets to configure firewalls ● Provides DNS based service discovery ● https://docs.cloudfoundry.org/concepts/u nderstand-cf-networking.html
  66. 66. Container Instance Identity ● Every container instance created on a Cloud Foundry is assigned a unique ○ X.509 certificate ○ PKCS#1 RSA private key ● The certificate and key pair are rotated every 24 hours or shorter duration set by the administrator ● The certificate contains ○ The Common Name property is set to the instance GUID for the given app instance. ○ The certificate contains an IP SAN set to the container IP address for the given app instance. ○ The certificate contains a DNS SAN set to the instance GUID for the given app instance. ○ The Organizational Unit property in the certificate’s Subject Distinguished Name contains the values organization:ORG-GUID, space:SPACE-GUID, and app:APP-GUID. The ORG-GUID, SPACE-GUID, and APP-GUID are set to the GUIDs for the organization, space, and app as assigned by Cloud Controller. ● Enables mutual TLS between microservices calling each other OAuth spec assumes TLS is used ○ https://content.pivotal.io/blog/new-in-pcf-2-1-app-container-identity-assurance-vi a-automatic-cert-rotation

    Soyez le premier à commenter

    Identifiez-vous pour voir les commentaires

  • IvanMoneys

    Dec. 20, 2018
  • Gudimetla

    Dec. 20, 2018
  • aladinux

    Jan. 6, 2019
  • skotam

    Mar. 10, 2019
  • MohammedNami

    Jul. 26, 2019
  • wilferraciolli

    Dec. 29, 2019
  • ImrankhanPatan

    Feb. 25, 2020

SpringOne Tour Toronto 2018 by Pivotal Implementing Microservices Security Patterns & Protocols with Spring - Adib Saikali

Vues

Nombre de vues

1 660

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

213

Actions

Téléchargements

82

Partages

0

Commentaires

0

Mentions J'aime

7

×