microsoft-identity-web: [Bug] Signing in users breaks when using backchannel proxy

Which version of Microsoft Identity Web are you using? Note that to get help, you need to run the latest version. 0.3.1-preview

Where is the issue?

Web app
- Sign-in users
- Sign-in users and call web APIs
Web API
- Protected web APIs (validating tokens)
- Protected web APIs (validating scopes)
- Protected web APIs call downstream web APIs
Token cache serialization
- In-memory caches
- Session caches
- Distributed caches
Other (please describe)

Is this a new or an existing app?

a. The app is in production and I have upgraded to a new version of Microsoft Identity Web.

Repro I have a public repro which is mainly a new project created with dotnet new mvc2 -singleauth template, then modified to handle Cloud Foundry variable parsing to obtain proxy information, and create the back channel proxy. Relevant code for Proxy is below. – repro here

I am not sure why, but simply changing back to .AddAzureAD, changing options to OpenIdConnectOptions, and no other changes, the back channel communication works properly.

        public void PostConfigure(string name, MicrosoftIdentityOptions options)
        {
            Log.Debug("Starting PostConfigure");
            var proxyURI = VCAPHelper.GetSquidUri();
            Log.Debug("Setting Proxy URI to {Proxy}", proxyURI);

            if (!string.IsNullOrEmpty(proxyURI))
            {
                var webProxy = new WebProxy()
                {
                    Address = new Uri($"http://{VCAPHelper.GetSquidHost()}:{VCAPHelper.GetSquidPort()}"),
                    BypassProxyOnLocal = true,
                    UseDefaultCredentials = false,
                    Credentials = new NetworkCredential(VCAPHelper.GetSquidUsername(), VCAPHelper.GetSquidPassword())
                };
                var httpClientHandler = new HttpClientHandler()
                {
                    Proxy = webProxy,
                    UseDefaultCredentials = true,
                    UseProxy = true
                };
                options.Backchannel = new HttpClient(httpClientHandler, true);
            }

Expected behavior I would expect back channel behavior to work normally when access through a proxy is required to access metadata at login.microsoft.com.

Actual behavior Receive an error below presumably due to some communication on the back channel not working through the proxy.

IOException: IDX20804: Unable to retrieve document from: 'https://login.microsoftonline.com/common/discovery/instance?authorization_endpoint=https://login.microsoftonline.com/common/oauth2/v2.0/authorize&api-version=1.1'.

Additional context / logs / screenshots There was an issue open under aspnetcore last year where I got the AzureAD piece working, that issue is https://github.com/dotnet/aspnetcore/issues/20000, for reference.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 22 (1 by maintainers)

Most upvoted comments

I’d suggest using the same pattern as AspNet, injecting IOptions<AadIssuerValidatorOptions> so the developer can do something like this in startup:

services.Configure<AadIssuerValidatorOptions>(options =>
{
  options.Backchallel = ...
  or 
  options.Configuration = ...
});

Tratcher on Oct 14, 2020

@jennyf19 : moving this to an enhancement as @Tratcher provided more context about what needs to be done. @Tratcher : would inject an IHttpClient be a god solution? It might be worth a quick sync to be sure we are not iterating towards the solution 😃

jmprieur on Oct 14, 2020

The ConfigurationManager I linked to uses its own HttpClient instance with only the default proxy settings. https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/91acf95dcbba555064d089363b97dbf5d211e30a/src/Microsoft.IdentityModel.Protocols/Configuration/ConfigurationManager.cs#L89

It needs to be replaced by one that allows you to pass in the HttpClient like this: https://github.com/dotnet/aspnetcore/blob/3fdbc2e90d9762324ef3809098c9ca25b0cb3284/src/Security/Authentication/OpenIdConnect/src/OpenIdConnectPostConfigureOptions.cs#L99-L100

Until then the above workarounds that let you configure the default proxy for the whole application should work.

Tratcher on Oct 13, 2020