User Authentication with IdentityServer and Azure API Management

1
votes

I need some help with Azure API Management service.

At the moment we have a SinglePage App which is using two Backend Services (WebApi .Net Core) hosted on Azure. To Authenticate and Authrize user we are using IdentityServer (also hosted on Azure as a service) + SubscriptionService. Here IdSrv is authenticating the user and it also defines to which APIs the webapp has access. The SubscriptionService has information if the user has rights to given APIs. More or less like that.

So the flow is: WebApp -> redirect to IdSrv endpoint -> login -> back to UI -> ask backend with user credentials (token)

Now, we want to add Azure API Management to the mix and I am struggling how to do that...

Initially we were thinking that we can hide everything including the IdentityServer behind API Management gateway, but looks like this doesn't make sense or is impossible. I found this as a helpfull reference: Generate Access Token and validate against IdentityServer4 through Azure API Management in which the second answer is quite important remark.

Based on that I think that I need to leave the Client to use IdentityServer to authenticate as this requires UI interaction but then somehow set a global policy in API Management to authorize the user using mentioned Send-Request policy. And then change backend to accept the JWT tokens from this policy? Is my thinking correct? How to implement that?

Or I should just pass the authorization-header from client request through API Management?

All those things are new for me so it could be that I missed something or messed up the terms...

2
azureidentityserver4asp.net-core-webapiazure-api-management

2 Answers

2
votes

The way you integrate APIM into picture may depend on goals you want to achieve with APIM. You could hide IdSrv behind APIM since there is Client credentials flow that would allow APIM to authenticate/authorize itself to an API, or you could have user authorize APIM once via Auth code grant and then store refresh tokens and use them to talk to an API. But I'm not sure that would be best since it quite a bit changes you system and forces you to solve other problems instead, like how to authenticate user to APIM. In some cases this may be a good approach, it's up to you to decide.

If you're fine with keeping IdSrv facing user, then we have APIM receiving a token with every request. You could then have a global/API policy in APIM that would send token received from user to SUbscriptionService to check user authorization to make a call) can do that with send-request policy), and either let the call pass or deny. This approach is most useful if you want to use different auth mechanism between APIM and backend, because if APIM is doing authorization work, your backend could avoid checking any user access, and instead just authorize APIM to do everything.

Check out this sample on how to authorize requests using external service: https://docs.microsoft.com/en-us/azure/api-management/policies/authorize-request-using-external-authorizer

0
votes

it is quite late from asking this question but here I described how we have done that. We cover UI clients and Device clients with SSL Certification auth on APIM. In short words:

  • UI Client is being redirected to ID Server Loging page
  • APIM is doing Token validation with ID Server
  • APIM is doing SSL Certification verification in DB and returning back token like data for devices to pass some "device account" information.

More details can be found here: