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

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. ● 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. So you want to build
secure cloud native
applications!

4. The Security Toolbox

5. It’s easy to get confused

6. Goal for this talk is to organize the security toolbox

7. So you can build secure cloud native applications

8. So you can work better with your infosec team

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. Let’s start from the beginning

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. How to allow users to use the credentials with app 1 and app 2?
Your company grows and now has 2 applications

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

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. 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. 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. Don’t trust apps with user credentials

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. 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. 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. 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. How can my new cloud native
application integrate with the existing
corporate standard Active Directory /
LDAP / SAML infrastructure?

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. What are the standards that underpin
OpenID Connect?

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. 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. JWS Format
Header
Payload
Signature
{ “typ” : “JWT”, “alg” : “HS256” }
{
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true
}
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFO
NFh7HgQ

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

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. ✅ 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. How is a single microservice
secured?

42. Microservices talk to each other

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. 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. 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. 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. 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. 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. Demo
● Implementing a Resource Server
Implementing a
Resource Server
with Spring
Security 5.1

50. Multiple Microservices

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

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

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

62. PCF and Microservice Security

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