Replies: 1 comment 1 reply
-
Hi @regtm, I'm not familiar with APIMs limitations here and what workarounds may be available. From your description, it sounds like you are using Scenario 3 from this doc? https://learn.microsoft.com/en-us/azure/api-management/authentication-authorization-overview#scenario-3-api-management-authorizes-to-backend You mention the following in your description:
What claims does the access token possess which is sent to DAB? Does that JWT contain the |
Beta Was this translation helpful? Give feedback.
-
I'm looking for a way to combine DAB's API generation and fine grained permission management with the governance and management features provided by APIM.
I have come up with a rather straightforward way to implement this, by utilizing EntraID as identity provider. The flow goes like this: Client authenticates to the APIM via subscription key, which is linked to a product. The apim requests a jwt with a custom claim for the subscribed product, as well as adding the equivalent X-MS-API-ROLE. The jwt is then passed on to dab to make use of it's fine grained permission control.
Unfortunately, it seems that EntraID does not support custom claims for the client credentials authentication flow. So now I'm looking for a way to work around this limitation.
One possible workaround is to duplicate endpoints with the same data source but differing permission, which then can be added to the respective products in apim. This, obviously, is a rather ugly approach but seems possible to me right now.
A second approach could have been to extract the signing keys from entraid to sign my own jwts with custom claims, though a quick search indicates that access to the keys is not possible. However, running a separate identity provider to generate the jwts for dab would be possible, though I'd lose the tight integration into the azure ecosystem that EntraID has.
Do you know of other ways to work around this issue?
Beta Was this translation helpful? Give feedback.
All reactions