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.

Microservices Security Patterns & Protocols with Spring & PCF

863 vues

Publié le

SpringOne Platform 2018
Microservices Security Patterns & Protocols with Spring & PCF
Adib Saikali, Pivotal

Publié dans : Logiciels
  • ⇒ www.WritePaper.info ⇐ is a good website if you’re looking to get your essay written for you. You can also request things like research papers or dissertations. It’s really convenient and helpful.
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Hello! I do no use writing service very often, only when I really have problems. But this one, I like best of all. The team of writers operates very quickly. It's called ⇒ www.HelpWriting.net ⇐ Hope this helps!
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Microservices Security Patterns & Protocols with Spring & PCF

  1. 1. Microservices Security Patterns & Protocols with Spring & PCF Adib Saikali @asaikali
  2. 2. So you want to build secure cloud native applications!
  3. 3. The Security Toolbox
  4. 4. It’s easy to get confused
  5. 5. Goal for this talk is to organize the security toolbox
  6. 6. So you can build secure cloud native applications
  7. 7. So you can work better with your infosec team
  8. 8. Cover w/ Image The plan is to explore security patterns and protocols through a series of use cases with pointers on how to implement them with PCF and Spring
  9. 9. Let’s start from the beginning
  10. 10. 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
  11. 11. How to allow users to use the credentials with app 1 and app 2? Your company grows and now has 2 applications
  12. 12. Extract user tables into its own database App 2 Database App 2 Server App 1 Database App 1 Server User Database
  13. 13. 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.
  14. 14. 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!
  15. 15. 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
  16. 16. Don’t trust apps with user credentials
  17. 17. Introduce a single sign on authentication server 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 ● Improvement over LDAP user directory ● 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
  18. 18. SSO Login Demo ● Cloud Foundry UAA OpenId Connect Server ● Spring Security 5.1 OpenId Connect Support
  19. 19. 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
  20. 20. JSON Web Algorithms (JWA) ● There are numerous cryptographic algorithms that are used as basic building blocks in security protocols ● Systems exchanging data need to agree on which cryptographic algorithms are used in the exchange ● There is a need for a standard scheme to precisely identify algorithms “This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.” - JWA RFC 7518 ● In JWA the string HS256 refers to the hashed message authentication code (HMAC) with the secure hashing algorithm (SHA) that outputs a fixed size 256 bit hash ● JWA is useful to anyone needing to precisely specify which cryptographic algorithm is used in a specific situation.
  21. 21. JWA IANA Registry https://www.iana.org/assignments/jose/jose.xhtml
  22. 22. Example JWA Use Case ● You’re building an app that deals with medical images ● Medical images are encrypted then stored on an S3 bucket ● In your SQL database you have a table that tracks the what bucket and path the image is stored in and the encryption algorithm used to secure the image. ● A256GCM refers to the Advanced Encryption Standard with Galois Counter Mode using a 256-bit key img_id bucket ALG 87371241 myapp/hands A256GCM
  23. 23. JSON Web Key (JWK) ● Cryptographic algorithms use keys that need to be exchanged / stored / read ● Different cryptographic keys have different components for example an elliptic curve key needs to indicate the curve being used, and the x, y coordinates of the curve … etc. “A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.” - JWA RFC 7518 ● JWK offers a standard ways to represent cryptographic keys using JSON. It’s ideal for use with REST API’s { "kty":"EC", "crv":"P-256", "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU", "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0", "kid":"134" }
  24. 24. 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
  25. 25. 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
  26. 26. JWS Format Header Payload Signature { “typ” : “JWT”, “alg” : “HS256” } { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true } TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFO NFh7HgQ
  27. 27. Example JWS Document eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwI iwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2c Bab30RMHrHDcEfxjoYZgeFONFh7HgQ base64url(header).base64url(payload).base64url(signature)
  28. 28. JWF 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
  29. 29. Validating a JWS Demo ● Get the UAA certificate used to sign the JWS object ● Decode the JWS on jwt.io ● Validate that the JWS not tampered with and was issued by the localhost UAA
  30. 30. 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
  31. 31. JSON Web Encryption ● JWE is a data format for representing content that has been encrypted using JSON data structures ● JWE can be base64URL encoded which means they are safe to include in URLs query parameters and http headers ● Given a JSON you can encrypt it and represent the result as a JWE document “JSON Web Encryption (JWE) represents encrypted content 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 IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.” - RFC 7516
  32. 32. JWE Format Header Cipher Text Authentication Tag { “alg” : “RSA-OAEP”, “enc” : “A256GCM” } 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG 9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A XFBoMYUZodetZdvTiFvSkQ Encrypted Key Initialization Vector OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGipsEdY3mx_etLbbWSrFr05kLzcSr4qK Aq7YN7e9jwQRb23nfa6c9dStnImGyFDbSv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322ivDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je81860ppamavo35UgoRdbYaBcoh9QcfylQr66 oc6vFWXRcZ_ZT2LawVCWTIy3brGPi6UklfCpIMfIjf7iGdXKHzg 48V1_ALb6US04U3b
  33. 33. Example JWE documnet eyJhbGciOiJSU0ExXzUiLCJraWQiOiJmcm9kby5iYWdnaW5zQGhvYmJpdG9uLmV4YW1wb GUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.laLxI0j-nLH- _BgLOXMozKxmy9gffy2gTdvqzfTihJBuuzxg0V7yk1WClnQePFvG2K- pvSlWc9BRIazDrn50RcRai__3TDON395H3c62tIouJJ4XaRvYHFjZTZ2GXfz8YAImcc91Tfk0 WXC2F5Xbb71ClQ1DDH151tlpH77f2ff7xiSxh9oSewYrcGTSLUeeCt36r1Kt3OSj7EyBQXoZlN7I xbyhMAfgIe7Mv1rOTOI5I8NQqeXXW8VlzNmoxaGMny3YnGir5Wf6Qt2nBq4qDaPdnaAuuG UGEecelIO1wx1BpyIfgvfjOhMBs9M8XL223Fg47xlGsMXdfuY- 4jaqVw.bbd5sTkYwhAIqfHsx8DayA.0fys_TY_na7f8dwSfXLiYdHaA2DxUjD67ieF7fcVbIR62J hJvGZ4_FNVSiGc_raa0HnLQ6s1P2sv3Xzl1p1l_o5wR_RsSzrS8Z- wnI3Jvo0mkpEEnlDmZvDu_k8OWzJv7eZVEqiWKdyVzFhPpiyQU28GLOpRc2VbVbK4dQKP dNTjPPEmRqcaGeTWZVyeSUvf5k59yJZxRuSvWFf6KrNtmRdZ8R4mDOjHSrM_s8uwIFcqt4r 5GX8TKaI0zT5CbL5Qlw3sRc7u_hg0yKVOiRytEAEs3vZkcfLkP6nbXdC_PkMdNS- ohP78T2O6_7uInMGhFeX4ctHG7VelHGiT93JfWDEQi5_V9UN1rhXNrYu- 0fVMkZAKX3VWi7lzA6BP430m.kvKuFBXHe5mQr4lqgobAUg
  34. 34. JWE Features ● A JWE document encoded in the compact serialization format can be safely included in URLs or HTTP authorization headers ● Payload of of the document is secured ● Useful to anyone wanting to transmit or store JSON objects
  35. 35. 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
  36. 36. JSON Web Token ● A JSON object that contains information that is useful for making security decisions ● There are standard fields / claims that are part of JWT tokens ● The JSON object has been signed and formatted as a JWS document or encrypted and formatted as a JWE document ● The JWT token can be put into a URL parameter or an HTTP header “JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.” - RFC 7519
  37. 37. Standard Optional Fields on a JWT Token Field Description jti Unique id of the token iss Who issues the token iat Time when the token was issued nbf Time when the token is valid from exp Time when the token expires sub Unique id of the user that the token represents aud List of systems that can use the token
  38. 38. Using JWT with Http ● Add tokens to standard headers such as Authorization header as defined by Oauth2 with info about the end user GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3O DkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
  39. 39. ✅ 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
  40. 40. Using JWT with RabbitMQ / JMS Message ● Add the JWT token to a custom header in the outgoing JMS message
  41. 41. 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
  42. 42. 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
  43. 43. What exactly does OAuth2 define? ● Oauth 2 Defines 4 Roles ○ 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
  44. 44. What exactly does OAuth2 define? ● OAuth2 defines 4 ways that an application can obtain an access token from an OAuth2 authorization server to use with an resource server App 1 Server aka Client Resource Server X Authorization Server Do you want to allow app 1 do access resource server x? yes AT AT Resource Owner
  45. 45. Opaque vs. non Opaque Bearer Token Opaque access token Non opaque IdToken OAuth2 spec expects client applications to treat access tokens as opaque tokens
  46. 46. Resource Owner Password Credentials Grant Give me an access token because I know the users password
  47. 47. 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
  48. 48. 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 the this flow.
  49. 49. 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.0
  50. 50. ✅ 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
  51. 51. 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
  52. 52. Required ID Token fields Field Description iss Who issues the token iat Time when the token was issued exp Time when the token expires sub Unique id of the user that the token represents aud List of systems that can use the token Full list of IdToken fields at https://openid.net/specs/openid-connect-core-1_0.html#IDToken
  53. 53. OpenId Connect Flow Demo ● OpenId Connect Playground https://openidconnect.net/
  54. 54. How can my new cloud native application integrate with the existing corporate standard Active Directory / LDAP / SAML infrastructure?
  55. 55. 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
  56. 56. ✅ 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
  57. 57. Use OpenId Connect to authenticate Users
  58. 58. But what about microservices?
  59. 59. Microservices talk to each other
  60. 60. 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.
  61. 61. 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
  62. 62. 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
  63. 63. 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?
  64. 64. 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
  65. 65. 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
  66. 66. 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?
  67. 67. 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
  68. 68. 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
  69. 69. 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?
  70. 70. Bearer Token Relay ● The access and id tokens are passed from the edge microservice to the downstream microservices. ● 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 using token relay. BFF A B Oauth2 Server Get token
  71. 71. 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 ● 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 Get token
  72. 72. 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.
  73. 73. 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
  74. 74. 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
  75. 75. 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- via-automatic-cert-rotation
  76. 76. We are hiring! https://pivotal.io/careers/openings/spring-engineer-spring-security/1320220
  77. 77. Disclaimer
  78. 78. Unless otherwise indicated, these slides are © 2013-2018 Pivotal Software, Inc. and licensed under a Creative Commons Attribution- NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Safe Harbor Statement The following is intended to outline the general direction of Pivotal's offerings. It is intended for information purposes only and may not be incorporated into any contract. Any information regarding pre-release of Pivotal offerings, future updates or other planned modifications is subject to ongoing evaluation by Pivotal and is subject to change. This information is provided without warranty or any kind, express or implied, and is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions regarding Pivotal's offerings. These purchasing decisions should only be based on features currently available. The development, release, and timing of any features or functionality described for Pivotal's offerings in this presentation remain at the sole discretion of Pivotal. Pivotal has no obligation to update forward looking information in this presentation. 7 8
  79. 79. > Stay Connected. <Your CTA> <Related Session> #springone@s1p

×