Implementing Microservices Security

Patterns & Protocols with Spring Security 5

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
© Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
Quick Survey
● 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?
So you want to build
secure cloud native
applications!
The Security Toolbox
It’s easy to get confused
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
The plan is to explore
security patterns and
protocols through a series Cover w/ Image

of use cases with examples

on how to implement them
with Spring Security 5
Let’s start from the beginning
Your company has 1 application

App 1 App 1
Server Database

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
Your company grows and now has 2 applications

How to allow users to use the credentials with app 1 and app 2?
Extract user tables into its own database

App 1 App 1
Server Database

User
Database

App 2 App 2
Server Database
Extract user tables into its own database
Challenges
● 2 application collects credentials and thus can App 1 App 1
leak credentials Server DB

● Duplicate implementation of login / user

management / forgot password functionality
across apps

● A server side bug / security vulnerability can User DB

compromise user tables

● Authentication logic changes less frequently

than application features
App 2 App 2
● Requires coordination between app 1 and app 2 Server DB
when making changes to user tables.
Company wants to use a 3rd party application

Challenges
App 1 App 1
Server
● 3rd party app does not understand the DB

database schema we are using to

manage the users

● 3rd party app does not support the 3rd Party

database app 1 and app 2 use Application User DB

● Integrating 3rd party app into the

company requires modifying the code
for the 3rd party app which is not App 2 App 2
practical! Server DB
Introduce a directory service

Standards based directory server enables in

App 1 App 1
house apps and 3rd apps to access the user Server DB
database using a common protocol and
schema
● Widely deployed in the enterprise
● Improvement over a custom shared SQL DB LDAP
3rd Party
● Easy to implement with Spring Security LDAP directory
Application
Service
But
● Every app must collect a user credentials and
can leak them through a vunerability / bad code
/ malicious intent App 2 App 2
● Optimized for username / password creds. Server DB
What about multifactor authentication
● Only works inside the corporate boundary, can’t
easily extend to external parties
Don’t trust apps with user credentials
Simplistic Web Application Security

App 1 App 1
Server Database

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
Use OpenID Connect to Authenticate Users

All applications will redirect users to the SSO

App 1 App 1
server to be authenticated. The SSO server Server DB
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
OpenID Connect OIDC
Connect
Server DB
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
App 2 App 2
Server DB
 ● CloudFoundry User Account and Authentication
(UAA) Server
● Open Source Apache Licensed
UAA OpenID ● Used to secure the Cloud Foundry Ecosystem
Connect Server ● Designed to be embedded inside a larger system
● Easy to use as a development OIDC server
Demo
● https://github.com/cloudfoundry/uaa
 Configure the OIDC Provider
Spring Security 5
● Register client with UAA
OpenID Connect ● Obtain a client id and secret from UAA
Support ● Note the UAA oauth2/oidc endpoints

Demo
 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 App 1 App 1
Server DB
users

● The Cloud Foundry UAA can be used

as a bridge to LDAP / Active Directory
/ SAML and other OpenID Connect
Servers OpenID
Connect OIDC
Server DB
● The PCF SSO leverages the UAA to
offer applications running on PCF
easy access to OpenID Connect and
OAuth from the cf marketplace
LDAP SAML
Server Idp
What are the standards that underpin
OpenID Connect?
OpenID Connect Standards Layer Cake

OpenID Connect

OAuth 2

Javascript Object Signing and Encryption (jose)

JSON Web Token (JWT)

JSON Web Signature (JWS) JSON Web Encryption (JWE)

JSON Web Algorithms (JWA) & JSON Web Key (JWK)

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 { “typ” : “JWT”, “alg” : “HS256” }

{
“sub”: “1234567890”,
Payload “name”: “John Doe”,
“admin”: true
}
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFO
Signature
NFh7HgQ
Example JWS Document

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwI
iwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2c
Bab30RMHrHDcEfxjoYZgeFONFh7HgQ

base64url(header).base64url(payload).base64url(signature)
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

 ● 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
Validating a JWS was issued by the localhost UAA

Demo
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
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
Getting an Access Token from an OAuth2 Server

Do you want to allow app 1 do access resource server x?

yes Authorization
Resource Owner Server

n
ca
fi I
r
w ne ver x
o er
t he ce s
sk ur AT
s e a reso
a
ple cess
ac Resource Server
X
App 1 AT
Server
aka
Client
Resource Owner Password Credentials Grant

Give me an access
token because I
know the users
password

On the Roadmap for Spring security 5.2

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

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

OpenID Connect Standards Layer Cake

✅ OpenID Connect

✅ OAuth 2
✅ Javascript Object Signing and Encryption (jose)
✅ JSON Web Token (JWT)
✅ JSON Web Signature (JWS) ✅ JSON Web Encryption (JWE)
✅ JSON Web Algorithms (JWA) & JSON Web Key (JWK)
How is a single microservice
secured?
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

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

● 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
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 Microservice
JWT
A B
Implementing a ● Implementing a Resource Server
Resource Server
with Spring
Security 5.1

Demo
Multiple Microservices
How should the UI code interact with microservices?

Browser
What about CORS?
What about a Native
Mobile Clients?

What about Server Side

Rendering for a Web UI?

A B C
Monolithic Edge Gateway
Make a UI Microservice that is exposed to end users and have it serve up the UI?

Browser
Native Mobile

UI

A B C
Backend For Frontend (BFF)
Extend each UI experience with a dedicated backend component for UI
http://samnewman.io/patterns/architectural/bff/

Browser
WEB iPhone
iPhone Mobile
BFF BFF

A B C
The Big Picture

Native Mobile App Single Page App Desktop App GUI

Layer

Edge
Microservice Microservice Microservice
Microservices

Internal
Microservices

Problem: How can we secure the call chain between different microservices?
Bearer Token Relay
Oauth2
Server
Get token

BFF A B

● 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
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
 ● How to implement Token Relay with Spring
Security 5

Token Relay
Bearer Token Exchange
Oauth2
Server Get token
Get token

BFF A B

● 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
 ● How to implement Token Exchange with Spring
Security 5

Token Exchange
Service Username / Password
Oauth2
Server
Get token

BFF A B

● 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.
 ● How to use Client Credentials with Spring
Security 5

Client Credentials
PCF and Microservice Security
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-vi
a-automatic-cert-rotation