OpenID Connect with Curity

This guide focuses on configuring the plugin for introspection, and especially as it relates to the introspection using the Phantom Token pattern. Some tweaks are made so that a phantom token is provided in the introspection response and then passed on to the upstream API.

Configuring the Curity Identity Server to provide a Phantom Token in the introspection response is outlined in more detail in this article.

• An installation of the
• An introspection endpoint configured with the Token Procedure Approach

Configure Kong

The Kong OpenID Connect plugin is configured to introspect an incoming opaque access token and in return receive a JWT in the introspection response from the Curity Identity Server. The plugin is enabled for a service or a route.

As part of the introspection, the OpenID Connect plugin also has the ability to validate that required scopes are available in the introspected token. Access to the requested API are denied if the correct scopes are missing.

If access is granted, the JWT from the introspection response is added to a header and forwarded to the upstream API where it can be consumed.

Create a service

Create a service that can be used to test the integration.

Create a route

Add a route to the service.

  --data "paths[]=/httpbin"

Configure the plugin

The Kong OpenID Connect plugin is enabled for the previously created service. In the example below, the openid scope is required in order for access to be granted. As noted by the config.upstream_headers_claims configuration, the plugin looks for the JWT (the phantom token) claim in the introspection response. The config.upstream_headers_names configuration extracts the JWT from the introspection response and adds it to a phantom_token header in the call to the upstream API.

Any supported OAuth/OIDC flow can be used to obtain an opaque access token from the Curity Identity Server. Several approaches for obtaining a token are outlined in the . Make sure that the token issued contains the openid scope.

curl -X GET http://kong:8000/httpbin/get \
--header "Authorization: Bearer <OPAQUE ACCESS TOKEN"

Kong introspects the opaque token and receives the JWT in the response. The JWT is forwarded to the upstream API. Because the configured upstream API is httpbin, it is echoed back. The below sample response shows the phantom_token that contains the JWT and can be consumed by the API. The response is truncated for readability.

Resources

• Overview of the
• Information on the Introspection and Phantom Tokens flow
• Installing the

Kong Dev Portal Authentication

The is a part of Kong Enterprise. The portal enables developers to access and manage configured services and documentation to provide a streamlined onboarding process. The Kong Dev Portal supports various options for user authentication and access control. This guide outlines how to configure the Kong OpenID Connect Plugin to leverage the Curity Identity Server as a third-party Identity Provider for user Authentication to the Dev Portal.

The Kong Dev Portal needs a client configured in the Curity Identity Server. The outlines details on how to configure a client. The configuration details below should be sufficient:

• Authentication method: secret. Make note of the Secret and use it in the client_secret field in the Dev Portal configuration (see below).
• Capabilities: Code Flow.
• Following scopes: openid, profile, and .
• Choose suitable authentication methods.
• Add redirect URI (by default http://kong:8004/<WORKSPACE_NAME>/auth).

More information is available in the Code Flow tutorial.

Configure OpenID Connect in the Kong Dev Portal

Enabling the Kong Dev Portal is outlined in the Kong Dev Portal Documentation and not covered in this article. The documentation also covers how to configure the .

Example Configuration Object

Below is an example configuration object that is used to configure the OIDC plugin for the Dev Portal.

{
    "consumer_by": ["username","custom_id","id"],
    "leeway": 1000,
    "scopes": ["openid","profile","email"],
    "logout_query_arg": "logout",
    "login_redirect_uri": ["https://kong-dev-portal:8003"],
    "login_action": "redirect",
    "logout_redirect_uri": ["https://kong-dev-portal:8003"],
    "ssl_verify": false,
    "client_id": ["kong-dev-portal-client"],
    "forbidden_redirect_uri": ["https://kong-dev-portal:8003/unauthorized"],
    "client_secret": ["Pa$$w0rd!"],
    "issuer": "https://idsvr.example.com/oauth/v2/oauth-anonymous/",
    "logout_methods": ["GET"],
    "consumer_claim": ["email"],
    "login_redirect_mode": "query"

An Authentication Action to automatically provision the user to the Kong Dev Portal is available in the Curity GitHub repository. Using the Action is not mandatory as the user could be provisioned in other ways, such as manually through the Kong Dev Portal login page. However, using the Authentication Action would streamline the user flow since the Action takes the user’s full name and the email from the Curity Authenticator and automatically provision that to the Kong Dev Portal using the exposed API.

Configuration

This Action is straightforward to configure. An HTTP Client is needed to communicate with the Kong Dev Portal API. By default, the HTTP Authentication can be left out. Only a correct scheme needs to be configured (HTTP or HTTPS).

The Action also configures the URL to the registration endpoint of the Kong Dev Portal. Here the scheme needs to match what’s configured in the HTTP Client used.

When the action is created, it can be assigned to the Authenticators used in the client configured in the Curity Identity Server as described above.

Action to Resolve Additional User Information

Depending on the Authenticator used, an additional Action may be needed to resolve additional information. By default, The Kong Dev Portal provisioning requires Full Name and email. If the Authenticator does not provide this, it’s possible to use an Action to resolve the data. This could be as simple as a Data Source action configured to use a Data Source that provides the information.

By default, the Kong Dev Portal Provisioner Action works on the default account table schema of the Curity Identity Server database. This provides email as a column, but the Full Name is not readily available. The Action operates on the column and parse the information to pass the user’s Full Name to the Kong Dev Portal.

The attributes column contains this structure:

The data source used to resolve additional information needs to be configured with an appropriate Attribute Query. This would look similar to this:

select * from "accounts" where "username"= :subject

Conclusion