SlideShare a Scribd company logo
© Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
Security in the world of
microservices
Madhav Sathe
msathe@pivotal.io
Oct 2018
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.
Cover w/ Image
Agenda
➢ Challenges
➢ Standards and protocols
➢ PCF built for security
➢ Demo
➢ Bonus - Some patterns
The fundamentals
➢ Identity
○ Who you are
○ E.g. a person, web application, mobile application or a microservice
➢ AuthN/Authentication
○ Establish the identity (using credentials)
➢ AuthZ/Authorization
○ What resources you can access, what actions you can perform
➢ Federated identity
○ E.g. when I login to Pivotal sites using Pivotal Identity I can access my account
on Salesforce (without having to login to Salesforce separately)
➢ Delegated authorization
○ Limited amount of access given typically to an application on behalf of someone
Microservices are cool
Microservices deliver business agility?
Right
Microservices deliver faster time to market?
Right
Microservices make security simple?
Well...
In the high speed, agile world of
APIs & microservices
security is a moving target
Developer Challenges in µServices Architecture
WEB
BFF
Browser Mobile
Mobile
BFF
API> Identity federation in hybrid, multi-cloud apps> Identity federation in hybrid, multi-cloud apps
> AuthN/AuthZ for app/device/APIs to µService
> AuthN/AuthZ for µService to µService
> Single Sign On
> Identity federation in hybrid, multi-cloud apps
> AuthN/AuthZ for app/device/APIs to µService
> AuthN/AuthZ for µService to µService
> Single Sign On
> Managing credentials for backing services
> Identity federation in hybrid, multi-cloud apps
> AuthN/AuthZ for app/device/APIs to µService
> AuthN/AuthZ for µService to µService
> Single Sign On
> Managing credentials for backing services
> Creating containers
> Securing containers
> Identity federation in hybrid, multi-cloud apps
> AuthN/AuthZ for app/device/APIs to µService
> AuthN/AuthZ for µService to µService
> Single Sign On
> Managing credentials for backing services
> Creating containers
> Securing containers
> Runtime CVEs
> Identity federation in hybrid, multi-cloud apps
> AuthN/AuthZ for app/device/APIs to µService
> AuthN/AuthZ for µService to µService
> Single Sign On
> Managing credentials for backing services
> Creating containers
> Securing containers
> Runtime CVEs
> Threat vectors such as DDOS, SQL injection, etc
Embrace application platform built on
modern standards
Key standards and protocols
➢ JWT - JSON Web Token
○ Compact
○ URL safe
○ Base-64 encoded
○ Self contained
○ Used along with other JOSE standards - JWA, JWK, JWS and JWE
➢ OAuth2.0
○ Delegated authorization
➢ OpenID Connect
○ OAuth2.0 + Identity layer
JWT https://jwt.io/
Standard used by OpenID Connect to share asserted identity of the user (ID Token) and
(optionally) by OAuth2.0 to authorize delegated access (by value Access Token)
Header
Payload
Signature
{ “typ” : “JWT”, “alg” : “HS256” }
{
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true
}
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOn
RydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
OAuth 2.0
Protocol to provide delegated access control to applications
RFC Title Purpose
6749 The OAuth 2.0 Authorization Framework how a token can be obtained
6750 The OAuth 2.0 Authorization Framework:
Bearer Token Usage
how to make HTTP requests with the token
once it is obtained
Meet the actors
Authorization
Server
Application/
ClientResource Owner
Resource
Server/API
Client registers with AS
AS generates ID/Secret for client
RO authenticates itself
Allows Client to access RS
Client wants to access the protected RS
RS ‘trusts’ AS
Has the public key shared by AS
OAuth 2.0 Grant types: application types
➢ Authorization code: web application
○ Mostly used for server side apps such as web apps
○ Most common use of OAuth
➢ Password: Native Mobile, Desktop, or Command Line App
○ RO shares credentials with the client app → client app is trusted by RO
➢ Implicit: Single-Page JavaScript App
○ Client secret that is not guaranteed to be confidential
➢ Client credentials: service to service
○ When client app is acting on its own behalf
User is authenticated
User is not
authenticated
Authorization code grant flow
Resource
Server
Access Application
Give me Permission / Approval
Authenticate & Grant Authorization
Send Authorization Code
Exchange code with client
credentials for token
Resource
Owner
Send Token
Authorization
Server
Access protected resource
Send resource
Access
Control
Application
16
Authorization
Server
Resource
Server
Authenticate with Client
Credentials
Send Token
Access protected resource
(with token)
Application
Send resource
Access Control
Client credentials grant flow
OpenID Connect 1.0
Typical OIDC flow
Load Application
Request Login/Authorize
Authenticate & Grant Authorization
Request ID + Access Token
User Identity Provider RSApplication
Send Authorization Code
Exchange code with client
credentials for ID + AT
Send ID + AT
Exchange AT for Protected Resource
Types of tokens
➢ Access token
○ Generated by Auth Server for Client to access the Resource Server/API/microService
○ Goes in the Authorization header as a Bearer token
○ Opaque token
■ Randomly generated string
■ Resource Server can validate with Auth server
■ Risk mitigation - can be revoked
○ JWT
■ Contains user information and scopes
■ Self validated, saves roundtrip to Auth Server
■ Bummer - can’t be revoked
➢ Refresh token
○ Token used by client to get a new Access Token
➢ ID token
○ OIDC server
○ Always JWT
○ Contains user identity and claims
○ Meant to be used by Client
○ Self validated, saves roundtrip to Auth Server
Push security out of the application code on to the
platform
Enterprise ready security
App
➢ Security Services for App
○ UAA (SSO)
Identity
as a Service
○ Credhub
Credentials store as
a service
Integrated with
service brokers
A platform with security services for your apps...
PCF cellscf push App
PCF
runtimeCredhubSSO/UAA
● Identity Proxy
● User AuthN/AuthZ
● Service-to-Service
AuthN/AuthZ
● Credential Generation
● Credential Storage
● Credential Rotation
UAA - User Account and Authentication Service
OAuth2 server bundled/integrated within PCF that can be used for centralized identity
management
Its primary role is as an OAuth2 provider, issuing tokens for client applications
UAA - OIDC Certified IDP
UAA Basics
➢ Multi-tenant IDP
➢ Users : Internal or External (LDAP, SAML, OpenID Connect)
➢ Permissions
○ Groups associated with Users
○ Groups associated with Applications
○ On User’s Behalf - As Scopes
○ On Application’s Behalf - As Authorities
➢ External Group Mappings
○ Derive UAA Group from External Groups
○ LDAP, SAML, OpenID Connect
➢ External User Attributes
○ LDAP, SAML, OpenID Connect
○ In ID_Token and /UserInfo
SSO Service
➢ Secure apps with minimal developer overhead
➢ Provide UAA as a service
➢ Self-service dashboard for admins
➢ SAML IDP integration is hard, SSO service broker makes it easy for security admins
Personas
➢ Security admin
○ Create plans
○ Configure backing IDP
○ Map IDP users and attributes
➢ Platform operator
○ Create SSO service instance
○ Create Admin user
○ Create application users
➢ Application developer
○ Application manifest
○ Spring Boot/Security annotations
○ SSO service binding
○ Managing application scopes
PCF SSO Demo
SSO Plan
UAA Tenant
ToDo µService (RS)
SSO Service
Instance
User in the
UAA IDP
Register client
Create resource scopes
ToDo portal (Client)
Bind app with
AuthCode Grant type Ingest ClientID,
Secret via VCAP
Trusts auth server
Validates tokenshttps://www.myapp.com
Needs access to
protected resource
Tokens are not security
Facebook access token breach announced on Sep 25
Container-to-Container Networking
➢ C2C enables direct communication
between application containers on Cloud
Foundry
➢ Fine grained policies for µService to
µService access
➢ 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
What about security of the container?
PCF creates a natively secured container for every application instance
Multiple layers of overlapping container security provides defense in depth
➢ Complete isolation for containers using namespaces + pivot_root
➢ Unprivileged containers by default
➢ Cgroups to restrict resource usage and access control
➢ Dropped capabilities
➢ AppArmor as Mandatory Access Control layer
➢ Seccomp filtering to block harmful system calls
➢ Vetted and hardened OS to reduce attack surface
➢ Vetted and fine tuned RootFS
➢ All of the above with ZERO developers/operations overhead
PCF Locks Down Application Containers
CredHub - Cradle to Grave Credentials
Management
“VCAP_SERVICES”: {
“my-service”: [{
“credentials”: {
“credhub-ref”: “/c/my-broker/1111/2222/credentials”
},
}]
}
“VCAP_SERVICES”: {
“service-name”: [{
“credentials”: {
“uri”: “https://service-6yQVNrhZVP.example.com”,
“username”: “VofTuQk2BH”,
“password”: “fRqah7Wygi”
},
}]
}
POST /interpolate
interpolated credentials
CredHub
Service
Broker
PUT /data
PCF creates & interpolates credentials → no developer overhead,
mitigate risk of accidental leaks
Decide what you want to own from ‘security’
perspective
DIY K8s or container stack
Embedded OS
Container RootFS
Runtime Layer
Service Brokerage
Application Layer
PCF
Provided
You
manage
Container Scheduler
Container Runtime
OS
Container RootFS
Runtime Layer
Service Brokerage
Application Layer
You
manage
Container Scheduler
Container Runtime
Value line for business
Microservices Security Patterns
Work with your InfoSec to design and
develop secured µServices
API Gateway in DMZ
➢ Use cases
○ Authentication
○ Address common threats
■ Input validation
■ SQL injection
○ Mitigating DDOS attacks
➢ Key benefits
○ Separate the cross cutting concerns
○ Let security experts handle it and iterate over it without impact developer
productivity
➢ Things to remember
○ Use Opaque token as this is exposed on the wild web
○ Downstream/on platform service can retrieve ID Token for the given opaque
token
○ Make sure expiry of ID token doesn’t last more than opaque token
API as a service facade
➢ Use cases
○ Token exchange e.g. for accessing legacy apps
○ Enforce rate limiting
○ Coarse grained access control
○ Gather performance & usage metrics
○ Response aware business metrics
➢ Key benefits
○ Let security experts handle and iterate over security constructs
○ Hide microservices on internal network
○ Support hybrid use cases
○ Avoid tokens proliferation
➢ Things to remember
○ Use mTLS between API facade and µServices
○ Ensure µService doesn’t allow other access routes
µService handles AuthN/AuthZ
➢ Use cases
○ Each microservice needs to implement authentication
○ Fine grained authorization
○ Don’t want extra hop of the API facade
○ Developers want to implement all authorization closer to the business logic
○ Don’t have API platform that can implement cross-cutting concerns and
implementing a DIY API gateway is more costly than desired benefits
➢ Benefits
○ Better latency
○ No learning curve to implement custom API gateway and then maintain it
➢ Things to remember
○ Use mTLS for authenticate of the client µService
○ Block all other callers
○ Use Access Tokens for fine grained access control
Greenfield Apps Using Legacy IDP
➢ Mix of legacy and greenfield Apps/APIs OR ecosystem of multiple IDPs
○ Legacy API expects SAML assertion from an external IDP
○ Greenfield API expects OAuth token from UAA
➢ Flow
○ External IDP registers an OAuth client
○ grant_type = “urn:ietf:params:oauth:grant-type:saml2-bearer” or
“urn:ietf:params:oauth:grant-type:jwt-bearer”
○ Scopes -> Relevant scopes needed in access token
○ Request UAA Access Token
■ Pass client id and secret
■ JWT or SAML assertion
■ Response = UAA access token
Transforming How The World Builds & Runs Software
© Copyright 2018 Pivotal Software, Inc. All rights Reserved.

More Related Content

What's hot (20)

PDF
Webauthn Tutorial
FIDO Alliance
 
PDF
Chakray.com - Enterprise Security and IAM with WSO2IS and Penrose
Roger CARHUATOCTO
 
PDF
Full stack security
DPC Consulting Ltd
 
PPTX
Webinar: Extend The Power of The ForgeRock Identity Platform Through Scripting
ForgeRock
 
PDF
JavaOne 2014 - Securing RESTful Resources with OAuth2
Rodrigo Cândido da Silva
 
PDF
CIS14: OAuth and OpenID Connect in Action
CloudIDSummit
 
PDF
Authentication and Authorization Architecture in the MEAN Stack
FITC
 
PPTX
Getting Started With WebAuthn
FIDO Alliance
 
PDF
ConFoo 2015 - Securing RESTful resources with OAuth2
Rodrigo Cândido da Silva
 
PPT
OAuth 2.0 and OpenId Connect
Saran Doraiswamy
 
PDF
Identiverse - Microservices Security
Bertrand Carlier
 
PDF
Enterprise Single Sign On
WSO2
 
PPTX
U2F/FIDO2 implementation of YubiKey
Haniyama Wataru
 
PPTX
RSA Conference 2016: Don't Use Two-Factor Authentication... Unless You Need It!
Mike Schwartz
 
PDF
Stateless Auth using OAuth2 & JWT
Gaurav Roy
 
PDF
What the Heck is OAuth and Open ID Connect? - UberConf 2017
Matt Raible
 
PPTX
LASCON 2017: SAML v. OpenID v. Oauth
Mike Schwartz
 
PPTX
The Client is not always right! How to secure OAuth authentication from your...
Mike Schwartz
 
PPTX
Implementing MITREid - CIS 2014 Presentation
Justin Richer
 
PPTX
WSO2 Identity Server 5.3.0 - Product Release Webinar
WSO2
 
Webauthn Tutorial
FIDO Alliance
 
Chakray.com - Enterprise Security and IAM with WSO2IS and Penrose
Roger CARHUATOCTO
 
Full stack security
DPC Consulting Ltd
 
Webinar: Extend The Power of The ForgeRock Identity Platform Through Scripting
ForgeRock
 
JavaOne 2014 - Securing RESTful Resources with OAuth2
Rodrigo Cândido da Silva
 
CIS14: OAuth and OpenID Connect in Action
CloudIDSummit
 
Authentication and Authorization Architecture in the MEAN Stack
FITC
 
Getting Started With WebAuthn
FIDO Alliance
 
ConFoo 2015 - Securing RESTful resources with OAuth2
Rodrigo Cândido da Silva
 
OAuth 2.0 and OpenId Connect
Saran Doraiswamy
 
Identiverse - Microservices Security
Bertrand Carlier
 
Enterprise Single Sign On
WSO2
 
U2F/FIDO2 implementation of YubiKey
Haniyama Wataru
 
RSA Conference 2016: Don't Use Two-Factor Authentication... Unless You Need It!
Mike Schwartz
 
Stateless Auth using OAuth2 & JWT
Gaurav Roy
 
What the Heck is OAuth and Open ID Connect? - UberConf 2017
Matt Raible
 
LASCON 2017: SAML v. OpenID v. Oauth
Mike Schwartz
 
The Client is not always right! How to secure OAuth authentication from your...
Mike Schwartz
 
Implementing MITREid - CIS 2014 Presentation
Justin Richer
 
WSO2 Identity Server 5.3.0 - Product Release Webinar
WSO2
 

Similar to Microservices security - jpmc tech fest 2018 (20)

PPTX
Securing Microservices with Spring Cloud Security
Will Tran
 
PDF
Implementing Microservices Security Patterns & Protocols with Spring
VMware Tanzu
 
PDF
Building Highly Secure Cloud-Native Applications on PAS with Ease - Jignesh S...
VMware Tanzu
 
PDF
Secured REST Microservices with Spring Cloud
Orkhan Gasimov
 
PDF
When and Why Would I use Oauth2?
Dave Syer
 
PPTX
Enterprise Access Control Patterns for REST and Web APIs Gluecon 2011, Franco...
CA API Management
 
PDF
Cloud Foundry UAA as an Identity Gateway
VMware Tanzu
 
PDF
APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson...
apidays
 
PDF
API Security In Cloud Native Era
WSO2
 
PPTX
Enterprise Access Control Patterns for Rest and Web APIs
CA API Management
 
PPTX
Microservice security with spring security 5.1,Oauth 2.0 and open id connect
Nilanjan Roy
 
PPTX
Securing APIs with oAuth2
Michae Blakeney
 
PDF
Identiverse 2018 nathanael coffing
JoshuaCiccone2
 
PDF
Security as a Service - Tian Wang
VMware Tanzu
 
PPTX
Best Practices in Building an API Security Ecosystem
Prabath Siriwardena
 
PDF
muCon 2016: Authentication in Microservice Systems By David Borsos
OpenCredo
 
PDF
Authentication in microservice systems
David Borsos
 
PDF
Draft Ietf Oauth V2 12
Vishal Shah
 
PDF
Beyond API Authorization
Jared Hanson
 
PPTX
Enabling Cloud Native Security with OAuth2 and Multi-Tenant UAA
Will Tran
 
Securing Microservices with Spring Cloud Security
Will Tran
 
Implementing Microservices Security Patterns & Protocols with Spring
VMware Tanzu
 
Building Highly Secure Cloud-Native Applications on PAS with Ease - Jignesh S...
VMware Tanzu
 
Secured REST Microservices with Spring Cloud
Orkhan Gasimov
 
When and Why Would I use Oauth2?
Dave Syer
 
Enterprise Access Control Patterns for REST and Web APIs Gluecon 2011, Franco...
CA API Management
 
Cloud Foundry UAA as an Identity Gateway
VMware Tanzu
 
APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson...
apidays
 
API Security In Cloud Native Era
WSO2
 
Enterprise Access Control Patterns for Rest and Web APIs
CA API Management
 
Microservice security with spring security 5.1,Oauth 2.0 and open id connect
Nilanjan Roy
 
Securing APIs with oAuth2
Michae Blakeney
 
Identiverse 2018 nathanael coffing
JoshuaCiccone2
 
Security as a Service - Tian Wang
VMware Tanzu
 
Best Practices in Building an API Security Ecosystem
Prabath Siriwardena
 
muCon 2016: Authentication in Microservice Systems By David Borsos
OpenCredo
 
Authentication in microservice systems
David Borsos
 
Draft Ietf Oauth V2 12
Vishal Shah
 
Beyond API Authorization
Jared Hanson
 
Enabling Cloud Native Security with OAuth2 and Multi-Tenant UAA
Will Tran
 
Ad

Recently uploaded (20)

PDF
Research-Fundamentals-and-Topic-Development.pdf
ayesha butalia
 
PPTX
Dev Dives: Automate, test, and deploy in one place—with Unified Developer Exp...
AndreeaTom
 
PDF
Generative AI vs Predictive AI-The Ultimate Comparison Guide
Lily Clark
 
PPTX
AI Code Generation Risks (Ramkumar Dilli, CIO, Myridius)
Priyanka Aash
 
PPTX
AI in Daily Life: How Artificial Intelligence Helps Us Every Day
vanshrpatil7
 
PDF
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification
Ivan Ruchkin
 
PPTX
cloud computing vai.pptx for the project
vaibhavdobariyal79
 
PDF
RAT Builders - How to Catch Them All [DeepSec 2024]
malmoeb
 
PDF
Brief History of Internet - Early Days of Internet
sutharharshit158
 
PPTX
Farrell_Programming Logic and Design slides_10e_ch02_PowerPoint.pptx
bashnahara11
 
PPTX
The Future of AI & Machine Learning.pptx
pritsen4700
 
PPTX
AVL ( audio, visuals or led ), technology.
Rajeshwri Panchal
 
PDF
Peak of Data & AI Encore - Real-Time Insights & Scalable Editing with ArcGIS
Safe Software
 
PDF
Trying to figure out MCP by actually building an app from scratch with open s...
Julien SIMON
 
PDF
NewMind AI Weekly Chronicles – July’25, Week III
NewMind AI
 
PDF
Structs to JSON: How Go Powers REST APIs
Emily Achieng
 
PDF
The Future of Artificial Intelligence (AI)
Mukul
 
PDF
Tea4chat - another LLM Project by Kerem Atam
a0m0rajab1
 
PDF
How Open Source Changed My Career by abdelrahman ismail
a0m0rajab1
 
PPTX
Agile Chennai 18-19 July 2025 | Emerging patterns in Agentic AI by Bharani Su...
AgileNetwork
 
Research-Fundamentals-and-Topic-Development.pdf
ayesha butalia
 
Dev Dives: Automate, test, and deploy in one place—with Unified Developer Exp...
AndreeaTom
 
Generative AI vs Predictive AI-The Ultimate Comparison Guide
Lily Clark
 
AI Code Generation Risks (Ramkumar Dilli, CIO, Myridius)
Priyanka Aash
 
AI in Daily Life: How Artificial Intelligence Helps Us Every Day
vanshrpatil7
 
State-Dependent Conformal Perception Bounds for Neuro-Symbolic Verification
Ivan Ruchkin
 
cloud computing vai.pptx for the project
vaibhavdobariyal79
 
RAT Builders - How to Catch Them All [DeepSec 2024]
malmoeb
 
Brief History of Internet - Early Days of Internet
sutharharshit158
 
Farrell_Programming Logic and Design slides_10e_ch02_PowerPoint.pptx
bashnahara11
 
The Future of AI & Machine Learning.pptx
pritsen4700
 
AVL ( audio, visuals or led ), technology.
Rajeshwri Panchal
 
Peak of Data & AI Encore - Real-Time Insights & Scalable Editing with ArcGIS
Safe Software
 
Trying to figure out MCP by actually building an app from scratch with open s...
Julien SIMON
 
NewMind AI Weekly Chronicles – July’25, Week III
NewMind AI
 
Structs to JSON: How Go Powers REST APIs
Emily Achieng
 
The Future of Artificial Intelligence (AI)
Mukul
 
Tea4chat - another LLM Project by Kerem Atam
a0m0rajab1
 
How Open Source Changed My Career by abdelrahman ismail
a0m0rajab1
 
Agile Chennai 18-19 July 2025 | Emerging patterns in Agentic AI by Bharani Su...
AgileNetwork
 
Ad

Microservices security - jpmc tech fest 2018

  • 1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0 Security in the world of microservices Madhav Sathe [email protected] Oct 2018
  • 2. 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.
  • 3. Cover w/ Image Agenda ➢ Challenges ➢ Standards and protocols ➢ PCF built for security ➢ Demo ➢ Bonus - Some patterns
  • 4. The fundamentals ➢ Identity ○ Who you are ○ E.g. a person, web application, mobile application or a microservice ➢ AuthN/Authentication ○ Establish the identity (using credentials) ➢ AuthZ/Authorization ○ What resources you can access, what actions you can perform ➢ Federated identity ○ E.g. when I login to Pivotal sites using Pivotal Identity I can access my account on Salesforce (without having to login to Salesforce separately) ➢ Delegated authorization ○ Limited amount of access given typically to an application on behalf of someone
  • 6. Microservices deliver business agility? Right Microservices deliver faster time to market? Right Microservices make security simple? Well...
  • 7. In the high speed, agile world of APIs & microservices security is a moving target
  • 8. Developer Challenges in µServices Architecture WEB BFF Browser Mobile Mobile BFF API> Identity federation in hybrid, multi-cloud apps> Identity federation in hybrid, multi-cloud apps > AuthN/AuthZ for app/device/APIs to µService > AuthN/AuthZ for µService to µService > Single Sign On > Identity federation in hybrid, multi-cloud apps > AuthN/AuthZ for app/device/APIs to µService > AuthN/AuthZ for µService to µService > Single Sign On > Managing credentials for backing services > Identity federation in hybrid, multi-cloud apps > AuthN/AuthZ for app/device/APIs to µService > AuthN/AuthZ for µService to µService > Single Sign On > Managing credentials for backing services > Creating containers > Securing containers > Identity federation in hybrid, multi-cloud apps > AuthN/AuthZ for app/device/APIs to µService > AuthN/AuthZ for µService to µService > Single Sign On > Managing credentials for backing services > Creating containers > Securing containers > Runtime CVEs > Identity federation in hybrid, multi-cloud apps > AuthN/AuthZ for app/device/APIs to µService > AuthN/AuthZ for µService to µService > Single Sign On > Managing credentials for backing services > Creating containers > Securing containers > Runtime CVEs > Threat vectors such as DDOS, SQL injection, etc
  • 9. Embrace application platform built on modern standards
  • 10. Key standards and protocols ➢ JWT - JSON Web Token ○ Compact ○ URL safe ○ Base-64 encoded ○ Self contained ○ Used along with other JOSE standards - JWA, JWK, JWS and JWE ➢ OAuth2.0 ○ Delegated authorization ➢ OpenID Connect ○ OAuth2.0 + Identity layer
  • 11. JWT https://jwt.io/ Standard used by OpenID Connect to share asserted identity of the user (ID Token) and (optionally) by OAuth2.0 to authorize delegated access (by value Access Token) Header Payload Signature { “typ” : “JWT”, “alg” : “HS256” } { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true } TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOn RydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
  • 12. OAuth 2.0 Protocol to provide delegated access control to applications RFC Title Purpose 6749 The OAuth 2.0 Authorization Framework how a token can be obtained 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage how to make HTTP requests with the token once it is obtained
  • 13. Meet the actors Authorization Server Application/ ClientResource Owner Resource Server/API Client registers with AS AS generates ID/Secret for client RO authenticates itself Allows Client to access RS Client wants to access the protected RS RS ‘trusts’ AS Has the public key shared by AS
  • 14. OAuth 2.0 Grant types: application types ➢ Authorization code: web application ○ Mostly used for server side apps such as web apps ○ Most common use of OAuth ➢ Password: Native Mobile, Desktop, or Command Line App ○ RO shares credentials with the client app → client app is trusted by RO ➢ Implicit: Single-Page JavaScript App ○ Client secret that is not guaranteed to be confidential ➢ Client credentials: service to service ○ When client app is acting on its own behalf User is authenticated User is not authenticated
  • 15. Authorization code grant flow Resource Server Access Application Give me Permission / Approval Authenticate & Grant Authorization Send Authorization Code Exchange code with client credentials for token Resource Owner Send Token Authorization Server Access protected resource Send resource Access Control Application
  • 16. 16 Authorization Server Resource Server Authenticate with Client Credentials Send Token Access protected resource (with token) Application Send resource Access Control Client credentials grant flow
  • 18. Typical OIDC flow Load Application Request Login/Authorize Authenticate & Grant Authorization Request ID + Access Token User Identity Provider RSApplication Send Authorization Code Exchange code with client credentials for ID + AT Send ID + AT Exchange AT for Protected Resource
  • 19. Types of tokens ➢ Access token ○ Generated by Auth Server for Client to access the Resource Server/API/microService ○ Goes in the Authorization header as a Bearer token ○ Opaque token ■ Randomly generated string ■ Resource Server can validate with Auth server ■ Risk mitigation - can be revoked ○ JWT ■ Contains user information and scopes ■ Self validated, saves roundtrip to Auth Server ■ Bummer - can’t be revoked ➢ Refresh token ○ Token used by client to get a new Access Token ➢ ID token ○ OIDC server ○ Always JWT ○ Contains user identity and claims ○ Meant to be used by Client ○ Self validated, saves roundtrip to Auth Server
  • 20. Push security out of the application code on to the platform Enterprise ready security
  • 21. App ➢ Security Services for App ○ UAA (SSO) Identity as a Service ○ Credhub Credentials store as a service Integrated with service brokers A platform with security services for your apps... PCF cellscf push App PCF runtimeCredhubSSO/UAA ● Identity Proxy ● User AuthN/AuthZ ● Service-to-Service AuthN/AuthZ ● Credential Generation ● Credential Storage ● Credential Rotation
  • 22. UAA - User Account and Authentication Service OAuth2 server bundled/integrated within PCF that can be used for centralized identity management Its primary role is as an OAuth2 provider, issuing tokens for client applications
  • 23. UAA - OIDC Certified IDP
  • 24. UAA Basics ➢ Multi-tenant IDP ➢ Users : Internal or External (LDAP, SAML, OpenID Connect) ➢ Permissions ○ Groups associated with Users ○ Groups associated with Applications ○ On User’s Behalf - As Scopes ○ On Application’s Behalf - As Authorities ➢ External Group Mappings ○ Derive UAA Group from External Groups ○ LDAP, SAML, OpenID Connect ➢ External User Attributes ○ LDAP, SAML, OpenID Connect ○ In ID_Token and /UserInfo
  • 25. SSO Service ➢ Secure apps with minimal developer overhead ➢ Provide UAA as a service ➢ Self-service dashboard for admins ➢ SAML IDP integration is hard, SSO service broker makes it easy for security admins
  • 26. Personas ➢ Security admin ○ Create plans ○ Configure backing IDP ○ Map IDP users and attributes ➢ Platform operator ○ Create SSO service instance ○ Create Admin user ○ Create application users ➢ Application developer ○ Application manifest ○ Spring Boot/Security annotations ○ SSO service binding ○ Managing application scopes
  • 28. SSO Plan UAA Tenant ToDo µService (RS) SSO Service Instance User in the UAA IDP Register client Create resource scopes ToDo portal (Client) Bind app with AuthCode Grant type Ingest ClientID, Secret via VCAP Trusts auth server Validates tokenshttps://www.myapp.com Needs access to protected resource
  • 29. Tokens are not security Facebook access token breach announced on Sep 25
  • 30. Container-to-Container Networking ➢ C2C enables direct communication between application containers on Cloud Foundry ➢ Fine grained policies for µService to µService access ➢ 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
  • 31. What about security of the container? PCF creates a natively secured container for every application instance Multiple layers of overlapping container security provides defense in depth ➢ Complete isolation for containers using namespaces + pivot_root ➢ Unprivileged containers by default ➢ Cgroups to restrict resource usage and access control ➢ Dropped capabilities ➢ AppArmor as Mandatory Access Control layer ➢ Seccomp filtering to block harmful system calls ➢ Vetted and hardened OS to reduce attack surface ➢ Vetted and fine tuned RootFS ➢ All of the above with ZERO developers/operations overhead
  • 32. PCF Locks Down Application Containers
  • 33. CredHub - Cradle to Grave Credentials Management “VCAP_SERVICES”: { “my-service”: [{ “credentials”: { “credhub-ref”: “/c/my-broker/1111/2222/credentials” }, }] } “VCAP_SERVICES”: { “service-name”: [{ “credentials”: { “uri”: “https://service-6yQVNrhZVP.example.com”, “username”: “VofTuQk2BH”, “password”: “fRqah7Wygi” }, }] } POST /interpolate interpolated credentials CredHub Service Broker PUT /data PCF creates & interpolates credentials → no developer overhead, mitigate risk of accidental leaks
  • 34. Decide what you want to own from ‘security’ perspective DIY K8s or container stack Embedded OS Container RootFS Runtime Layer Service Brokerage Application Layer PCF Provided You manage Container Scheduler Container Runtime OS Container RootFS Runtime Layer Service Brokerage Application Layer You manage Container Scheduler Container Runtime Value line for business
  • 36. Work with your InfoSec to design and develop secured µServices
  • 37. API Gateway in DMZ ➢ Use cases ○ Authentication ○ Address common threats ■ Input validation ■ SQL injection ○ Mitigating DDOS attacks ➢ Key benefits ○ Separate the cross cutting concerns ○ Let security experts handle it and iterate over it without impact developer productivity ➢ Things to remember ○ Use Opaque token as this is exposed on the wild web ○ Downstream/on platform service can retrieve ID Token for the given opaque token ○ Make sure expiry of ID token doesn’t last more than opaque token
  • 38. API as a service facade ➢ Use cases ○ Token exchange e.g. for accessing legacy apps ○ Enforce rate limiting ○ Coarse grained access control ○ Gather performance & usage metrics ○ Response aware business metrics ➢ Key benefits ○ Let security experts handle and iterate over security constructs ○ Hide microservices on internal network ○ Support hybrid use cases ○ Avoid tokens proliferation ➢ Things to remember ○ Use mTLS between API facade and µServices ○ Ensure µService doesn’t allow other access routes
  • 39. µService handles AuthN/AuthZ ➢ Use cases ○ Each microservice needs to implement authentication ○ Fine grained authorization ○ Don’t want extra hop of the API facade ○ Developers want to implement all authorization closer to the business logic ○ Don’t have API platform that can implement cross-cutting concerns and implementing a DIY API gateway is more costly than desired benefits ➢ Benefits ○ Better latency ○ No learning curve to implement custom API gateway and then maintain it ➢ Things to remember ○ Use mTLS for authenticate of the client µService ○ Block all other callers ○ Use Access Tokens for fine grained access control
  • 40. Greenfield Apps Using Legacy IDP ➢ Mix of legacy and greenfield Apps/APIs OR ecosystem of multiple IDPs ○ Legacy API expects SAML assertion from an external IDP ○ Greenfield API expects OAuth token from UAA ➢ Flow ○ External IDP registers an OAuth client ○ grant_type = “urn:ietf:params:oauth:grant-type:saml2-bearer” or “urn:ietf:params:oauth:grant-type:jwt-bearer” ○ Scopes -> Relevant scopes needed in access token ○ Request UAA Access Token ■ Pass client id and secret ■ JWT or SAML assertion ■ Response = UAA access token
  • 41. Transforming How The World Builds & Runs Software © Copyright 2018 Pivotal Software, Inc. All rights Reserved.

Editor's Notes

  • #5: But first let us take a look at fundamentals. Federation - Authentication take place in one single domain, other security realms that trust this primary domain can reuse the authentication and trust the authenticity of the identity established Any system in this federation can accept the credentials of the authentication domain. The primary domain is what we call an Identity Provider (IdP) or Asserting Party (AP); the other security domains that trust the IdP to authenticate users are referred to as Relying Parties (RP) or Service Providers (SP). Authentication and identity data are passed between these parties using tokens. These Tokens are minted by a system called a Security Token Service (STS) or a Federation Service (OAuth Authorization Server and an OpenID Connect Provider are examples of an STS and a Federation Service, respectively.) The end result is that a STS hands a token to the user after they first log into that authentication service. When the user then requests access to another domain, the domain registers that the user already has a token, and grants it access without requesting another log-in. Federation allows for SSO across these different “security domains” or “realms.”
  • #6: Everyone understands what Microservices are? Is everyone convinced that Microservices are cool?
  • #8: Unlike traditional IT In the world of APIs and Microservices Security is always a moving target
  • #9: Once you start modernizing your apps they look somewhat like this. Other than traditional Web applications enterprises now have Mobile apps. Several enterprises provide APIs exposed over cloud, for their partners, or for larger community. Thanks to agile movement and 2 weeks sprint - new enhancements, continued modernization will mean this. Bunch of polyglot microservices accessing polyglot backing stores. Now compare this with traditional monoliths where most of this logic resides within same app server or JVM. All the method calls were within a same process, no need to authenticate each call stack method call. Also, traditional apps had mostly relational DB as a backing store, now we use backing store that suites the microservice. There are several security related challenges developers have to deal with here - So the developers have to take care of all of this and still deliver agility for business.
  • #10: So embracing modern and open standards is crucial to ensure interoperability. Interoperability across clouds, across polyglot services, across partners, etc
  • #18: Before I explain what is OpenID Connect is let me start off by explaining what it is NOT ---- Many people mistake OAuth to be an Authentication protocol. However OAuth as a specification only deals with delegated user access. The OAuth Client requests a token, gets a token which it eventually uses to access an API resource. In some cases there may not be a user at all. Authentication in the context of a user accessing an application tells an application who the current user is and whether or not they're present. A full authentication protocol will probably also tell you a number of attributes about this user, such as a unique identifier, an email address, and what to call them The protocol which fulfills the authentication requirements is OpenID Connect. ---- It can be said to be the next generation of SAML which the federation protocol used for Single Sign-On and Authentication. If authenticates and asserts the users identity via claims which are passed back in the form SAML assertion in the XML SOAP format. However OpenID Connect is much more light-weight and flexible when compared to SAML as it utilizes the OAuth protocol and JWT as the backbone. Its REST Based and supports multiple application types similar to OAuth. The Application to be authenticated could be a Web Application or a Native Application or Java Script Application. All these types are supported because its based on OAuth which supports all these types.
  • #19: Auth doesn’t mandate what info can be passed in AT