-
Notifications
You must be signed in to change notification settings - Fork 208
Deploying web apps to App Services as Linux containers
Normally, Microsoft Identity Web computes the redirect URI automatically depending on the deployed URL.
However, when you deploy web apps to App Services as Linux containers, your application will be called by App Services on an HTTP address, whereas its registered redirect URI in the app registration will be HTTPS.
This means that when a user browses to the web app, they will be redirected to login.microsoftonline.com
as expected, but with redirect_uri=http://<your app service name>.azurewebsites.net/signin-oidc
instead of redirect_uri=https://<your app service name>.azurewebsites.net/signin-oidc
.
If you are on Azure App Service (Linux container), just set the following environment variable:
"ASPNETCORE_FORWARDEDHEADERS_ENABLED"=true
Otherwise, in order to get the right result, the guidance from the ASP.NET Core team for working with proxies is in Configure ASP.NET Core to work with proxy servers and load balancers. You should address the issue centrally by using UseForwardedHeaders
to fix the request fields, like scheme.
The container scenario should have been addressed by default in .NET Core 3.0. See Forwarded Headers Middleware Updates in .NET Core 3.0 preview 6. If there are issues with this for you, please contact the ASP .NET Core team https://github.com/dotnet/aspnetcore, as they will be the right team to assist with this.
For more examples of the issue, as well as the history of how Microsoft Identity Web attempted to manage the issue in the past, see issue #115.
When scaling out a web app without App Service ARR affinity, after the user signs-in, the code is redirected back and forth between app service backend instances, causing a redirect loop. Enabling logging enables you to see that ASP.NET Core emits the following error:
Error from RemoteAuthentication: Unable to unprotect the message.State
This causes an authorization failure and Microsoft.Identity.Web redirects back to Azure AD which re-authenticates the user and redirects them back to the app, this time hitting the other App Service backend instance and causing the same error above.
For details, see https://github.com/AzureAD/microsoft-identity-web/issues/1160
If you enable ARR affinity things go well.
Upon receiving the response from Azure AD, the ASP.NET Core middleware takes care of validating the ‘state’ parameter to prevent cross-site forgery attack. The OpenID Connect OWIN middleware use .NET Data Protection API to encrypt the value stored in the ‘state’ parameter. However, data protection (DP) keys are not automatically sync'd across backend App Service instances of the same app
Add your own encryption key shared across instances, for instance hosted in blob storage and secured via Microsoft Key Vault. By ensuring the DP key is shared across all instances of the Linux App Service the Open ID Connect message state
parameter is being properly decrypted on any backend instance of the web app.
Example of the startup.cs:
services.AddDataProtection()
.SetApplicationName("MyApp")
.SetDefaultKeyLifetime(TimeSpan.FromDays(30))
.PersistKeysToAzureBlobStorage(new Uri("https://mystore.blob.core.windows.net/keyrings/master.xml"), new DefaultAzureCredential())
.ProtectKeysWithAzureKeyVault(new Uri("https://myvault.vault.azure.net/keys/MasterEncryptionKey"), new DefaultAzureCredential());
See Azure AD issues with load balancing across multiple regions on stack overflow.
The user sometimes get the error:
Status.AppServices.Middleware.ProductionExceptionMiddleware: Unhandled exception occurredSystem.Exception: An error was encountered while handling the remote login.
---> System.Exception: Unable to unprotect the message.State.
To fix it, set up an additional HTTP-only routing rule in Front Door that redirects all HTTP traffic to the HTTPS-exclusive rule
See Configure ASP.NET Core to work with proxy servers and load balancers | Troubleshooting
For troubleshooting Azure front door, see also https://github.com/AzureAD/microsoft-identity-web/issues/1076#issuecomment-808707902
For troubleshooting with Azure AD Application Gateway, see https://github.com/AzureAD/microsoft-identity-web/issues/1199
Try setting the environment variable ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
on your service. This is something done by default in the Asp.Net Core container image, but it might not be happening in the ARC containers.
More background:
Forward the scheme for Linux and non-IIS reverse proxies. See also https://github.com/AzureAD/microsoft-identity-web/issues/1792
- Home
- Why use Microsoft Identity Web?
- Web apps
- Web APIs
- Using certificates
- Minimal support for .NET FW Classic
- Logging
- Azure AD B2C limitations
- Samples
- Web apps
- Web app samples
- Web app template
- Call an API from a web app
- Managing incremental consent and conditional access
- Web app troubleshooting
- Deploy to App Services Linux containers or with proxies
- SameSite cookies
- Hybrid SPA
- Web APIs
- Web API samples
- Web API template
- Call an API from a web API
- Token Decryption
- Web API troubleshooting
- web API protected by ACLs instead of app roles
- gRPC apps
- Azure Functions
- Long running processes in web APIs
- Authorization policies
- Generic API
- Customization
- Logging
- Calling graph with specific scopes/tenant
- Multiple Authentication Schemes
- Utility classes
- Mixing web app and web API
- Deploying to Azure App Services
- Azure AD B2C issuer claim support
- Performance
- specify Microsoft Graph scopes and app-permissions
- Integrate with Azure App Services authentication
- Ajax calls and incremental consent and conditional access
- Back channel proxys
- Client capabilities