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 like this:
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
.
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 Gateway.
-
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 Admin API and retrieve
more information about the Consumer.
LDAP directory searching is performed during the request and plugin lifecycle to retrieve the fully qualified DN of the user.
This allows the plugin to bind using the user’s LDAP username and password.
The search uses:
ldapsearch -x \
-h "$LDAP_HOST" \
-D "$BIND_DN" \
-b "$ATTRIBUTE=$USERNAME,$BASE_DN" \
-w "$LDAP_PASSWORD"
When using only RBAC Token authorization, service directory mapping to Kong Gateway roles doesn’t take effect. If you need to use CLI access with your service directory mapping, you can use the same authentication mechanism that Kong Manager uses to secure browser sessions.
Retrieve a secure cookie session with the authorized LDAP user credentials:
curl -c /tmp/cookie http://localhost:8001/auth \
-H 'Kong-Admin-User: $LDAP_USERNAME' \
--user $LDAP-USER:$LDAP_PASSWORD
Now the cookie is stored at /tmp/cookie
and can be read for future requests:
curl -c /tmp/cookie -b /tmp/cookie http://localhost:8001/consumers \
-H 'Kong-Admin-User: $LDAP_USERNAME'
Because Kong Manager is a browser application, if any HTTP responses see the Set-Cookie
header, then it will automatically attach it to future requests. This is why it’s helpful to use cURL’s cookie engine or HTTPie sessions. If you don’t want to store the session, then the Set-Cookie
header value can be copied directly from the /auth
response and used with subsequent requests.