Security Considerations for API Gateway Aggregation
Download as PPTX, PDF1 like122 views
This document discusses security considerations for API gateway aggregation. It proposes building an API gateway aggregator in front of existing API gateways to expose APIs outside a company while minimizing security risks and impact on existing services. It describes how the aggregator can implement OAuth 2.0 authorization with a centralized authorization server and token exchange to authorize external applications without complexifying authorization for internal services. Advanced use cases discussed include supporting the Financial-grade API security profile for highly sensitive data and implementing zero-trust networking.
Security Considerations for API Gateway Aggregation
- 1. © Hitachi, Ltd. 2023. All rights reserved. Security Considerations for API Gateway Aggregation APIsecure 2023 Hitachi, Ltd. Yoshiyuki Tabata Slides are available at https://www.slideshare.net/ssuserbeb7c0
- 2. 1 © Hitachi, Ltd. 2023. All rights reserved. About the speaker • Specialist in API authorization Consulting for API management infrastructure and authentication/authorization systems in the financial, public, social, and industrial fields • Contributor to OSS related to authentication, authorization, and API management Keycloak (IAM OSS) 3scale (API management OSS) • Other activities Speaker at events such as Apidays, API Specifications Conference, OAuth Security Workshop, etc. Author of Keycloak books (Japanese) and writer of web articles about IAM (Japanese) Yoshiyuki Tabata Software Engineer Hitachi, Ltd. GitHub: @y-tabata
- 3. © Hitachi, Ltd. 2023. All rights reserved. Contents 2 1. Introduction to API Gateway Aggregation 2. Security Considerations for API Gateway Aggregation 3. Advanced use cases of API Gateway Aggregation
- 4. © Hitachi, Ltd. 2023. All rights reserved. Contents 3 1. Introduction to API Gateway Aggregation 2. Security Considerations for API Gateway Aggregation 3. Advanced use cases of API Gateway Aggregation
- 5. 4 © Hitachi, Ltd. 2023. All rights reserved. “Minimum” API Management Introduction to “Minimum” API Management API GW API API Authz Server own service API call API call API call issue token • “API management” is required when providing multiple APIs, considering the operational aspect. • In this case, luxurious API management is not necessary, but “Minimum” API Management is sufficient that provides only an API Gateway and an Authorization Server, especially for small-start projects.
- 6. 5 © Hitachi, Ltd. 2023. All rights reserved. “Minimum” API Management Introduction to “Minimum” API Management NGINX API API Keycloak own service API call API call API call issue token • For example, this “Minimum” API Management can be built with only Keycloak and NGINX.
- 7. 6 © Hitachi, Ltd. 2023. All rights reserved. Major features Provide support for OAuth 2.0, OpenID Connect and SAML. Connect to existing LDAP or Active Directory servers. Login with social networks. What is Keycloak • Keycloak is IAM (Identity and Access Management) OSS. • Keycloak provides OAuth 2.0 authorization server feature and single sign-on. Based on Standard Protocols Keycloak LDAP Active Directory RDB OpenID Connect SAML GitHub Twitter Facebook User Federation Social Login
- 8. 7 © Hitachi, Ltd. 2023. All rights reserved. Common issue for companies providing multiple services • In the case company provides multiple services, multiple minimum API management systems exist in-house together. “Minimum” API Management API GW API API Authz Server own services API call API call API call issue token “Minimum” API Management API GW API API Authz Server own services API call API call API call issue token
- 9. 8 © Hitachi, Ltd. 2023. All rights reserved. Common issue for companies providing multiple services • Recently, use cases for exposing APIs outside the company become popular, such as providing APIs to 3rd-party applications and the spread of remote work. • Existing APIs may not be exposed outside the company without changes because of low-level security and usability. API GW API API Authz Server own services API call API call API call issue token API GW API API Authz Server own services API call API call API call issue token remote work outside the company API call ? 3rd party apps
- 10. 9 © Hitachi, Ltd. 2023. All rights reserved. Common issue for companies providing multiple services • At a minimum, the following points should be considered when exposing APIs. • Minimum security (API authorization, OWASP Top 10) • Minimum impact on services provided to existing users API GW API API Authz Server own services API call API call API call issue token API GW API API Authz Server own services API call API call API call issue token remote work outside the company API call ? 3rd party apps
- 11. 10 © Hitachi, Ltd. 2023. All rights reserved. Proposal: API GW Aggregation • At a minimum, the following points should be considered when exposing APIs. • Minimum security (API authorization, OWASP Top 10) • Minimum impact on services provided to existing users -> Build API GW Aggregator in front of API GWs. API GW API API Authz Server own services API call API call API call issue token API GW API API Authz Server own services API call API call API call issue token remote work 3rd party apps outside the company API GW Aggregator API call API call API call API call
- 12. © Hitachi, Ltd. 2023. All rights reserved. Contents 11 1. Introduction to API Gateway Aggregation 2. Security Considerations for API Gateway Aggregation 3. Advanced use cases of API Gateway Aggregation
- 13. 12 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • This chapter considers how to meet requirements with API GW Aggregation, especially focusing on the API authorization perspective. • Minimum security (API authorization, OWASP Top 10) • Minimum impact on services provided to existing users API GW API API Authz Server own services API call API call API call issue token API GW API API Authz Server own services API call API call API call issue token remote work 3rd party apps outside the company API GW Aggregator API call API call API call API call
- 14. 13 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • This chapter considers how to meet requirements with API GW Aggregation, especially focusing on the API authorization perspective. • Minimum security (API authorization, OWASP Top 10) • Minimum impact on services provided to existing users API GW API API Authz Server own services API call API call API call issue token API GW API API Authz Server own services API call API call API call issue token remote work 3rd party apps outside the company API GW Aggregator API call API call API call API call
- 15. 14 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • Minimum security (API authorization, OWASP Top 10) • API authorization -> Authorization server based on OAuth 2.0 • OWASP Top 10 -> WAF (Web Application Firewall) API GW API API Authz Server own services API call API call API GW API API Authz Server own services API call API call remote work 3rd party apps API GW Aggregator Authz Server API call API call issue token API call API call + WAF issue tokens using OAuth2 authz code grant verify issuer, audience, expiration, revocation
- 16. 15 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • This chapter considers how to meet requirements with API GW Aggregation, especially focusing on the API authorization perspective. • Minimum security (API authorization, OWASP Top 10) • Minimum impact on services provided to existing users API GW API API Authz Server own services API call API call API call issue token API GW API API Authz Server own services API call API call API call issue token remote work 3rd party apps outside the company API GW Aggregator API call API call API call API call
- 17. 16 © Hitachi, Ltd. 2023. All rights reserved. ✔ ✔ ✔ How to meet requirements with API GW Aggregation • Minimum impact on services provided to existing users • API authorization of external applications in API GW Aggregator and that of each own services in individual API GW works with no problems because using their dedicated authz servers. API GW API API Authz Server own services API call API call API call issue token API GW API API Authz Server own services API call API call API call issue token remote work 3rd party apps API GW Aggregator (w/ WAF) Authz Server issue token API call API call
- 18. 17 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • Minimum impact on services provided to existing users • API authorization of external applications in individual API GW is complex. API GW API API Authz Server API call API call API GW API API Authz Server API call API call remote work 3rd party apps API GW Aggregator (w/ WAF) Authz Server issue token API call API call API call API call
- 19. 18 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • Minimum impact on services provided to existing users • API authorization of external applications in individual API GW is complex. -> If API GW Aggregator reuses the access token from the external app sends, individual API GW needs to deal with tokens issued by multiple AS. API GW API API Authz Server API call API call 3rd party apps API GW Aggregator (w/ WAF) Authz Server issue token API call (w/ access token) API call (w/ access token) own services issue token API call using the same access token MUST deal with tokens issued by multiple AS.
- 20. 19 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • Minimum impact on services provided to existing users • API authorization of external applications in individual API GW is complex. -> If API GW Aggregator reuses the access token from the external app sends, individual API GW needs to deal with tokens issued by multiple AS. -> We should avoid this situation because it extends the surface of possible attacks such as IdP mix-up attacks and may have an impact on own services. API GW API API Authz Server API call API call 3rd party apps API GW Aggregator (w/ WAF) Authz Server issue token API call (w/ access token) API call (w/ access token) own services issue token API call using the same access token MUST deal with tokens issued by multiple AS.
- 21. 20 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • Minimum impact on services provided to existing users • API authorization of external applications in individual API GW is complex. -> Instead, API GW Aggregator exchanges tokens in each API GW's AS. (cf. RFC 8693 OAuth 2.0 Token Exchange) API GW API API Authz Server API call API call 3rd party apps API GW Aggregator (w/ WAF) Authz Server issue token API call (w/ access token) API call (w/ access token) token exchange using the different access token deal with tokens issued by only one AS.
- 22. 21 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • Minimum impact on services provided to existing users • API authorization of external applications in individual API GW is complex. -> Instead, API GW Aggregator exchanges tokens in each API GW's AS. (cf. RFC 8693 OAuth 2.0 Token Exchange) -> Token translation such as exchanging lightweight access tokens*1 with more claims-packed access tokens can be realized and can protect privacy. API GW API API Authz Server API call API call 3rd party apps API GW Aggregator (w/ WAF) Authz Server issue token API call (w/ access token) API call (w/ access token) token exchange using the different access token deal with tokens issued by only one AS. lightweight access tokens *1: an assertion-based access token w/o privacy information or a handle-based access token
- 23. 22 © Hitachi, Ltd. 2023. All rights reserved. How to meet requirements with API GW Aggregation • This API GW Aggregator also can be built with Keycloak and NGINX. API GW API API Authz Server own services API call API call API GW API API Authz Server own services API call API call remote work 3rd party apps NGINX Plus Keycloak API call API call issue token API call API call issue token issue token token exchange token exchange NGINX App Protect (WAF) protect each API individually using OpenAPI specs.
- 24. © Hitachi, Ltd. 2023. All rights reserved. Contents 23 1. Introduction to API Gateway Aggregation 2. Security Considerations for API Gateway Aggregation 3. Advanced use cases of API Gateway Aggregation
- 25. 24 © Hitachi, Ltd. 2023. All rights reserved. Advanced use case: access to highly sensitive data • When publishing APIs that give access to highly sensitive data or that can be used to trigger highly important transactions, the system needs to support a highly secured OAuth profile such as FAPI (Financial-grade API) security profile. API GW API API Authz Server own services API call API call API GW API API Authz Server own services API call API call remote work 3rd party apps NGINX Plus (w/ NGINX App Protect) Keycloak API call API call issue token API call API call issue token issue token token exchange token exchange provide highly sensitive data
- 26. 25 © Hitachi, Ltd. 2023. All rights reserved. What is FAPI • Financial-grade API (FAPI) security profile requires a high level of security based on OAuth 2.0, used as a protocol for "API Authorization" and OpenID Connect (OIDC), used as a protocol for "SSO". It defines secure usage of OAuth 2.0 and OIDC to apply to APIs in any market area. Financial-grade API Security Profile 1.0 Part 2: Advanced RFC 7519: JSON Web Token (JWT) RFC 7636: Proof Key for Code Exchange by OAuth Public Clients RFC 6819: OAuth 2.0 Threat Model and Security Considerations RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC 6749: The OAuth 2.0 Authorization Framework OpenID Connect Core 1.0 RFC 8705: OAuth 2.0 Mutual- TLS Client Authentication and Certificate-Bound Access Tokens RFC 9126: OAuth 2.0 Pushed Authorization Requests Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
- 27. 26 © Hitachi, Ltd. 2023. All rights reserved. Advanced use case: access to highly sensitive data • To support FAPI, the authz server, the client application, and the resource server all must meet FAPI requirements. -> API GW Aggregator built with Keycloak and NGINX can support FAPI. API GW API API Authz Server own services API call API call API GW API API Authz Server own services API call API call remote work 3rd party apps NGINX Plus (w/ NGINX App Protect) Keycloak API call API call issue token API call API call issue token issue token token exchange token exchange Hitachi publishes a certified implementation of FAPI RP. https://github.com/Hitachi/hitachi-fapi-java provide highly sensitive data
- 28. 27 © Hitachi, Ltd. 2023. All rights reserved. Advanced use case: zero-trust network • To protect from a domino effect, where one compromised API compromises multiple other critical components, implement a zero-trust network. API GW API API Authz Server own services API call API call API GW API API Authz Server own services API call API call remote work 3rd party apps NGINX Plus (w/ NGINX App Protect) Keycloak API call API call issue token API call API call issue token issue token token exchange compromised API
- 29. 28 © Hitachi, Ltd. 2023. All rights reserved. Advanced use case: zero-trust network • To implement a zero-trust network, mutual TLS (mTLS) and JWT validation are the essential technology. -> Establishing mTLS connections between NGINX, and validating the access token (JWT) in cooperation with Keycloak. NGINX API API Keycloak own services NGINX API API Keycloak own services remote work 3rd party apps NGINX Plus (w/ NGINX App Protect) Keycloak issue token API call (mTLS + JWT) issue token issue token token exchange token exchange NGINX NGINX NGINX NGINX NGINX NGINX API call (mTLS + JWT) API call (mTLS + JWT) compromised API API call (mTLS + JWT) Keycloak supports policy decision and policy administration
- 30. 29 © Hitachi, Ltd. 2023. All rights reserved. Advanced use case: zero-trust network • To implement a zero-trust network, mutual TLS (mTLS) and JWT validation are the essential technology. -> Complicated certificate management for mTLS is reduced by integrating with Vault. NGINX API API Keycloak own services NGINX API API Keycloak own services remote work 3rd party apps NGINX Plus (w/ NGINX App Protect) Keycloak issue token API call (mTLS) issue token issue token token exchange token exchange Vault NGINX NGINX NGINX NGINX NGINX NGINX API call (mTLS) API call (mTLS) API call (mTLS) compromised API real-time Vault certificate-issuing requests and the dynamic certificate-loading feature in NGINX Plus.
- 31. 30 © Hitachi, Ltd. 2023. All rights reserved. Other advanced use cases • There are many other advanced use cases. The below are for different types of clients. API GW API API Authz Server own services API call API call API GW API API Authz Server own services API call API call remote work 3rd party apps NGINX Plus (w/ NGINX App Protect) Keycloak API call API call issue token API call API call issue token issue token token exchange token exchange For native apps, issue client credentials via dynamic client registration endpoint For browser-based apps, behave as BFF (backend for frontend) handling the full authz flow and managing tokens.
- 32. 31 © Hitachi, Ltd. 2023. All rights reserved. Summary We proposed “API GW Aggregation” can expose APIs outside the company with minimum security and minimum impact on services provided to existing users. the underlying technologies are OAuth2, WAF, and token exchange. can be built with Keycloak and NGINX. supports advanced use cases such as FAPI and zero-trust networks. Slides are available at https://www.slideshare.net/ssuserbeb7c0
- 33. 32 © Hitachi, Ltd. 2023. All rights reserved. Trademarks • 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. • Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries. • NGINX and NGINX Plus are registered trademarks of F5, 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.