YARP: how to supply default credentials in a proxied request?

[MattiasMartens]

Hi, I first posted this on Stack Overflow but I thought it might be good to take it straight to the source as well.

Quoting from SO:

Per #166 (comment) it is possible to authenticate using the default network credentials cache when a server forwards a request through YARP.

(That is, it is possible to authenticate using credentials stored on the server; a user logging in through a proxy is confirmed not to be supported.)

But how to actually configure this?

The docs suggest that I can add a "WebProxy" block to my network configuration file, to which I can add a "UseDefaultCredentials" parameter:

      "MyCluster": {
        "Destinations": {
          "mydest": {
            "Address": "https://example.com",
            "UseDefaultCredentials": "true"
          }
        },
        "HttpClient": {
          "WebProxy": {
            "Address": "??? what goes here?",
            "UseDefaultCredentials": "true"
          }
        }
      },

But the question is in the code: what exactly is the address supposed to be for the outgoing web proxy? Is this separate from the URLs in the destinations section? What if there is more than one destination?

I have tried:

• Specifying HttpClient.WebProxy.UseDefaultCredentials and leaving HttpClient.WebProxy.Address blank (not respected, still get a request for authentication)
• Specifying both HttpClient.WebProxy.UseDefaultCredentials and HttpClient.WebProxy.Address, removing the "Destinations" section entirely (503 Service not configured)

[samsp-msft]

The HttpClient.WebProxy is not for this scenario, it is for when using a forward proxy that you need to authenticate with, and will not affect the authentication between YARP and the destination server.

You probably need to be looking at Configuring the client and then setting a credential something like this.

[mattiasgth]

@Tratcher: thanks for the encouragement :-) I've tried all different kinds of tricks to get this working, but no luck so far. Using our own homegrown proxy (where a .NET HttpClient is sending the request), everything works as expected, but there's obviously something wrong with how we're using yarp. I'll start a new thread Monday on this. (It would be great to have an article on proxy => destination auth in the docs.)

[MattiasMartens]

@mattiasgth Hi, fellow Mattias.

I posted this on another page -- what I had above was a starting point but it would fail on execution because NTLM is a multi-step flow. The thing that ultimately worked for us was more like this:

// Add reverse proxy capability to the server
var proxyBuilder = services
    .AddReverseProxy()
    .ConfigureHttpClient((context, handler) =>
    {
        // Set credentials here
        handler.Credentials = CredentialCache.DefaultNetworkCredentials;
    })
    // Load configuration here
    .LoadFromConfig(Configuration.GetSection("..."))
    .AddTransforms(context => {
        // Load request content fully into buffer instead of providing it as a stream.
        // This is needed to prevent the multi-message NTLM auth flow from
        // prompting the request stream to be read more than once, which is an error.
        context.AddRequestTransform(async transformContext => {
            await transformContext.ProxyRequest.Content.LoadIntoBufferAsync();
        });
    });

[mattiasgth]

OK, so I never got this to work. I've tried adding the transform above, but no luck. Our backend server returns The HTTP/2 server reset the stream. HTTP/2 error code 'HTTP_1_1_REQUIRED' (0xd). when using this kind of authentication. Anonymous authentication works fine.

On what version of IIS did @MattiasMartens get this to work? Any ideas on how to debug this?

[Tratcher]

Oh, Windows auth doesn't work over HTTP/2 (YARPs default). You need to tell the proxy to use HTTP/1.1.

    "Clusters": {
      "allclusterprops": {
        "HttpRequest" : { // Options for sending request to destination
          "ActivityTimeout" : "00:02:00",
          "Version" : "1.1",
          "VersionPolicy" : "RequestVersionOrLower",
        },
....
      }

[mattiasgth]

@Tratcher Many thanks for this! Sorry for very late answer, but switching to HTTP/1.1 almost solved it. Everything works as expected in all environments, except our production servers. For some reason, the requests fail when using HTTPS. What ultimately worked for us was to switch to plain HTTP for proxy <=> back-end communication.