.net-coreproxyaccess-tokendotnet-httpclientidentitymodel

IdentityModel.AspNetCore problem with proxy credentials for backchannel HttpClient


I'm using IdentityModel.AspNetCore to manage client access tokens in a background service. Access to the internet is only possible through a corporate proxy server which uses windows authentication.

The proxy server is configured in Windows options and the background service detects the settings, however authentication doesn't work and I'm constantly getting The proxy tunnel request to proxy 'http://proxy:8080/' failed with status code '407'. How can I configure the HttpClient to use the windows credentials for authentication against the proxy server?

I've already tried the following, but this doesn't work:

        services.AddAccessTokenManagement(options =>
        {
            options.Client.Clients.Add("sapci", new ClientCredentialsTokenRequest
            {
                Address = hostContext.Configuration["HttpProxy:TokenEndpoint"],
                ClientId = hostContext.Configuration["HttpProxy:ClientId"],
                ClientSecret = hostContext.Configuration["HttpProxy:ClientSecret"],
                GrantType = OidcConstants.GrantTypes.ClientCredentials,
                AuthorizationHeaderStyle = BasicAuthenticationHeaderStyle.Rfc2617,
                ClientCredentialStyle = ClientCredentialStyle.AuthorizationHeader
            });
        })
        .ConfigureBackchannelHttpClient(client => new HttpClient(new HttpClientHandler()
        {
            DefaultProxyCredentials = CredentialCache.DefaultCredentials,
        }));

Solution

  • I believe you can do this at app startup, to ensure you capture all client usages:

    HttpClient.DefaultProxy = new WebProxy()
    {
      Credentials = CredentialCache.DefaultCredentials
    }:
    

    I would reduce your problem to deploying a minimal console app and running it with the same user account etc as your service. Once that works your main app will also.

    Sometimes these things are infrastructure related also: eg in the past, with IIS clustered environments, I've had to use a service account and register a service principal name, eg to prevent use of computer accounts. I doubt that is relevant to .Net Core / Kestrel though, which I assume you are using.