Implementing security requirements for banking API system using Open Source Software (OSS)

© Hitachi, Ltd. 2018. All rights reserved.
Implementing security requirements for
banking API system using Open Source Software (OSS)
API Days Paris Dec 2018
Hitachi, Ltd.
OSS Solution Center
Yuichi Nakamura, Ph.D.

1© Hitachi, Ltd. 2018. All rights reserved.
Self introduction
Yuichi Nakamura :
OSS Solution Center, Hitachi, Ltd. @ Yokohama, Japan
• Loves OSS
• SELinux
• Developed SELinux tool, contributed SELinux for embedded systems
• Led Japanese SELinux community
• Contributed to academic community
• Identity Management & API Management
• Keycloak, 3scale
• Leading team to enhance security for banking API
• Holding Japanese meetup community “Secure OSS SIG”

Contents
2
1. Introduction: requirements and OSS
2. Usage of OSS to meet requirements

Background: Banking API and its security in Japan
• The revised banking act was published in Jun 2017 to promote API.
- Similar to PSD2 in EU
• 83% of banks (114 banks) answered they will open API by 2020/6(*).
(*) Based on survey of Japanese Bankers Association as of Dec 2017
• Security : OAuth 2.0 is recognized as a key technology to secure API
Quoted from Report about open API by the Japanese Bankers Association
https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_3.pdf

Usage of OAuth 2.0: Authentication, authorization
End users Applications API Server
Who is allowed what?
-> Access control
(Authorization)
Uses Apps
via browser or
mobile devices
Call REST API
Access token
* OAuth 2.0 (RFC6749) only describes how tokens are issued.
We have to use other standards or create something outside of standards.
Who is using API?
-> User authentication
What is using API?
-> Client authentication
OAuth 2.0

Requirements for Authentication/Authorization for banking API
# Category Description
1 Authentication • Can support various(customized) authentication in
OAuth flow
• Compliance to OpenID Connect on top of OAuth
2 Access control • Deny/allow access based on claims in tokens
• Can be combined with rate limit to protect backend
3 Manage tokens • Revoke tokens triggered by users, administrators
• Revoke tokens based on policy
4 Compliance to the
latest standards
• Financial-grade API (FAPI) of OpenID Foundation

Contents
6
1. Introduction: requirements and OSS
2. Usage of OSS to meet requirements

Open API system
API
Gateway
Legacy
Backend
REST API
Server
Applications
(Web App,
Mobile App)
Developer
Portal
API Management
Manager
App developers
End Users
Bank
• API Management product is usually used for common functions to open APIs
• Rate limit, dev portal, analytics etc
• It is desirable authentication/authorization is integrated into API management
Authentication/
Authorization

Open Source Software (OSS) for open API
• There are various OSSs
• We chose “3scale” and “Keycloak”
• Completeness of feature
• Activity and future of community
OSS
API Management Kong
3scale
WSO2
tyk
Authentication/
Authorization
Keycloak
Gluu
OpenAM

What is Keycloak
An OSS for Identity Management, community is led by Red Hat: www.keycloak.org
LDAP
Active
Directory
RDB
Identity Federation
OpenID Connect, OAuth2.0, SAML
Social Login
(Identity Brokering)
Identity Management
Authentication

What is 3scale
API
Gateway
(apicast)
Legacy
Backend
REST API
Server
Applications
(Web App,
Mobile App)
Developer
Portal(porta)
API Management
Manager
(porta)
App developers
End Users
Authentication/
Authorization
Container Platform
• OSS implementation of API Management led by Red Hat (https://github.com/3scale)
• Include full functions of API management (not only API GW)
• Cloud native : Works on OpenShift or okd
• OAuth2, OIDC in combination with Keycloak

Requirements for Authentication/Authorization for banking API
# Category Description
1 Authentication • Can support various(customized) authentication in
OAuth flow
• Compliance to OpenID Connect on top of OAuth
2 Access control • Deny/allow access based on claims in tokens
• Can be combined with rate limit to protect backend
3 Manage tokens • Revoke tokens triggered by users, administrators
4 Compliance to the
latest standards
• Financial-grade API (FAPI) of OpenID Foundation
Implemented these requirements, using 3scale+Keycloak
and collaborating with OSS community

Authentication : Registering Apps
• Authentication within OAuth/OIDC flow works, basically
Keycloak
Devportal/
Management console
(system)
Developer/Administrator
(1) Generate client ID/secret
Via Web console, and register app
API
Gateway
(apicast)
zync
MySQL
3scale
(2) Register client ID/secret
to manage from 3scale
(3) Sync client ID/secret to
Keycloak

Authentication : Authentication/Issue token
Authorization code flow is used.
(1) Redirect to login screen
End user
Keycloak User data
store
(2) Authenticates user using
user data storage
(3) Authorization code
Application (4) Token request with client secret
(5) Access token and id token
• Authentication within OAuth/OIDC flow works, basically

Authentication: Issues
Keycloak User data
store
(2) Authenticates user using
user data storage
RFC7636(PKCE) is required to protect code
Login screen is generated by Keycloak.
Screen can be customized by template.
However, the template is not enough,
highly customized screen is often required.
(Look & feel and login logic)

PKCE support for Keycloak
• Keycloak did not support PKCE..
-> We submitted PR and merged.
https://github.com/keycloak/keycloak/pull/3831
• From Keycloak 3.1.0, PKCE is supported.
• Enabled by default (no switch)
• Only when PKCE is requested from client, it works
• Included in OIDC server metadata from 4.0.0

Highly customized login screen
End user
Keycloak
Login
Screen
AP server
(2) Forward login screen&
result
Delegates login screen by using
Identity brokering feature of Keycloak
Login screen/logic can be coded
as customers like.
Submitted patch to enable forward parameter from application
https://github.com/keycloak/keycloak/pull/5163

Access Control
• Keycloak only issues tokens. Access control is out of scope.
API
Gateway
(apicast)
REST API
Server
Applications
(Web App,
Mobile App)
Access control have to be implemented in
apicast or REST server
Apicast did not support access control using tokens
-> we developed with community
API Request with
access token
More convenient, to reduce development in REST API server

Access Token of Keycloak
{
"jti": "c26a32c4-4b48-4c2f-a7da-3b9b8ecad652",
"exp": 1535424101,
"nbf": 0,
"iat": 1535423801,
"iss": "http://localhost:8080/auth/realms/provider",
"aud": "broker",
"sub": "e4b11e2e-9136-409b-8720-57463c627c10",
"typ": "Bearer",
"azp": "broker",
"auth_time": 0,
"session_state": "ac1767e2-2e30-4d44-b6f3-b77935a7a0bc",
"acr": "1",
"allowed-origins": [],
"realm_access": {
"roles": [
"read",
"additional",
"write"
]
},
"name": "Takashi Mogi",
"preferred_username": "mogi",
"given_name": "Takashi",
"family_name": "Mogi",
"email": "mogi@example.com"
}
• The format of access token is not
standardized neither RFC nor OIDC.
• It depends on implementation.
• In Keycloak, the format is similar to ID token
of OIDC (JWT, claims)

Keycloak role check policy
• Implemented in apicast extension called policy
• Checks “role” field of access token and URL.
• We submitted patch and included from 3scale 2.3. https://github.com/3scale/apicast/pull/773
{
"jti": "c26a32c4-4b48-4c2f-a7da-3b9b8ecad652",
"exp": 1535424101,
…
"allowed-origins": [],
"realm_access": {
"roles": [
"read",
"additional",
"write"
]
},
End User
Client
Application
Keycloak
APIcast API Backend
Resources:
/resource1
Role Check:
Require “role1” to access to “/resource1”
1.Request“role1”
4.Issueaccess
tokenincluding
“role1”
5. “GET /resource1”
with access token
6. Allow to access
to “/resouce1”
Use

Edge limit policy
Rate limit: A kind of access control
Apicast did not support rate limit to protect backend.
Limit concurrent connection, request/sec based on request property including access token.
-> We implemented patches with community and
“Edge limit policy” is included in 3scale 2.3.
API
Gateway
(apicast)
REST API
Server
Applications
(Web App,
Mobile App)
API Request with
access token
Any value can be extracted as a key to control access
https://github.com/3scale/apicast/pull/719
Protects backend by rate limit, type of limit:
leaky bucked algorithm, fixed window, concurrent connection
https://github.com/3scale/apicast/pull/648

Manage tokens
Keycloak itself has features to revoke tokens
• Revoke tokens triggered by administrator
-> Can be revoked from admin console
-> Timeout can be configured in admin console
• Revoke tokens triggered by users
- Keycloak does not support RFC 7009(OAuth 2.0 Token Revocation)
- Instead, logout endpoint is used.
/auth/realms/＜realm＞/protocol/openid-connect/logout
Related access tokens, id tokens, refresh tokens are revoked.

Token introspection policy
• Only authorization server knows that tokens are revoked…
API Servers have to ask authorization server -> token introspection (RFC7662)
• To facilitate, we developed token introspection in apicast with community, and
3scale 2.3 supports the feature (Token introspection policy).
1) API Request with
token
2) Token Introspection
(Check token is alive)API
Gateway
(apicast)
Applications
(Web App,
Mobile App)
Keycloak
Result can be cached to reduce
performance impact

Notes of Persistence of refresh tokens in Keycloak
• By default, refresh tokens are lost when all Keycloak servers are
rebooted, and in version up.
• End users have to login again.
• To persist refresh tokens, you have to add “offline_access” in scope
• Such refresh tokens are called “offline token” in Keycloak
• Refresh tokens are persisted in RDB, and upgrade path is also
prepared
• Also note that before 4.0.0, revocation policy of offline token is not
enough, after 4.1.0 is recommended to use offline token

How API is called in 3scale 2.3 + Keycloak
1) API Request with
token
2) Token Introspection
(Token Introspection policy)
3scale API
Gateway
(apicast)
REST API
Server
Applications
(Web App,
Mobile App)
Keycloak
3) Access control
(role check policy, edge limit policy)
4) Extract necessary information from
access token and set header (Header
policy)
5) API Request with necessary
information in header

Compliance to the latest standard: FAPI
OAuth
OpenID
Connect
(OIDC)
Spec to exchange access token(authorization info).
A lots are left to implementers,
insecure usage can easiliy happen.
In addition to OAuth,
ID token (authentication info) can be included.
Usage of OAuth is a bit hardened.
Secure usage of OAuth and OIDC
is standardized.
ＦＡＰＩ
FAPI (Financial-Grade API) is being standardized in OpenID Foundation.
Part1 (ReadOnly), Part2(ReadWrite), JARM

FAPI in Japan
• FAPI is still implementer’s draft as of today
• However, being strongly promoted in banking industry
https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_3.pdf
Quoted from “Report of Review Committee on Open APIs: Promoting Open Innovation”, Japanese Bankers Association
• We have to prepare for FAPI in advance, because can not implement soon.

Issues toward FAPI in Keycloak
Investigated implementation of Keycloak, and reported issues. (As of Mar 2017, Keycloak 3.0)
JIRA Description
KEYCLOAK-2604 RFC 7636(PKCE) support
KEYCLOAK-5661 shall return the list of allowed scopes with the issued access token
KEYCLOAK-5811 Client authentication client_secret_jwt
KEYCLOAK-6700 Support of s_hash
KEYCLOAK-6768 Support of Encrypted ID token
KEYCLOAK-6770 Signature algorithm (PS256 or ES256) support
KEYCLOAK-8460 Signature algorithm (PS256 or ES256) support (for request object)
KEYCLOAK-6771 Support for holder of key mechanism

Current status of issues
JIRA Description Pull Request Included
version
KEYCLOAK-2604 RFC 7636(PKCE) support 3831 3.1.0
KEYCLOAK-5661 shall return the list of allowed scopes
with the issued access token
4527 3.4.0
KEYCLOAK-5811 Client authentication client_secret_jwt 4835 4.0.0
KEYCLOAK-6700 Support of s_hash 5022 4.0.0
KEYCLOAK-6768 Support of Encrypted ID token 5779 Not yet
KEYCLOAK-6770 Signature algorithm (PS256 or ES256)
support
5533 4.5.0
KEYCLOAK-8460 Signature algorithm (PS256 or ES256)
support (for request object)
5603 4.7.0
KEYCLOAK-6771 Support for holder of key mechanism 5083 4.0.0
We are developing patches with community, major parts are resolved.
Our colleague @tnorimat is mainly working.
High lights are introduced.

Holder of Key mechanism
Bearer token
Trust a one who have tokens (access token, refresh token)
-> If bad guys steal token, they can use tokens.
Holder of Key
* Bind a secret which proves the possession with the token.
* API server verifies the binding
・ Two standards in IETF
１）[MTLS] : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
Pros： Based on existing widely used technology (TLS)
Cons： Client certificates are necessary
２）[OAUTB]：OAuth 2.0 Token Binding
Pros： Authorization codes can be bounded, client certificates are not necessary
Cons： Extension in TLS layer is necessary for all parties
FAPI requires [MTLS] OR [OAUTB]

Holder of Key mechanism in Keycloak
[MTLS] was implemented. We gave up [OAUTB] because of TLS extension
(Did anyone implemented [OAUTB]??)
Pull Request: https://github.com/keycloak/keycloak/pull/5083/
Included in Keycloak 4.0.0 as “OAuth2 Certificate Bound Access Tokens”.
https://www.keycloak.org/docs/4.0/release_notes/index.html

Problem of signature algorithm
Keycloak supported only RS256 for signature.
-> Crypto specialists say RS256 is not strong enough. PS256 or ES256 is required in FAPI.
RS256 was hardcoded !
-> Refactored with community and now signature algorithm is pluggable (Signature SPI).
Other strong algorithms are supported :basic part 4.5.0, request object 4.7.0.
ES256, ES384, ES512, RS384, HS256, HS384,HS512 are supported.

Server metadata as of Keycloak 3.0.0
{
"issuer":"http://localhost:8080/auth/realms/master",
"authorization_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/auth",
"token_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/token",
"token_introspection_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/token/introspect",
"userinfo_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/userinfo",
"end_session_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/logout",
"jwks_uri":"http://localhost:8080/auth/realms/master/protocol/openid-connect/certs",
"check_session_iframe":"http://localhost:8080/auth/realms/master/protocol/openid-connect/login-status-iframe.html",
"grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials"],
"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code id_token token"],
"subject_types_supported":["public","pairwise"],
"id_token_signing_alg_values_supported":["RS256"],
"userinfo_signing_alg_values_supported":["RS256"],
"request_object_signing_alg_values_supported":["none","RS256"],
"response_modes_supported":["query","fragment","form_post"],
"registration_endpoint":"http://localhost:8080/auth/realms/master/clients-registrations/openid-connect",
"token_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post"],
"token_endpoint_auth_signing_alg_values_supported":["RS256"],
"claims_supported":["sub","iss","auth_time","name","given_name","family_name","preferred_username","email"],
"claim_types_supported":["normal"],
"claims_parameter_supported":false,
"scopes_supported":["openid","offline_access"],
"request_parameter_supported":true,
"request_uri_parameter_supported":true
}
/auth/realms/master/.well-known/openid-configuration

Server metadata as of Keycloak 4.7.0
{
"issuer":"http://localhost:8080/auth/realms/master",
"authorization_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/auth",
"token_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/token",
"token_introspection_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/token/introspect",
"userinfo_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/userinfo",
"end_session_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/logout",
"jwks_uri":"http://localhost:8080/auth/realms/master/protocol/openid-connect/certs",
"check_session_iframe":"http://localhost:8080/auth/realms/master/protocol/openid-connect/login-status-iframe.html",
"grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials"],
"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code id_token token"],
"subject_types_supported":["public","pairwise"],
"id_token_signing_alg_values_supported":["ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","RS512"],
"userinfo_signing_alg_values_supported":["ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","RS512","none"],
"request_object_signing_alg_values_supported ":["ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","RS512","none"],
"response_modes_supported":["query","fragment","form_post"],
"registration_endpoint":"http://localhost:8080/auth/realms/master/clients-registrations/openid-connect",
"token_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","client_secret_jwt"],
"token_endpoint_auth_signing_alg_values_supported":["RS256"],
"claims_supported":["sub","iss","auth_time","name","given_name","family_name","preferred_username","email"],
"claim_types_supported":["normal"],
"claims_parameter_supported":false,
"scopes_supported":["openid","address","email","offline_access","phone","profile"],
"request_parameter_supported":true,
"request_uri_parameter_supported":true,
"code_challenge_methods_supported":["plain","S256"],
"tls_client_certificate_bound_access_tokens":true,
"introspection_endpoint":"http://localhost:8080/auth/realms/master/protocol/openid-connect/token/introspect"
}
/auth/realms/master/.well-known/openid-configuration

Remaining works for FAPI
• Token encryption support -> Submitted PR, waiting for review
• Pass FAPI conformance test
-> FAPI conformance test is under development
• New specification : “JARM” and “CIBA”

Other issues
• Cookies of Keycloak
• Keycloak was developed for SSO and issues cookies to browsers
• Cookies are not required for authz server of API, and we encountered
side-effects
• Container technologies
• 3scale only works on container, but container technologies (e.g.
kubernetes + lots of OSSs) are not easy to learn, and version up is
VERY frequent.
• Have to discuss with community, to improve more.

Summary
• OAuth is recognized as a key technology for banking API systems
• Requirements to be considered around OAuth
• Authentication
• Access control
• Token management
• Latest standard (OIDC, FAPI)
• Applied OSS (3scale + Keycloak) to achieve them
• Improved with OSS community
• 3scale: enhanced rate limit, access control
• Keycloak: Features required for FAPI
-> Improvements are included in the latest version
• Let’s work with OSS community ! Keycloak and 3scale are great community.

Trademarks
• Red Hat is a trademark or registered trademark of Red Hat, Inc. in the United States and other
countries.
• OpenShift is a trademark or registered trademark of Red Hat, Inc. in the United States and other
countries.
• WSO2 is a trademark or registered trademark of WSO2 in the United States and other countries.
• OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other
countries.
• Github is a trademark or registered trademark of Github, Inc. in the United States and other countries.
• Twitter is a trademark or registered trademark of Twitter,Inc. in the United States and other countries.
• Facebook is a trademark or registered trademark of Facebook,Inc. in the United States and other
countries.
• Other brand names and product names used in this material are trademarks, registered trademarks,
or trade names of their respective holders.

Implementing security requirements for banking API system using Open Source Software (OSS)

Implementing security requirements for banking API system using Open Source Software (OSS)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Implementing security requirements for banking API system using Open Source Software (OSS)

Similar to Implementing security requirements for banking API system using Open Source Software (OSS) (20)

More from Yuichi Nakamura

More from Yuichi Nakamura (9)

Recently uploaded

Recently uploaded (16)

Implementing security requirements for banking API system using Open Source Software (OSS)