Kong API Gateway
Overview
Kong API Gateway integrates with Okta API Access Management (OAuth as a Service) to secure internal and external API traffic, in two different deployment scenarios: 1 - An authorization-tier integration, where authentication will be happening outside of Kong. A web application will handle authentication vs. Okta, acquiring an access token, and sending that access token to Kong on behalf of the end user. 2 - Kong itself handles authentication vs. Okta, and passes user info to upstream apps.
The Challenge
- API production and consumption is exploding, overburdening IT teams
- Microservices, partner integrations, and public APIs are driving this growth
- Securing all these APIs is harder – and more important – than ever
- Asking each engineering team to implement their own API security is wasteful and risky
The Solution
API consumers authenticate once through Okta, and receive an access token
Kong enforces token validity when consumers try consuming APIs
API consumers can easily access the APIs they’re authorized to access—and only those
Okta also secures the developer portal and Kong admin access
Secure APIs without sacrificing agility
Whether public-facing or internal-only, APIs should be accessible only to authorized parties. Previously, implementing API access control required each engineering team to independently build and maintain security at the service or application level. Now, by delegating security to Okta + Kong, engineering teams can move quickly without compromising the safety of enterprise assets.
Enjoy intuitive, standards-based integration
Okta and Kong work perfectly together because each implements identity and access management standards like OAuth and OpenID Connect. Employees, partners, and other authorized end users can easily understand and quickly implement the integration, because it’s based on open standards.
Add a developer portal and API analytics
Okta and Kong integrated together bring admin access, a developer portal for teaching consumers how to use your APIs, and an analytics feature to understand how your APIs are being used together in one complete, easy-to-manage API experience.
Capabilities
Access
- OIDC OpenID Connect is an extension to the OAuth standard that provides for exchanging Authentication data between an identity provider (IdP) and a service provider (SP) and does not require credentials to be passed from the Identity Provider to the application.
- WS-Federation
- SAML Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP) that does not require credentials to be passed to the service provider.
- SWA Secure Web Authentication is a Single Sign On (SSO) system developed by Okta to provide SSO for apps that don't support proprietary federated sign-on methods, SAML or OIDC.
Provisioning
- Create Creates or links a user in the application when assigning the app to a user in Okta.
- Update Okta updates a user's attributes in the app when the app is assigned. Future attribute changes made to the Okta user profile will automatically overwrite the corresponding attribute value in the app.
- Deactivate Deactivates a user's account in the app when it is unassigned in Okta or their Okta account is deactivated. Accounts can be reactivated if the app is reassigned to a user in Okta.
- Sync Password Push either the users Okta password or a randomly generated password to the app. This feature is not required for all federated applications as user authentication takes place in Okta, however some apps still require a password.
- Group Push Push existing Okta groups and their memberships to the application. Groups can then be managed in Okta and changes are reflected in the application.
- Group Linking Link Okta groups to existing groups in the application. Simplifies onboarding an app for Okta provisioning where the app already has groups configured.
- Schema Discovery Import the user attribute schema from the application and reflect it in the Okta app user profile. Allows Okta to use custom attributes you have configured in the application that were not included in the basic app schema.
- Attribute Mastering The application can be defined as the source of truth for a full user profile or as the source of truth for specific attributes on a user profile.
- Attribute Writeback When the application is used as a profile master it is possible to define specific attributes to be sourced from another location and written back to the app. For example the user profile may come from Active Directory with phone number sourced from another app and written back to Active Directory.
