Add support for SocketsHttpHandler to use provided SPN

[mconnew]

WCF has the requirement to use non-default SPN's when using Kerberos authentication over HTTP. The AuthenticationHandler class specifies the SPN in this line of code. WCF needs a way to optionally specify which value is used on this line.
Ideally this would be exposed via an api mechanism available on HttpClientHandler/HttpClient/HttpRequestMessage so that WCF wouldn't need to dictate that a client always uses SocketsHttpHandler once available. We need to be able to specify either a mapping between hostname and SPN or to be able to specify on a per-request basis. This is especially important as there are likely to be some compatibility edge cases with SocketsHttpHandler once released and we would need to allow developers to specify which implementation that WCF will use.
An issue to expose the ability to specify the SPN in a general way to support mutual authentication was previously opened in 2015 in issue #15708. This issue is a more specific ask for this support to be available in SocketsHttpHandler and hopefully for it to be exposed in a more generic manner.

[davidsh]

cc: @geoffkizer @karelz @stephentoub

[geoffkizer]

I think you are asking for the equivalent of AuthenticationManager.CustomTargetNameDictionary on SocketsHttpHandler. Is that right?

This doesn't seem that hard to do.

[geoffkizer]

Does WCF allow arbitrary SPNs to be configured? Or is there some limited set of things it does?

[mconnew]

We allow any valid SPN or UPN to be used so we need the ability to specify a freeform value.

[geoffkizer]

Ok, thanks.

First step here would be an API proposal.

[karelz]

@mconnew I expect that we will add new features and APIs primarily into SocketsHttpHandler. I do not expect that we will keep adding the same feature into WinHttp/LibCurl handlers once SocketsHttpHandler is proven & mainstream (hopefully even during 2.1).

[mconnew]

@karelz, I understand that the existing implementations aren't expected to get it. There are multiple ways to do this, for example you could bring over the AuthenticationManager.CustomTargetNameDictionary api and have SocketsHttpHandler use that to find the mapping, that way HttpClientHandler wrapping SocketsHttpHandler could still be used. Another option is to add it to HttpClientHandler and add a SupportXXXX property. This could be supported on the full framework which wraps HttpWebRequest so there would be more than one implementation which supports this api. Adding api surface in a general location doesn't mean it needs to be supported everywhere but would provide greater flexibility.

[karelz]

Good, I was just checking your expectations :) ... I think we are aligned here.

[mconnew]

Just to put some context on this, we believe this is a blocker for some scenarios running WCF services in a container. When running a service in a container, even if the host is domain joined, the container image isn't fully domain joined (things gets very murky as there's no corresponding machine account in the domain). This normally means you can't do Windows authentication to an HTTP service/website running on a container. You can configure a domain gMSA account which the local SYSTEM account gets mapped to. My expectation is that this should allow running a service with a upn identity. WCF supports this on the full framework, but without support for specifying the HTTP server Kerberos identity, a .Net Core client can't use Windows auth.

[karelz]

OK, that makes it more needed.

The code for reference where we set SPN today:
https://github.com/dotnet/corefx/blob/158ed4d059a875e6828c176ce7ecc4a221b331e3/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/AuthenticationHelper.NtAuth.cs#L61

SPN is tied to authentication. Adding it per request (likely into HttpRequestMessage) feels weird.
Maybe we should follow SocketsHttpHandler.Credentials model as SPN is similar to that ...

@mconnew did you have some specific API shape in mind?
cc @davidsh @geoffkizer

[davidsh]

In .NET Framework, we have an API that allows a dev to map custom SPN's to URI:

See example: https://stackoverflow.com/questions/39740676/forcing-specific-spn-for-url-in-net

Existing API: https://docs.microsoft.com/en-us/dotnet/api/system.net.authenticationmanager.customtargetnamedictionary?view=netframework-4.7.2

Maybe we should just implement this class on .NET Core and have the HTTP handlers use it. I don't think we need to define a new API for this.

[mconnew]

@davidsh, what I like about your idea is it would allow anyone's existing code using this capability to just work as the faux HttpWebRequest just wraps SocketsHttpHandler/HttpClientHandler. It would make migration easier.

[karelz]

AuthenticationManager is currently not hooked up anywhere - it is noop class.
https://github.com/dotnet/corefx/blob/aea91202c9ed213184562529e66959e602ec7826/src/System.Net.Requests/src/System/Net/AuthenticationManager.cs

The API:
https://github.com/dotnet/corefx/blob/aea91202c9ed213184562529e66959e602ec7826/src/System.Net.Requests/src/System/Net/AuthenticationManager.cs#L16

[geoffkizer]

We've generally moved away from using global-level settings like AuthenticationManager in HttpClient.

Seems like all we need here is CustomTargetNameDictionary on SocketsHttpHandler. Am I missing something?

[davidsh]

We've generally moved away from using global-level settings like AuthenticationManager in HttpClient.
Seems like all we need here is CustomTargetNameDictionary on SocketsHttpHandler. Am I missing something?

First, if we are going to add a new API to SocketsHttpHandler, we should do it to HttpClientHandler as well.

Second, this approach won't help folks still using HttpWebRequest APIs especially if porting from .NET Framework to .NET Core.

If we don't care about HttpWebRequest working with this scenario and we don't care about making people change their code when porting to .NET Core, then we can add this API to SocketsHttpHandler/HttpClientHandler.