I just started using Tyk (great product btw! ), but I am having a little problem with understanding the use of a developer account and using any requested keys. So far I took the following steps:
Added API and setup the catalogue, developer and API key (BA)
Login as developer on portal and request API key
The portal shows me a username and password combination (because of BA)
To put it bluntly, what should we do with the given username/password (from step 3)? We assumed we had to use it as the BA login for the API call, but after doing so and looking at the raw request (using the Log Browser), I noticed the BA credentials being passed through to the external API endpoint. At this point I would expect the gateway to recognize my username/password (the one from step 3) and use the real credentials (from step 1) to actually communicate with the external endpoint.
There must be something I am missing, please enlighten me
That isnāt how it works, Tyk will not substitute the u/p of a BA user credetnials set that it has issued for the the one that t has stored against the developer. This would mean we would be storing the developer credential in plaintext, which we would never do.
If you want to pass a different set of credentials to the upstream, you will need to add:
The data you need to the custom fields of the developer (e.g. username and plaintext password - seriously this is NOT recommended)
In the API designer, open up the Endpoint designer tab and open the āGlobal Settingsā drawer, here you can add a header transform.
Add a Delete operation for the Authorization header
Add a new Authorization header with your credentials. Unfrotunately the header injector will not base64 encode the data for you, so you may actually need to store it in the developer object that way.
Alternatively, you can hard code it into the header injection if there is only one password.
Thanks for the reply Martin. It seems we wrongly interpreted the use of the developer portal and the requesting of keys. If I am deducing this correctly, this would create the following use case when requesting/granting access to an internal API while using BA (omitting any system-specific steps):
Developer requests key using the portal
Admin opens key request and adds the generated credentials to a .htpasswd file
Developer uses the generated credentials to make a request
Admin is able to see statistics and optionally add extra rules/settings for this specific developer
Based on the authentication mechanism (BA), step 2 would differ, while the other steps mostly stay the same.
Granted that the above would be correct, could I assume that the developer portal/keys only apply when using an internal API, because step 2 would not be possible in case of an external API.
Could you verify this is correct?
To add some context, we are currently communicating with many external APIs and are looking for an API gateway to manage things like rate-limiting, credentials and request/response translation. So the main point of this thread is mostly about finding out in what manner the credentials part is applied.
Unless you make key requests require approval by the admin, the admin would never see the plaintext of the u/p that gets generated, we try to avoid that at all costs because itās a security concern. But otherwse, yes that could work (even though itās extremely convoluted).
It would be much easier to have:
Create a single .hpasswd file with one set of credentials for the gateway
In the API Designer, have the gateway delete the Authorization Header and insert a new one with the internal gateway credentials
The developer can then get API credentials via the portal, and use those credentials immediately, because we replace them as the request passes through he gateway with the internal ones.
This way you get:
Analytics per user
A simple password model without the need for automation
The ability to generate keys for all you users without having to manage their IDs internally
Using these credetnails, you can use policies in Tyk to manage rate limits, quotas and complex acess control rules.
If you need more data about the user upstream in your app, you can use the header injector to inject meta data that the user provides on signup into the outbound request.
), but I am having a little problem with understanding the use of a developer account and using any requested keys. So far I took the following steps: