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?
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 https://tyk.io/docs/tyk-identity-broker/identity-providers/openldap-activedirectory/
â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, https://tyk.io/docs/tyk-dashboard-v1-0/endpoint-designer-plugins/url-rewriting/
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.
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â
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:
Request goes into TIB
TIB validates user against LDAP
TIB uses basic LDAP data and generates a Portal User
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.
Yes you can, but it isnât easy, nor out of the box, there are two ways:
Method 1: JS middleware writebacks
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.
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
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):
Check the meta-data of the token for a key that reflects the user email address
If the key exists AND the headers already have the user email as a header, just return and do nothing
If no meta-data exists, create it and write the meta-data to the session token for next time
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:
User logs into portal with AD
User requests token
Token request is created, but not approved
User is redirected to a third-party app with the key request ID in the querystring
third-party (custom) app retrieves key-request and developer data with API
Custom app then approves key request, this generates a token which is returned to the app
Custom app then adds the email address to the metadata of the token
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.
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.
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?
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.
I am a bit worried that we are not completely understanding each other. (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.
