Hi,
We’ve just come across an issue which took us some time to get to the bottom of and I just wanted to check if it was indeed correct behavior or whether there’s some missing functionality in Tyk.
We have two Identity Service providers, one for our production and one for our test environments so we’ll refer to them as IS Prod & IS Test
We have a single instance of Tyk and we’ve setup two APIs, API Prod and API Test. These are the same API, just the Prod & Test variant. These are setup with an Authentication mode of JSON Web Token (JWT) and on each API we have configured the RSA public key of the Identity Service (it’s different between Prod & Test).
On both APIs the Identity Source is set to client_id and the policy field name is set to gateway_policy
We’ve also setup two policies - Policy Prod & Policy Test. Policy Prod only allows access to API Prod and Policy Test only allows access to Policy Test.
We then have two calling applications - which for consistency we’ll call App Prod & App Test. These are configured to ensure a claim of gateway_policy is within their JWT to assign Policy Prod to App Prod and Policy Test to App Test (unsurprising).
The kicker, and the issue is that both App Prod & App Test use the same client_id as they’re both configured against the two separate Identity Service Providers.
This seems fine on the face of it, and we thought nothing of it until we started to get some unexpected behavior.
App Test, API Test & Policy Test were the first to be setup and were working flawlessly. We then setup the Prod varients and when we tested them we could never get the App to talk to the API - Tyk kept denying the requests to the API, despite everything being set up correctly.
The reason for this is because Tyk is using the client_id (which is the same across IDPs) as the indentifier for it’s internal keys, and it’s using the cached policy associated with that key. So our App Prod would be linked to the existing App Test key and get the Policy Test applied rather than the one specified in it’s gateway_policy key!!
Now there are a few work arounds, we could use a different client_id between our IDPs however we get benefits from having the same client_ids between test and production so we’d rather not do this.
Another option would be to use a different claim for Identity Source, however this will mean a change to our IDPs to perhaps provide a claim which is a composite of client_id and iss which would be unique across our IDP environments however this feels like a work around.
We will also have this same issue in other circumstances where we use the sub claim for where we’re using Idenity Tokens rather than Access Tokens for our single sign on system and try to have a policy per website.
So after all this background the question I have for you is: is it possible to specify a composite Idenity Source in Tyk? This would be extremely beneficial!
Thanks,
Richard