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

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

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

4. 3© Hitachi, Ltd. 2018. All rights reserved. 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

5. 4© Hitachi, Ltd. 2018. All rights reserved. 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

6. 5© Hitachi, Ltd. 2018. All rights reserved. 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

8. 7© Hitachi, Ltd. 2018. All rights reserved. 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

9. 8© Hitachi, Ltd. 2018. All rights reserved. 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

10. 9© Hitachi, Ltd. 2018. All rights reserved. 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

11. 10© Hitachi, Ltd. 2018. All rights reserved. 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

12. 11© Hitachi, Ltd. 2018. All rights reserved. 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 Implemented these requirements, using 3scale+Keycloak and collaborating with OSS community

13. 12© Hitachi, Ltd. 2018. All rights reserved. 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

14. 13© Hitachi, Ltd. 2018. All rights reserved. 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

15. 14© Hitachi, Ltd. 2018. All rights reserved. Authentication: Issues (1) Redirect to login screen 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 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)

16. 15© Hitachi, Ltd. 2018. All rights reserved. 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

17. 16© Hitachi, Ltd. 2018. All rights reserved. Highly customized login screen (1) Redirect to login screen End user Keycloak (3) Authorization code Application (4) Token request with client secret (5) Access token and id token 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

18. 17© Hitachi, Ltd. 2018. All rights reserved. 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

19. 18© Hitachi, Ltd. 2018. All rights reserved. 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)

20. 19© Hitachi, Ltd. 2018. All rights reserved. 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

21. 20© Hitachi, Ltd. 2018. All rights reserved. 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

22. 21© Hitachi, Ltd. 2018. All rights reserved. Manage tokens Keycloak itself has features to revoke tokens • Revoke tokens triggered by administrator -> Can be revoked from admin console • Revoke tokens based on policy -> 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.

23. 22© Hitachi, Ltd. 2018. All rights reserved. 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

24. 23© Hitachi, Ltd. 2018. All rights reserved. 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

25. 24© Hitachi, Ltd. 2018. All rights reserved. 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

26. 25© Hitachi, Ltd. 2018. All rights reserved. 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

27. 26© Hitachi, Ltd. 2018. All rights reserved. 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.

28. 27© Hitachi, Ltd. 2018. All rights reserved. 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

29. 28© Hitachi, Ltd. 2018. All rights reserved. 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.

30. 29© Hitachi, Ltd. 2018. All rights reserved. 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]

31. 30© Hitachi, Ltd. 2018. All rights reserved. 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

32. 31© Hitachi, Ltd. 2018. All rights reserved. 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.

33. 32© Hitachi, Ltd. 2018. All rights reserved. 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

34. 33© Hitachi, Ltd. 2018. All rights reserved. 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

35. 34© Hitachi, Ltd. 2018. All rights reserved. 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”

36. 35© Hitachi, Ltd. 2018. All rights reserved. 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.

37. 36© Hitachi, Ltd. 2018. All rights reserved. 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.

38. 37© Hitachi, Ltd. 2018. All rights reserved. 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)

Estás leyendo una previsualización.

Eche un vistazo a continuación

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

Más Contenido Relacionado

Presentaciones para usted (20)

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

Más de Yuichi Nakamura (8)

Más reciente (20)