Restarting Azure App Service on Linux with Azure Active Directory authentication resets /.auth/me/

2
votes

I'm using Azure App Services Authentication/Authorization to restrict access to my web app, using Azure Active Directory as sign in method.

I've set the "Action to take when request is not authenticated" to "Log in with Azure Active Directory".

In order to find details about the logged in user, I make a request to the /.auth/me endpoint (as instructions from Microsoft docs says). This works fine, until the app is restarted in Azure. After restart, the /.auth/me/ endpoint returns an empty array, instead of the user information.

I can only reproduce the problem if the App service plan is running Linux. If I create a Windows App Service Plan, the /.auth/me endpoint is populated even after restart.

I've tried creating a new app on Azure, without uploading any code, and the problem is still there.

Do I need to set some extra settings in order for this to work on a Linux based ASP? I've tested with both docker based ASPs and code based (on dotnet core 2.2).

2
azureazure-active-directoryauthorizationazure-web-app-service

2 Answers

2
votes

I got an answer from Microsoft on their forums. As @Tony also found, this is because the middleware container handling the authentication on Linux App Services restarts and loses it's tokens. The Middleware Container is a second container running next to/in front of your code in Azure when your are using Linux App Services and it handles all the Auth magic (see this blog post by Jan Hajek on the middleware container)

Microsoft are currently invenstigating the loss of tokens as a potential bug, and their recommended workaround is using "Blob storage token store", which means the Azure Middleware Container will store the tokens in a blob storage instead of on disk and thereby keeping them on restart.

To implement:

  1. Create a blob storage in azure (if you don't have one you want to use already)
  2. Create a blob container with only private access

  3. Create a Shared Access Signature on the storage instance.

    • Give it access to*:
      • Allowed services: Blobs
      • Allowed resource types: Container, Object
      • Allowed permissions: Read, Write, List, Create
    • Set a start/end date for your SAS
    • Generate SAS and copy "Blob service SAS URL"

    • Modify the SAS URL to include your blob container name. For example, if the container you created in step 2 is named "tokens", modify your SAS URL from:

      https://xxxxx.blob.core.windows.net/?sv=2018-03-28... to

      https://xxxxx.blob.core.windows.net/tokens/?sv=2018-03-28...

  4. Go to your web app and add a new Application Setting. Name it WEBSITE_AUTH_TOKEN_CONTAINER_SASURL and give it the value of your modified SAS URL
  5. Go to your website and log in. A token should now be created in the blob storage and will be used after restart as well.
  6. If it does not work right away, try stopping/starting the web app in Azure. See the above blog post for additional debugging tips.

(*) The blog post linked above stated less permissions needed for the SAS, but I found I had to add object access as well.

0
votes

I did some research and verified the situation you mentioned. In Linux, after restart the information will lost, however, in Windows it works well. The reason of this is that the Middleware Container, which handles Auth for Linux, is respawned so the user data would be wiped away after a restart. We can monitor that actually after restart, the login status maintains, the lost part is only the information which is related to the docker containers.

If you need to reuse the information of current user through /.auth/me, you need to record the authMe information through code after the first log in.