Red Hat API Management

API Security with OpenID Connect

Presenter
Title
Date
 CUSTOMER MOVING TO
CONTAINERS?
Customer Benefits

● Breaking down the monolith means faster turnaround.

● Greater flexibility.
● Fully automated testing driving better QA.
● Free from single technology limits
● Makes customer agile, cloud native, reactive compliant, with bounded
security and fully aggregate enabled!

2
 REMEMBER SECURITY
Everything Has To Be Super Secure

● Independent services that are no longer bound to one monolith i.e. just one
security context on one cluster or multiple ones ?
● So in microservices - does each service have to store identity?
● Ownership of identity data is a risk if not done properly.

3
 CSO IS ON THE SPOTLIGHT
Recent News On Data Breaches Is Not A Good Start

77,000,000 PSN RECORDS STOLEN

Sony

143,000,000 ACCOUNTS
Equifax

117,000,000 RECORDS STOLEN

LinkedIn

4
 DEVELOPERS HEADACHE
Homemade Security Is Always A Recipe For Disaster

● The bar for appdev security has

been raised substantially.
● Most devs don’t really ‘do’
security.
○ E.g. Storing user
information - should be as
salted hash.
● The hand rolled solutions of the
past are not viable going
forwards.
5
 PROBLEM WAS SOLVED WHILE AGO
Banks

● Most people do not keep their

savings under their mattress for
the same security reasons.

● They store them in a trusted

environment - i.e. the bank.

● Then use a separate means to

authorise / authenticate
payments.

6
 API SECURITY WORKS IN THE SAME
WAY
Trusted Identity Authority

● Identity is abstracted away to a

single ‘fortress’.
● Tokens are issued as a means of
allowing access to services and
resources.
● So now your application services
no longer have to store sensitive
data!

7
 API SECURITY
Evolution of API Security

Naked API Simple API Keys Federated Control

The Authentication Granddaddy - Basic Auth

8 INSERT DESIGNATOR, IF NEEDED

 API SECURITY
Top Schemes

Most API Management platforms supports the following security schemes:

● API Key single token string

● APP ID/APP Key (Basic Auth) two token strings i.e. username, password
● OpenID Connect (OIDC) simple identity layer on top of OAuth framework

9
OAUTH
 OAUTH 2.0
From 20,000 FT

OAuth (Open Authorization) is an User

open standard for access delegation:
Authorize Owns

● One service can request access

to resources on another service
on the behalf of the user.

Published October 2012 Client Resources

Accesses

11
 OAUTH 2.0
Delegation

OAuth enables users

to grant third-party
access to their web
resources without
sharing their
passwords.

12
 OAUTH 2.0
Terminology

● Resource Owner: generally yourself.

● Resource Server: server hosting protected data (for example Google
hosting your profile).
● Client: application requesting access to a resource server (i.e. a mobile
application).
● Authorization Server: server issuing token to the client. This token will be
used for the client to request the resource server.

13
 OAUTH 2.0
Grant / Flow Types

Authorization Code Flow

The most secure and used where a user logs into Identity server and grants
access to Application to retrieve their data
Client Credentials Flow
Only Application data is passed in a single request for an Access Token
Implicit Flow
User logs in but secret is not passed
Resource Owner Password Flow
Application, username and password data is passed in a single request for an
Access Token

14
OPENID CONNECT
 OPENID CONNECT
Overview

● Built on top of the OAuth 2.0

protocol

● Allows clients to verify the

identity of an end user

● Obtains basic profile information

about the end user

● RESTful HTTP API, using JSON as

a data format

● Like SAML - but not just

webpage centric, easier to
16
implement.
 OPENID CONNECT
Layered Security Standards

Specifies JWT for token, and some

OpenID Connect
extensions

Core delegation flows.

OAuth flows
Lots of flexibility (too much?)

Wide variety of token and

Tokens
encryption standards

17
 OPENID CONNECT
Vs OAuth 2.0

OpenID is an open standard for authentication. A user must obtain an OpenID

account through an OpenID identity provider (for example, Google). The user will
then use that account to sign into any website (the relying party) that accepts
OpenID authentication.

OAuth2 is an open standard for authorization. Confusingly, OAuth2 is also the

basis for OpenID Connect. OAuth2 provides secure delegated access, meaning
that an application, called a client, can take actions or access resources on a
resource server on the behalf of a user, without the user sharing their credentials
with the application.

18
 OPENID CONNECT
ID Token

● Provides identity information to

Name: John Doe
the application from the
Type: Employee
Authority Server
Expired by:
● Base64 encoded - easy to work
Company
with.
Expiration: 02-06-

2019

19
 JWT (“JOT”)
To The Rescue

● Signed by algo and verified by

only correct key

● Contains user identity in form of

claims (Private, public, reserved)

● For OIDC purpose, SSO is widely

adopted in consumer/enterprise
apps

● Eliminates the need to look up

against a central access control
list

20
AUTHORIZATION CODE FLOW
COMPLETE EXCHANGE
 AUTHORIZATION CODE FLOW
An Orientation

User API Management

Resource Identity Provider
Owner API
RH SSO Manager

Application

Browser Resource
Client
Server

Server Side Applications

API
Service
Gateway

Authorization
Server

22
 AUTHORIZATION CODE FLOW
#0 - 3scale API Gateway Gets RH SSO Public Key On Configuration Load

User Identity Provider API Management

API
RH SSO Manager

Application

Browser GET
/auth/realms/{realm}

Server Side Applications

API
Service
Gateway

23
 AUTHORIZATION CODE FLOW
#1 - User Starts Using The Web App

User Identity Provider API Management

GET
API
onlinestore.com/catalog.html RH SSO Manager

Application

Browser

Server Side Applications

API
Service
Gateway

24
 AUTHORIZATION CODE FLOW
#2 - The Application Introduces RH SSO

User Identity Provider API Management

API
RH SSO Manager

Application

GET
Browser
/auth/realms/{realm}/protocol/
openid-connect/auth

Server Side Applications

API
Service
Gateway

25
 AUTHORIZATION CODE FLOW
#3 - RH SSO Forwards To Login Form

User Identity Provider API Management

Login Page
API
RH SSO Manager

Application

Browser

Server Side Applications

API
Service
Gateway

26
 AUTHORIZATION CODE FLOW
#4 - The User Logs Into RH SSO

User POST {username /

Identity Provider API Management
password}
API
RH SSO Manager

Application

Browser

Server Side Applications

API
Service
Gateway

27
 AUTHORIZATION CODE FLOW
#5 - RH SSO Forwards To Consent Page

Consent
User Screen Identity Provider API Management
API
RH SSO Manager

Application

Browser

Server Side Applications

API
Service
Gateway

28
 AUTHORIZATION CODE FLOW
#6 - The User Consents

User POST {consent} Identity Provider API Management

API
RH SSO Manager

Application

Browser

Server Side Applications

API
Service
Gateway

29
 AUTHORIZATION CODE FLOW
#7 - RH SSO Redirects To Application And Sends An Auth Code

User Identity Provider API Management

API
RH SSO Manager

Application

Browser GET { redirect_uri, code,

state }

Server Side Applications

API
Service
Gateway

30
 AUTHORIZATION CODE FLOW
#7.1 - The Temp Auth Code

● Is used to acquire an
access code.
● Think of this as being a
cloakroom ticket - this
can be used once only to
acquire a bearer token.

31
 AUTHORIZATION CODE FLOW
#8 - The Web App Calls The Token Endpoint

User Identity Provider API Management

API
RH SSO Manager

Application

Browser POST
/auth/realms/{realm}/protocol/openid-connect/token

Server Side Applications

API
Service
Gateway

32
 AUTHORIZATION CODE FLOW
#9 - RH SSO Sends A Valid Bearer Token

User Identity Provider API Management

API
RH SSO Manager

Application

Browser HTTP 200 { access_token, token_type,

expires_in }

Server Side Applications

API
Service
Gateway

33
 AUTHORIZATION CODE FLOW
#9.1 - The Bearer Token

"A security token with the property that any party in possession of the token (a
"bearer") can use the token in any way that any other party in possession of it
can"
34
 AUTHORIZATION CODE FLOW
#9.2 - The Bearer Token

Authorization: Bearer
QXV0aG9yaXphdGlvbjogQmVhcmVyIA0Kew0KICJqdGkiOiAiYmNiMTFmNDktZTZhZS00NGNhLWIwNzctMzc5MjU5NGYw
ZDk4IiwNCiAiZXhwIjogMTQ5NTI3MjczOSwNCiAibmJmIjogMCwNCiAiaWF0IjogMTQ5NDMyMjMzOSwNCiAiaXNzIjog
Imh0dHA6Ly8wOTY2ZWExZi5uZ3Jvay5pby9hdXRoL3JlYWxtcy9mb3VybWFya3MiLA0KICJhdWQiOiAiNGQ2NTI0MDYi
LA0KICJzdWIiOiAiZDIwZGM0MTUtNzUyZi00YTc5LWEzYTgtNTJlOTVlYTZkZWM2IiwNCiAidHlwIjogIkJlYXJlciIs
DQogImF6cCI6ICI0ZDY1MjQwNiIsDQogInNlc3Npb25fc3RhdGUiOiAiNTVhODQzMjktY2Y2ZC00YjliLWJhOGYtYWJh
MDM3NjRjMjFjIiwNCiAiY2xpZW50X3Nlc3Npb24iOiAiYmYxYTA3MzktYTM5Yy00NTE1LTljMDAtNzhlMTgyNmI4ZDM2
IiwNCiAiYWxsb3dlZC1vcmlnaW5zIjogWw0KICAiaHR0cHM6Ly93d3cuZ2V0cG9zdG1hbi5jb20iDQogXSwNCiAicmVh
bG1fYWNjZXNzIjogew0KICAicm9sZXMiOiBbDQogICAiYWNjZXNzX215X3Jlc291cmNlIg0KICBdDQogfSwNCiAicmVz
b3VyY2VfYWNjZXNzIjogew0KICAiYWNjb3VudCI6IHsNCiAgICJyb2xlcyI6IFsNCiAgICAibWFuYWdlLWFjY291bnQi
LA0KICAgICJ2aWV3LXByb2ZpbGUiDQogICBdDQogIH0NCiB9LA0KICJuYW1lIjogInRlc3QgdXNlciIsDQogInByZWZl
cnJlZF91c2VybmFtZSI6ICJ0ZXN0dXNlciIsDQogImdpdmVuX25hbWUiOiAidGVzdCIsDQogImZhbWlseV9uYW1lIjog
InVzZXIiLA0KICJlbWFpbCI6ICJ0ZXN0QGJsYWguY29tIg0KfQ0K
Accept: */*
Postman-Token: 86b86d4a-8369-40af-8612-9f0d3589fdfb
Cf-Ray: 35c3a94bb1ac35ae-LHR
X-3Scale-Proxy-Secret-Token: Shared_secret_sent_from_proxy_to_API_backend_169ad455fe40801e

What does a bearer token look like?

35
 AUTHORIZATION CODE FLOW
#9.3 - The Bearer Token
Authorization: Bearer
{
"jti": "bcb11f49-e6ae-44ca-b077-3792594f0d98",
"exp": 1495272739,
"nbf": 0,
if you base64 decrypt you get: "iat": 1494322339,
"iss": "http://0966ea1f.ngrok.io/auth/realms/fourmarks",
"aud": "4d652406",
"sub": "d20dc415-752f-4a79-a3a8-52e95ea6dec6",
"typ": "Bearer",
"azp": "4d652406",
"session_state": "55a84329-cf6d-4b9b-ba8f-aba03764c21c",
notice the role information "client_session": "bf1a0739-a39c-4515-9c00-78e1826b8d36",
"allowed-origins": [
"https://www.getpostman.com"

the token is a JWT.

],
"realm_access": {
"roles": [
"access_my_resource"
]
},
"resource_access": {
"account": {
"roles": [
"manage-account",
"view-profile"
]
}
},
"name": "test user",
"preferred_username": "testuser",
"given_name": "test",
"family_name": "user",
"email": "test@blah.com"
}

36
 AUTHORIZATION CODE FLOW
#9.4 - The Bearer Token

● Digitally signed by the Auth

Server.

● A Standardised Identity token.

● Contains the username and

roles, but can also add custom

claims.

37
 AUTHORIZATION CODE FLOW
#9.5 - Web App Submits The Access Token To Get User Info (Optional)

User Identity Provider API Management

API
RH SSO Manager

Application

Access
Browser GET
Token
/realms/{realm}/protocol/openid-connect/userinfo

Server Side Applications

API
Service
Gateway

38
 AUTHORIZATION CODE FLOW
#9.6 - Web App Receives UserInfo

User Identity Provider API Management

API
RH SSO Manager
HTTP 200
{ user_info }

Application

Access
Browser
Token

Server Side Applications

API
Service
Gateway

39
 AUTHORIZATION CODE FLOW
#10 - Web App Submits The Bearer Token

User Identity Provider API Management

API
RH SSO Manager

Application

Access
Browser
Token

Server Side Applications

API
Service
Gateway

gateway.com/api/catalog
Header: “Authentication: Bearer
{token}”

40
 AUTHORIZATION CODE FLOW
#11 - Gateway Verifies Token

User Identity Provider API Management

API
RH SSO Manager

Application

Access
Browser
Token

Server Side Applications

API
Service
Gateway

Verify JWT

41
 AUTHORIZATION CODE FLOW
#12 - Gateway Calls Backend API

User Identity Provider API Management

API
RH SSO Manager

Application

Access
Browser
Token

Server Side Applications

API
Service
Gateway

backend.com/buystuff

42
 AUTHORIZATION CODE FLOW
#13.1 - Gateway Reports To API Manager

User Identity Provider API Management

API
RH SSO Manager

Application

Access
Browser GET
Token
/transactions/authrep.xml

Server Side Applications

API
Service
Gateway

43
 AUTHORIZATION CODE FLOW
#13.2 - API Manager Response

User Identity Provider API Management

API
RH SSO Manager

Application

Access
Browser HTTP 200 { authorized
Token
}

Server Side Applications

API
Service
Gateway

44
RED HAT 3SCALE API
MANAGEMENT
 RED HAT 3SCALE API MANAGEMENT
System Architecture

The 3scale API Management architecture consists of :

● The API Manager which manages the API, Developers and Applications
● The Traffic Manager (API Gateways) that enforce the policies from the API
Manager and delegate authorization to 3rd party IDPs
● The Identity Provider (IDP) identity hub that supports many
authentication using various protocols
● The API Backend the API. i.e. the API Provider

46
 RED HAT API MANAGEMENT
Gateway Operations

● Checks the timestamp for ‘expired’ token.

● Checks the client_id is still valid

● Performs a check on the signature of the JWT using RH SSO

public key

47
 RED HAT API MANAGEMENT
System Architecture

Real Time Admin

API Backend Portal

Developer Apps
Config / Authorize
API Manager
API Gateway Policy Management
Policy
Enforcement
Mobile Apps

Swagger Doc Branded Dev Portal

Identity Provider
(IdP)

48
 RED HAT API MANAGEMENT
2.1: Openshift On-Premises + OpenID Connect

Real Time Admin Portal

API Backend

API Gateway API Provider

( Fuse / OpenShift )
Administrators
Sync / Authorize
API Management

Developers
API Mobile Apps
Consumers

RH SSO Swagger Doc Branded Dev Portal

Developer Apps
DEMO
 INITIAL SCENARIO

Report Accident Alert

OpenShift Route Service
Accident

Access Accident Center

Web OpenShift Route App
App

User JWT
Browser Toke
OpenShift Route n
Red Hat
Login Single Sign On

CONFIDENTIAL - FOR INTERNAL USE ONLY

 INSECURE SCENARIO

Malicious
Accident Alert
App OpenShift Route Service
Report
Accident

Access Accident Center

Web OpenShift Route App
App

There is only
User JWT
Browser Toke security at the
OpenShift Route
Red Hat
n
UI level
Login Single Sign On

CONFIDENTIAL - FOR INTERNAL USE ONLY

 ISOLATE BACKEND API

Malicious
Accident Alert
App OpenShift Route Removing
Service
Report
Accident
external access,
also breaks the
trusted app
Access Accident Center
Web OpenShift Route App
App

User JWT
Browser Toke
OpenShift Route n
Red Hat
Login Single Sign On

CONFIDENTIAL - FOR INTERNAL USE ONLY

 SECURING THE SERVICE

Report OpenShift Accident Alert

API Gateway
Accident Route Service

Access Accident Center

OpenShift JWT
Web App
Route Toke
App
n

User JWT
Browser Toke
Create API Management
OpenShift n
Route App
Red Hat
Login Single Sign On

CONFIDENTIAL - FOR INTERNAL USE ONLY

 SECURING THE SERVICE

Malicious
OpenShift Accident Alert
App API Gateway
Service
Route
Report
Accident
Malicious app
now has no
Access
token or invalid Web
OpenShift Accident Center
App
JWT
Route Toke
token, API App
n
gateway
User JWT
controls rate Browser Toke
OpenShift Create API Management
limits and Route Red Hat
n
App

mapping rules Login Single Sign On

CONFIDENTIAL - FOR INTERNAL USE ONLY

 FINAL DEPLOYMENT

Accident Center
Access App
Web App

JWT
Toke
n API Management
Create
Login
Red Hat App
Single Sign On

User JWT
Toke
Browser n
Accident Alert
API Gateway
Service

Report
Accident

CONFIDENTIAL - FOR INTERNAL USE ONLY

THANK YOU
plus.google.com/+RedHat facebook.com/redhatinc

linkedin.com/company/red-hat twitter.com/RedHatNews

youtube.com/user/
RedHatVideos