[Bug] Public cloud regionalization breaks existing services before 4.49.x
See original GitHub issueLogs and network traces Without logs or traces, it is unlikely that the team can investigate your issue. Capturing logs and network traces is described in Logging wiki.
Which version of MSAL.NET are you using?
4.49.1
Platform
What authentication flow has the issue?
- Desktop / Mobile
- Interactive
- Integrated Windows Authentication
- Username Password
- Device code flow (browserless)
- Web app
- Authorization code
- On-Behalf-Of
- Daemon app
- Service to Service calls
Other?
Relates to https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3252
Is this a new or existing app?
The 1P service is in production, and we have upgraded to a 4.49.1 or above of MSAL. This is breaking customers which use VNETs as they have to allow the traffic.
Repro
builder.WithAzureRegion(region);
Expected behavior
Not break customers.
Actual behavior
Customers have to change network to allow traffic to be sent to new regional endpoints.
Possible solution
Make the DNS suffix configurable so that 1P services can use later version of the package; but still use the old DNS suffix.
For example:
builder.WithAzureRegion(region, regionalHostSuffix: "r.login.microsoftonline.com")
Issue Analytics
- State:
- Created 6 months ago
- Comments:9 (6 by maintainers)
Top GitHub Comments
After discussions with the ESTS-R team, we have reched the conclusion that we cannot enforce the new alias, as some end-app devs block it and it is outside our control.
We need a mechanism to:
<region>.microsoft.login.com
(like today)<region>.r.login.microsoftonline.com
I propose we use either HttpClient extensibility or
OnBeforeTokenRequest
to achieve this. https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/src/client/Microsoft.Identity.Client/Extensibility/AbstractConfidentialClientAcquireTokenParameterBuilderExtension.cs#L23MSAL team to provide a POC.
Closing this as resolved, please re-open if more guidance is needed.