Microservices Security Patterns & Protocols with Spring & PCF

Microservices Security Patterns &
Protocols with Spring & PCF
Adib Saikali
@asaikali

So you want to build
secure cloud native
applications!

Goal for this talk is to organize the security toolbox

So you can build secure cloud native applications

So you can work better with your infosec team

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

Let’s start from the beginning

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

How to allow users to use the credentials with app 1 and app 2?
Your company grows and now has 2 applications

Extract user tables into its own database
App 2
Database
App 2
Server
App 1
Database
App 1
Server
User
Database

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.

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!

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

Don’t trust apps with user credentials

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

SSO Login Demo
● Cloud Foundry UAA OpenId Connect Server
● Spring Security 5.1 OpenId Connect Support

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

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.

JWA IANA Registry
https://www.iana.org/assignments/jose/jose.xhtml

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

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"
}

✅ JSON Web Algorithms (JWA) & JSON Web Key (JWK)
JSON Web Signature (JWS) JSON Web Encryption (JWE)
OAuth 2
OpenId Connect

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

JWS Format
Header
Payload
Signature
{ “typ” : “JWT”, “alg” : “HS256” }
{
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true
}
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFO
NFh7HgQ

Example JWS Document
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwI
iwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2c
Bab30RMHrHDcEfxjoYZgeFONFh7HgQ
base64url(header).base64url(payload).base64url(signature)

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

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

✅ JSON Web Signature (JWS) JSON Web Encryption (JWE)
OAuth 2
OpenId Connect

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

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

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

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

✅ JSON Web Signature (JWS) ✅ JSON Web Encryption (JWE)
OAuth 2
OpenId Connect

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

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

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

✅ Javascript Object Signing and Encryption (jose)
✅ JSON Web Token (JWT)
OAuth 2
OpenId Connect

Using JWT with RabbitMQ / JMS Message
● Add the JWT token to a custom header in the outgoing JMS message

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

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

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

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

Opaque vs. non Opaque Bearer Token
Opaque
access token
Non opaque
IdToken
OAuth2 spec expects client applications to treat access tokens as opaque tokens

Resource Owner Password Credentials Grant
Give me an access
token because I
know the users
password

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

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.

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

✅ OAuth 2
OpenId Connect

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

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

OpenId Connect
Flow
Demo
● OpenId Connect Playground
https://openidconnect.net/

How can my new cloud native
application integrate with the existing
corporate standard Active Directory /
LDAP / SAML infrastructure?

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

✅ OAuth 2
✅ OpenId Connect

Use OpenId Connect to
authenticate Users

Microservices talk to each other

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.

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

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

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?

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

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

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?

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

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

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?

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

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

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.

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

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

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

We are hiring!
https://pivotal.io/careers/openings/spring-engineer-spring-security/1320220

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

> Stay Connected.
<Your CTA>
<Related Session>
#springone@s1p

Microservices Security Patterns & Protocols with Spring & PCF

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Microservices Security Patterns & Protocols with Spring & PCF

Ähnlich wie Microservices Security Patterns & Protocols with Spring & PCF (20)

Mehr von VMware Tanzu

Mehr von VMware Tanzu (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Microservices Security Patterns & Protocols with Spring & PCF