HttpClient - control of ImpersonationLevel lost by deprecation of HttpWebRequest

[mrsvk]

Description

HttpWebRequest allows the user to specify the TokenImpersonationLevel for Windows Authentication in .NET Framework, and it defaulted to Delegation. On HttpClient, it defaults to Impersonation, and the user does not have the ability to change it as needed for a given request. This leaves no supported path in .NET to connect to web servers where Kerberos Delegation is required.

Reproduction Steps

Since this is a missing feature, I'll just link to documentation here:

.NET Framework documentation shows the available property on WebRequest: https://learn.microsoft.com/en-us/dotnet/api/system.net.webrequest.impersonationlevel?view=netframework-4.8.1

There is no corresponding property for .NET 6 or 8 for HttpClient, SocketsHttpHandler, or HttpRequestMessage.

Expected behavior

There should be a property somewhere that the user can use to specify the ability to use Delegation credentials for a specific request or set of requests.

Actual behavior

Using HttpClient to access our internal web servers that require delegable credentials fails.

Regression?

No response

Known Workarounds

While I am not endorsing this in any way, I was able to use https://www.nuget.org/packages/Lib.Harmony and reflection to inject code to only change the value of ImpersonationLevel to verify that is indeed the only reason this does not work. While that was workable as a test scenario, I would never endorse it for production code.

Configuration

No response

Other information

For .NET 8, this is hard-coded beyond user access in the function SendWithNtAuthAsync in System.Net.Http's AuthenticationHelper.NtAuth.cs, specifically in how it creates the NegotiateAuthentication helper class.

The NegotiateAuthentication class already supports the capability, as the user can already control it on NegotiateStream. All that is missing is a public property somewhere for the user to specify it when using HttpClient.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[MihaZupan]

Given that this appears to be working internally and simply? not exposed (thank you for checking), I'll mark this as an API suggestion. If others run into a similar limitation, please upvote the original post to let us gauge interest.

@wfurt @filipnavara does this seem like something we would want to expose an API for?

[wfurt]

I would be somewhat hesitant to do new API. The feature only works on Windows and the use of unconstrained delegation is discouraged. And it does not work with Edge by default any more. https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/www-authentication-authorization/kerberos-double-hop-authentication-edge-chromium

I would like to fix WebRequest.ImpersonationLevel so it actually works and migration of legacy apps to .NET Core is possible.

[mrsvk]

Thanks for your responses.

Given that HttpWebRequest is now a wrapper for HttpClient, I'm not sure if there's a path to restoring the WebRequest functionality without also exposing it on HttpClient - but, you'd definitely know better than I do.

Speaking as a user, my preference would be to have the choice available on HttpClient, as I far prefer the usage pattern there - the MS team has done a great job on it. My team already uses HttpClient in all of our new/migrated .NET applications that don't require delegation. I'd like to be able to be consistent across our rather large codebase.

I understand your point about unconstrained delegation being discouraged. Unfortunately, we're currently stalled on upgrading our infrastructure beyond it. We have a ton of distributed infrastructure, and we don't own the AD servers ourselves, so progress is very slow. However, we still have a need to migrate to .NET, so we're quite stuck.

[wfurt]

With #102038 submitted, there is at least migration path IMHO e.g. the property bus respected on .NET Core as well.

While we generally do not recommend use of Reflection, one could use same trick and construct HttpClient now that would try to gain given impersonation. That is certainly not as nice as full API but given that the is somewhat discouraged in new security landscape it may be sufficient.

Even if only as experiment, I would be curious if that would make your use case work @mrsvk.

[mrsvk]

@wfurt Thank you for the update!

It looks like this missed .NET 9 Preview 4 but will make Preview 5? I will plan on testing with that once it is available. While I agree Reflection is not necessarily ideal, it's a far better solution than the Harmony workaround I had mentioned. I wouldn't be too worried about pushing it into production environments.

I will circle back here once I confirm, and I'll close this issue if it does work.

[filipnavara]

It looks like this missed .NET 9 Preview 4 but will make Preview 5?

Correct.

I was about to point you to nightly build but someone screwed up. https://github.com/dotnet/installer/blob/main/README.md#installers-and-binaries is probably still updated, but who knows...

[wfurt]

Did you get it working somehow @mrsvk ? #25320 (comment) has another way how to do that. Since we exposed NegotiateAuthentication in 8.0 one can handle authentication in app instead of the handler and set NegotiateAuthenticationClientOptions.AllowedImpersonationLevel as desired.

[mconnew]

@wfurt, this is a very important scenario for WCF. It's sufficiently important to customers to drive a change to support impersonation in aspnetcore. The developers asking for this are all using the .NET Framework WCF client. None of them are able to port their client code to .NET without this being available for the HTTP client stack.
I think some of the hesitation with enabling this is the focus on delegation, but that's really the minority usage (at least for WCF) of this feature. It's primarily used for impersonation, so that local resources on the service machine can be accessed as the authenticating user. Full blown delegation is non-trivial to setup and needs cooperation of a domain admin which is why it's not used very often.
Are you sure this feature can't work on Linux for non-delegation scenarios? NTLM auth doesn't require any communication with the domain controller from the client side, so I would expect impersonation to work at least using NTLM?
Even if this was going to be a Windows only feature, you could attribute a property to only be for Windows.
If this isn't going to be made a public property (we would need it on HttpClientHandler as we have an extensibility point to allow customizing the HttpClientHandler), then can we rely on the internal api being stable so WCF can use it through reflection?
BTW, using NegotiateAuthentication directly is NOT an option. The reason being that this authenticates the socket and not the connection. As we don't have control of the connection pool, there's a risk that requests intended to be unauthenticated could get sent over an authenticated socket. And there's no way to know if a request will be sent over a new socket or an existing one. You could have a handshake have different legs attempt to happen on different sockets which would (should) fail.