Consumer authorization

You can use Kong consumers for authorization and dynamically map claim values to Kong consumers. This means that we restrict the access to only those that do have a matching Kong consumer. Kong consumers can have ACL groups attached to them and be further authorized with the Kong ACL plugin.

Prerequisites

In most cases, the OpenID Connect plugin relies on a third party identity provider (IdP). The examples in this guide use Keycloak as a sample IdP.

Expand the following sections to configure Keycloak and Kong Gateway.

Configure Keycloak

All the *.test domains in the following examples point to the localhost (127.0.0.1 and/or ::1).

We use Keycloak as the identity provider in the following examples, but the steps will be similar in other standard identity providers. If you encounter difficulties during this phase, refer to the Keycloak documentation.

Create a confidential client kong with private_key_jwt authentication and configure Keycloak to download the public keys from [the OpenID Connect Plugin JWKS endpoint][json-web-key-set]:
Create another confidential client service with client_secret_basic authentication. For this client, Keycloak will auto-generate a secret similar to the following: cf4c655a-0622-4ce6-a0de-d3353ef0b714. Enable the client credentials grant for the client:
(Optional) Create another confidential client cert-bound with settings similar to the service client created previously. From the Advanced tab, enable the OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled toggle.
(Optional, to test mTLS Client Authentication) Create another confidential client client-tls-auth with settings similar to the service client created above. From the Credentials tab, select the X509 Certificate Client Authenticator and fill the Subject DN field so that it matches the Kong client certificate’s, e.g.: CN=JohnDoe, OU=IT.
(Optional, to test Demonstrating Proof-of-Possession Client Authentication) Create another confidential client client-dpop-auth with settings similar to the service client created above. From the Advanced tab, enable theOAuth 2.0 DPoP Bound Access Tokens Enabled toggle.
Create a verified user with the name: john and the non-temporary password: doe that can be used with the password grant:

Alternatively you can download the exported Keycloak configuration, and use it to configure the Keycloak. Please refer to Keycloak import documentation for more information.

You need to modify Keycloak standalone.xml configuration file, and change the socket binding from:

<socket-binding name="https" port="${jboss.https.port:8443}"/>

<socket-binding name="https" port="${jboss.https.port:8440}"/>

The Keycloak default https port conflicts with the default Kong TLS proxy port, and that can be a problem if both are started on the same host.

Note: The mTLS Client Authentication, along with the proof of possession feature that validates OAuth 2.0 Mutual TLS Certificate Bound Access Tokens, both require configuring Keycloak to validate client certificates with mTLS using the --https-client-auth=request option, and to configure TLS appropriately, including adding the trusted client certificates to the truststore. For more information, refer to the Keycloak documentation.

Configure Kong Gateway

Create a service:

 curl -i -X POST http://localhost:8001/services \
   --data "name=openid-connect" \
   --data "url=https://httpbin.konghq.com/anything"

Create a route:

 curl -i -X POST http://localhost:8001/services/openid-connect/routes \
   --data "name=openid-connect" \
   --data "paths[]=/"

The following examples are built with simplicity in mind, and are not meant for a production environment. Because httpbin.konghq.com is the upstream service in these examples, we highly recommended that you do not run these examples with a production identity provider as there is a high chance of leaking information. The examples also use the plain HTTP protocol, which you should never use in production.

Let’s use the following example token payload:

{
   "exp": 1622556713,
   "aud": "account",
   "typ": "Bearer",
   "scope": "openid email profile",
   "preferred_username": "john",
   "given_name": "John",
   "family_name": "Doe"
}

Out of these attributes, the preferred_username claim looks promising for consumer mapping.

Configure the OpenID Connect plugin for integration with the ACL plugin. For the purposes of the demo, you can use the password grant.

For the demo, we’re going to set up the following:

Issuer, client ID, and client auth: settings that connect the plugin to your IdP (in this case, the sample Keycloak app).
Auth method: password grant (enabled for demo purposes).
The preferred_username claim from the example payload.

serviceで有効にする

Kong Admin API

Konnect API

Kubernetes

Declarative (YAML)

Konnect Terraform

次のリクエストを行います。

curl -X POST http://localhost:8001/services/{serviceName|Id}/plugins \
    --header "accept: application/json" \
    --header "Content-Type: application/json" \
    --data '
    {
  "name": "openid-connect",
  "config": {
    "issuer": "http://keycloak.test:8080/auth/realms/master",
    "client_id": "kong",
    "client_auth": "private_key_jwt",
    "auth_methods": [
      "password"
    ],
    "consumer_claim": [
      "preferred_username"
    ],
    "consumer_by": [
      "username"
    ]
  }
}
    '

SERVICE_NAME

IDを、このプラグイン構成の対象となるサービスの idまたはnameに置き換えてください。

独自のアクセストークン、リージョン、コントロールプレーンID、サービスIDを代入して、次のリクエストを行ってください。

curl -X POST \
https://{us|eu}.api.konghq.com/v2/control-planes/{controlPlaneId}/core-entities/services/{serviceId}/plugins \
    --header "accept: application/json" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer TOKEN" \
    --data '{"name":"openid-connect","config":{"issuer":"http://keycloak.test:8080/auth/realms/master","client_id":"kong","client_auth":"private_key_jwt","auth_methods":["password"],"consumer_claim":["preferred_username"],"consumer_by":["username"]}}'

地域固有のURLと個人アクセストークンの詳細については、 Konnect API referenceをご参照ください。

まず、KongPlugin リソースを作成します：

echo "
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: openid-connect-example
plugin: openid-connect
config:
  issuer: http://keycloak.test:8080/auth/realms/master
  client_id: kong
  client_auth: private_key_jwt
  auth_methods:
  - password
  consumer_claim:
  - preferred_username
  consumer_by:
  - username
" | kubectl apply -f -

次に、次のようにserviceに注釈を付けて、KongPluginリソースをイングレスに適用します。

kubectl annotate service SERVICE_NAME konghq.com/plugins=openid-connect-example

SERVICE_NAMEを、このプラグイン構成が対象とするサービスの名前に置き換えます。 kubectl get serviceを実行すると、利用可能なイングレスを確認できます。

注： KongPluginリソースは一度だけ定義するだけで、ネームスペース内の任意のサービス、コンシューマー、またはルートに適用できます。プラグインをクラスター全体で利用可能にしたい場合は、KongPluginの代わりにKongClusterPluginとしてリソースを作成してください。

このセクションを宣言型構成ファイルに追加します。

plugins:
- name: openid-connect
  service: SERVICE_NAME|ID
  config:
    issuer: http://keycloak.test:8080/auth/realms/master
    client_id: kong
    client_auth: private_key_jwt
    auth_methods:
    - password
    consumer_claim:
    - preferred_username
    consumer_by:
    - username

SERVICE_NAME

IDを、このプラグイン構成の対象となるサービスの idまたはnameに置き換えてください。

前提条件： パーソナルアクセストークンの設定

terraform {
  required_providers {
    konnect = {
      source  = "kong/konnect"
    }
  }
}

provider "konnect" {
  personal_access_token = "kpat_YOUR_TOKEN"
  server_url            = "https://us.api.konghq.com/"
}

Kong Konnectゲートウェイプラグインを作成するには、Terraform 構成に以下を追加します。

resource "konnect_gateway_plugin_openid_connect" "my_openid_connect" {
  enabled = true

  config = {
    issuer = "http://keycloak.test:8080/auth/realms/master"
    client_id = "kong"
    client_auth = "private_key_jwt"
    auth_methods = ["password"]
    consumer_claim = ["preferred_username"]
    consumer_by = ["username"]
  }

  control_plane_id = konnect_gateway_control_plane.my_konnect_cp.id
  service = {
    id = konnect_gateway_service.my_service.id
  }
}

Test consumer-based authorization

Before moving on, make sure the consumer john doesn’t exist:

 curl -i -X DELETE http//localhost:8001/consumers/john

Now try access the service without a matching consumer:
```
 curl --user john:doe http://localhost:8000
```
You should get an HTTP 403 Forbidden response.
Now, add the consumer:
```
 curl -i -X PUT http://localhost:8001/consumers/john
```
You should get an HTTP 200 if the consumer creation is successful.

Try to access the service again using the same consumer:

 curl --user john:doe http://localhost:8000

This time, you should get an HTTP 200 response. You should also see that the plugin added X-Consumer-Id and X-Consumer-Username as request headers:

 {
     "headers": {
         "Authorization": "Bearer <access-token>",
         "X-Consumer-Id": "<consumer-id>",
         "X-Consumer-Username": "john"
     },
     "method": "GET"
 }

It is possible to make consumer mapping optional and non-authorizing by setting the configuration parameter config.consumer_optional=true.

前へ Claims-based authorization

次へ Mutual TLS Client Authentication