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.”
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
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.