Well, our architecture is pretty much fixed in that it will require a list of roles encoded into a JWT provided by our own identity service. So I am basically looking for a way to map that as best as possible to Tyk’s way of doing things.
It would seem that for us to use Tyk we would have a role concept for api consumers so that we could define what roles have access to what parts of the API(s). Either mapping 1 jwt → multiple potentially overlapping policies, or introducing a real role concept into Tyk.
I’m not quite sure how Tyk’s Key concept fits into this. As I understand keys are created up front either in the Tyk gui or through the Tyk admin API? I would need to preemptively create a lot of keys with different policy combinations, right? Or have our identity service use Tyk’s admin API to create a key at the same time as it issues the JWT.
Is there a way to have an externally signed JWT map to a Tyk key? (which in turn maps to multiple policies?)
The next step after being able to do this, would be to actually do the same using openid connect providers (but that would be a future step for us) - basically if we could map let’s say roles set in external Azure AD hooked up through openid connect (which we happen to use) to Tyk multi-policy/future role concept.