Authenticating Tyk for LDAP users

Is it possible to authenticate the users through the LDAP (such as OpenLDAP, which I have already configured) integration and do a header transformation based on the user details retrieved from LDAP?

From LDAP user login, we will retrieve the user log in name (or email address), and do a header transform as described in

In this scenario, we will not create users from Tyk directly (except for the admin account that we created once in the beginning).

I have also configured Tyk Identity Broker. I am a bit confused by the statement in
“The LDAP Identity Provider is experimental currently and provides limited functionality to bind z user
to an LDAP server based on a username and password configuration. The LDAP provider currently does not extract user data from the server to populate a user object, but will provide enough defaults to work with all handlers.”

Also regarding URL Rewrite option in,
I do not see a URL Rewrite option as described:
“Tyk offers a simple form of URL rewriting, to enable the URL rewrite,
simply select “URL Rewrite” from the drop-down menu in the plugins
column of the Endpoint Designer.”

There is no plugins column or a "drop-down menu with “URL Rewrite” option in the Tyk Dashboard. See the attached image.

Please let me know whether I missed something.

Thank you.

Are you talking about the dashboard? Or the Tyk Gateway?

  • For Dashboard: It’s an SSO nonce that logs the user into the dash, no user is created
  • For Gateway it’s a token exchange, the flow is: Log in via TIB URL → TIB verifies Is valid → Call Tyk → Tyk GW Generates Token → Return Token to user / app

Try the dropdown to the right of the path, under the column “Select plugin”

I meant the Tyk dashboard.

Thanks, that works.

Will get back if I am stuck again.


Sorry, i’m not up to speed w/ your product nomenclature. We want API users to be able to login to a ‘developer portal’ and manage their individual API-Keys. And restrict access to users who have accounts on LDAP. From the documentation it appears that this should be possible.

When an API call is made, I want the api-key to be resolved to the LDAP user that the API-Key is associated with, and would like to include this LDAP user info to be included in the headers that are then sent to the backend system. This backend system uses these rewritten headers to make authorization decisions.


This is possible: It is possible for TIB to log a user into the Developer Portal as well as the Dashboard, while the dashboard is a SSO nonce, the developer portal actually generates an account on the system (these are two different user types)

This is not how it works, TIB logging users into the portal basically does this:

  1. Request goes into TIB
  2. TIB validates user against LDAP
  3. TIB uses basic LDAP data and generates a Portal User
  4. TIB Redirects user to Portal (user can then re-login via TIB to the same account)

The user, once in the portal, will be able to request API Tokens from the API catalogue. The token, when used against an API will not call back to LDAP to get data, it will just be validated as an API key. To have a secondary level of verification, you will need to do something custom with a JS plugin.

Also worth noting is that our LDAP integration does not extract much data from LDAP as the driver is quite new.

Hi Martin,
Thanks for the clarifications.

I was trying to achieve what @sharmaashish discussed above.

I have a question before I proceed further with the use case:

I would like to get the email entry for the user from LDAP, and include it to the header. I have successfully done header transforms. Is it possible to get the email address from LDAP using Tyk.

For example, I have the below entry (and many other following the same format) in LDAP.

Pradeeban Kathiravelu

dn: cn=Pradeeban Kathiravelu,ou=email,dc=my-domain,dc=com
cn: Pradeeban Kathiravelu
givenName: Pradeeban
sn: Kathiravelu
objectClass: inetOrgPerson

Is it possible to get the email address of this user, given that he logs in following the workflow you mentioned.

Yes you can, but it isn’t easy, nor out of the box, there are two ways:

Method 1: JS middleware writebacks

  1. When a user is logged into the portal via LDAP, it creates that user with a hidden ID which is basically the Email address and the provider (LDAP in this case), this is done here, and here.
  2. When that user requests a token via the portal, that token will have certain meta-data filled into their token to reflect the user, this includes the developer ID in a field called $tyk_meta. tyk_developer_id, which can use in your header injector
  3. To get back to the email address, you would need to either write a plugin that requests this data from the Tyk Dashboard API and adds it to the token meta-data fields (if it isn’t present) OR have your upstream service callback the same API and request the data

The JS plugin in (3) would need to do a few things, because it would be a post-processor (header injection would have completed already):

  1. Check the meta-data of the token for a key that reflects the user email address
  2. If the key exists AND the headers already have the user email as a header, just return and do nothing
  3. If no meta-data exists, create it and write the meta-data to the session token for next time
  4. Then, if no header exists, add the header in the JS

You need this logic because you might have the main header injector do the injection, but if it can’t find the field, you need to capture it after the fact using a lookup.

Method 2: Portal Key Request pre-approval hand off:

Another approach to get the data into the token is by using the portal key-request redirect:

  1. User logs into portal with AD
  2. User requests token
  3. Token request is created, but not approved
  4. User is redirected to a third-party app with the key request ID in the querystring
  5. third-party (custom) app retrieves key-request and developer data with API
  6. Custom app then approves key request, this generates a token which is returned to the app
  7. Custom app then adds the email address to the metadata of the token
  8. Custom app returns the token to the user

Now because the custom app has essentially copied the data into the token, the token is enriched with the necessary email address from LDAP and the data can be injected into the header.

Using the hand-off is probably the best thing to do because you don;t introduce latency by having arbitrary JS executing.

1 Like

Regarding the method 1:

I am confused here.
[1]. I already have url-rewriting work with a hard-coded email address (which is obviously oblivious to the logged in user data).

For this, a consumer does not even have to come to the portal, as my request just go through the Tyk Gateway. I, the admin, just configure this entire thing through the portal, once and only once.

[2]. suggests that we can transform the header with the user-specific data from LDAP such as user ID.

So, combining [1] & [2], what prevents getting the email address to the header during the re-write phase?

Probably I fail to understand why this is a post-processor, and how the “header injection would have already completed”.

Regarding the method 2:
Please let me know where does the third-party (custom) app exist? is it a TIB or Gateway plugin, or something completely external as a separate entity?

I am puzzled that you recommend the method 2, while method 1 is the one that is discussed in the documentation (

Did I miss or misinterpret something?

Thanks a lot… :slight_smile:


See the attached image.

Here, I will invoke my service through
curl -H “Authorization: 5735d4f55ee857068a000001d4810168c5e64969419e0b766d544cea” http://localhost:8080/tcia/get

When I hard-coded the email address (with my real email address), the web application works well.

Now, I need to get this email address from LDAP for the service invocations, by using $tyk_meta.uid (as shown in the attachment).

That means, I need
curl -H “Authorization: 5735d4f55ee857068a000001d4810168c5e64969419e0b766d544cea” http://localhost:8080/tcia/get

to work without hard-coding my email address - but rather get my email address from LDAP using $tyk_meta.uid.

Isn’t it populated by default for LDAP based accounts, as in ?

I am a bit worried that we are not completely understanding each other. :slight_smile: (or probably that is only me).

Also I am not completely sure how TIB is involved in the subsequent service requests such as above (except during the initial account creation process that we discussed earlier in the thread).

Any clarifications will be much appreciated. (Apologies for too much noise. I am new to both Tyk and LDAP, though I think this may make a convincing and interesting use case).


I’m not sure where LDAP is mentioned in those docs?? The meta data that is discussed in the transforms docs is related to the meta data stored with the API token. You need to put it there. Tyk doesn’t do that for you.

Both methods I have described will get some data from an LDAP server to a place where you can then inject it into the header. I guarantee you that those are the only ways to achieve it.

Tyk’s Identity Broker LDAP integration is very simple, and doesn’t request data from LDAP to add to the token yet, it just validates the username and password and then performs a Tyk action with a limited metadata object.