I have an Asp.Net Core application running in an Azure Web App and I need it to be able to call itself.
Part of a long-running process in the app needs to be able to open a connection to https://my-app-name.azurewebsites.net/api/check-for-updates.
This works fine in a public-facing environment, it failed on an IP-restricted one until I gave it local VNet access, and it doesn't work at all on an environment that relies on AD authentication. Instead, I get a 401 forbidden message.
Is there any way of telling it that a request from localhost does not need to be authenticated? It would be fine if this was limited by the endpoint.
One idea that crossed my mind was to use the Authentication service to provide identity but then use the Access Restriction panel to catch unauthenticated users from outside the local VNet, but it looks as though it doesn't have the option to pick up on the Authentication status of a request.
If you send a request from the app service to its own endpoint like https://my-app-name.azurewebsites.net/api/check-for-updates, you will not be able to tell whether it's a localhost request or not simply because it will be routed as any other external request through the domain https://my-app-name.azurewebsites.net. For scaled-out app services the request can land on a different instance as it will be load-balanced.
Here is how you can achieve the desired behaviour for the two scenarios you explained.
As you've already mentioned, you can configure this app service in your Vnet, or simply whitelist its own Outbound IP addresses under the Networking → Access restrictions blade.
Rather than trying to bypass AD authentication, I would recommend implementing service-to-service authentication using the same identity platform. You can create a new app registration in Azure Active Directory or re-use an existing one. Then you will need to generate a client secret and copy it with application ID for the back-end authentication process.
Finally, implement client credentials flow in the application so that it automatically requests access token and passes it in the Authorization header for the request https://my-app-name.azurewebsites.net/api/check-for-updates. Client credentials flow does not require any human interaction and works perfectly for background processes and "daemon" applications. There is a step-by-step guide for this scenario in documentation here.
This approach will allow you to send the required requests while keeping the existing security level. It will also work if you decide to call this endpoint from a different app service in future as it does not require the calling service to be hosted on the same machine.