コンテンツにスキップ
|
Plugin Hub
report-issue問題を報告する
header icon

LDAP Authentication Advanced

By Kong Inc.

このページは、まだ日本語ではご利用いただけません。翻訳中です。

古いプラグインバージョンのドキュメントを閲覧しています。

Looking for the plugin's configuration parameters? You can find them in the LDAP Authentication Advanced configuration reference doc.

Add LDAP Bind Authentication with username and password protection. The plugin checks for valid credentials in the Proxy-Authorization and Authorization headers, in that order.

The LDAP Authentication Advanced plugin provides features not available in the open-source LDAP Authentication plugin, which includes:

  • LDAP searches for group and consumer mapping
  • Ability to authenticate based on username or custom ID
  • The ability to bind to an enterprise LDAP directory with a password
  • The ability to authenticate/authorize using a group base DN and specific group member or group name attributes
  • The ability to obtain LDAP groups and set them in a header to the request before proxying to the upstream. This is useful for Kong Manager role mapping.

Usage

To authenticate a user, the client must set credentials in either the Proxy-Authorization or Authorization header in the following format:

credentials := [ldap | LDAP] base64(username:password)

The Authorization header would look something like:

Authorization:  ldap dGxibGVzc2luZzpLMG5nU3RyMG5n

The plugin validates the user against the LDAP server and caches the credentials for future requests for the duration specified in config.cache_ttl.

You can set the header type ldap to any string (such as basic) using config.header_type.

Upstream Headers

When a client has been authenticated, the plugin appends some headers to the request before proxying it to the upstream service, so that you can identify the consumer in your code:

  • X-Consumer-ID: The ID of the consumer in Kong.
  • X-Consumer-Custom-ID: The custom_id of the consumer (if set).
  • X-Consumer-Username: The username of the consumer (if set).
  • X-Credential-Identifier: The identifier of the credential (only if the consumer is not the anonymous consumer).
  • X-Anonymous-Consumer: Is set to true if authentication fails, and the anonymous consumer is set instead.

You can use this information on your side to implement additional logic. You can use the X-Consumer-ID value to query the Kong Admin API and retrieve more information about the consumer.

LDAP Search and config.bind_dn

LDAP directory searching is performed during the request/plugin lifecycle. It is used to retrieve the fully qualified DN of the user so a bind request can be performed with a user’s given LDAP username and password. The search for the user being authenticated uses the config.bind_dn property. The search uses scope="sub", filter="<config.attribute>=<username>", and base_dn=<config.base_dn>. Here is an example of how it performs the search using the ldapsearch command line utility:

ldapsearch -x \
  -h "<config.ldap_host>" \
  -D "<config.bind_dn>" \
  -b "<config.attribute>=<username><config.base_dn>" \
  -w "<config.ldap_password>"

Using Service Directory Mapping on the CLI

RBACトークン認証のみを使用する場合、Kongロールへのサービスディレクトリのマッピングは有効になりません。サービスディレクトリのマッピングでCLIアクセスを使用する必要がある場合は、Kong Managerがブラウザセッションの保護に使用するものと同じ認証メカニズムを使用できます。

ユーザーセッションを認証する

承認されたLDAPユーザーの認証情報を使用して、安全なCookieセッションを取得します。

$ curl -c /tmp/cookie http://localhost:8001/auth \
-H 'Kong-Admin-User: <ldap_username id="sl-md0000000">' \
--user <ldap_username id="sl-md0000000">:<ldap_password id="sl-md0000000">

これで、Cookie は /tmp/cookie に保存され、将来のリクエストで読み取ることができます。

$ curl -c /tmp/cookie -b /tmp/cookie http://localhost:8001/consumers \
-H 'Kong-Admin-User: <ldap_username id="sl-md0000000">'

Kong Managerはブラウザアプリケーションであるため、HTTP応答にSet-Cookieヘッダーが含まれている場合、このヘッダーは将来のリクエストに自動的に添付されます。cURLのCookieエンジンまたはHTTPieセッションの使用に役立つのはそのためです。セッションを保存したくない場合は、Set-Cookieヘッダーの値を/auth応答から直接コピーして、以降のリクエストで使用できます。

Notes

config.group_base_dn and config.base_dn do not accept an array and it has to fully match the full DN the group is in - it won’t work if it is specified a more generic DN, therefore it needs to be specific. For example, considering a case where there are nested "OU's". If a top-level DN such as "ou=dev,o=company" is specified instead of "ou=role,ou=groups,ou=dev,o=company", the authentication will fail.

Referrals are not supported in the plugin. A workaround is to hit the LDAP Global Catalog instead, which is usually listening on a different port than the default 389. That way, referrals don’t get sent back to the plugin.

The plugin doesn’t authenticate users (allow/deny requests) based on group membership. For example:

  • If the user is a member of an LDAP group, the request is allowed.
  • if the user is not a member of an LDAP group, the request is still allowed.

The plugin obtains LDAP groups and sets them in a header, x-authenticated-groups, to the request before proxying to the upstream. This is useful for Kong Manager role mapping.