Runtime: HttpClientHandler should support UseDefaultCredentials instead of No-op on *nix

[hongdai]

On *nix, kinit is used to obtain and cache Kerberos ticket-granting tickets. I have verified that users can use kinit to obtain a kerberos ticket and CredentialCache.DefaultNetworkCredentials will use the credential. The below code works after using kinit on the shell:

c# handler = new HttpClientHandler() { }; handler.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;

@mconnew @zhenlan

[davidsh]

cc: @stephentoub

[Priya91]

@zhenlan You've marked the issue as blocking partner, but it has not been in the radar for 2.0.0.

If you are able to workaround after kinit and the DefaultCredentials working, this is not blocking right?

cc @karelz

[hongdai]

WCF cusotmers will NOT be able to work around by kinit and the defaultCredentials working. They need the API HttpClientHandler.UseDefaultCredentials to set to System.Net.CredentialCache.DefaultNetworkCredentials.

[karelz]

What's the user scenario? How common is it?

[hongdai]

The user scenario is WCF clients use default credential on the machine to communicate WCF service. This is a very common scenario.

[Priya91]

@hongdai kinit is a system command, what is the posix C API that accomplishes this on Unix?

We can modify HttpClientHandler.UseDefaultCredentials to use CredentialCache.DefaultNetworkCredentials, but this will return null, unless we initialize this with kinit. So we need the posix OS API that we can call from .NET pal.

[hongdai]

I don't know if there is a posix C API.
I think the customer scenario is similar to window log in. Once window log in, you don't need to initialize - CredentialCache.DefaultNetworkCredentials will return the credential the customer has provided when log in. In unix, they just need to do kinit command instead of window log in.

[karelz]

Linux does not have standard identity across all distros (kinit is just one of the options AFAIK). It does not even tie user to one identity as on Windows (see dotnet/corefx#15150).

So I am not really sure what the ask here is. @zhenlan can you please chime in what exactly is blocking?
Does WCF need fully implemented identity on Linux?

[hongdai]

@mconnew @zhenlan
We believe below scenario should work:

1. HttpClientHandler UseDefaultCredentials is specified.
2. If the Server reply with a Kerberos challenge, indicating it only accept Kerberos credential. And
   users has used kinit to obtain a kerberos ticket.
3. Then HttpClientHandler should just use the kerberos ticket by setting it to System.Net.CredentialCache.DefaultNetworkCredentials.

[karelz]

@hongdai why only kinit when there are many other options?

[hongdai]

@karelz Because users have chosen kinit in this case, it does not use other options.

Do you know who owns System.Net.CredentialCache.DefaultNetworkCredentials? It uses the kerberos ticket generated by the kinit in this case. They should be able to provide justifications.

[karelz]

@hongdai my team owns (parts) of Networking - I can help loop in right folks.

I don't think we should build one-off solutions for just kinit, until we convince ourselves that our solution will be useful for other options. We might easily end up with very targeted APIs which will soon become legacy and we will be sorry & dragging them with us for years.

Should we perhaps chat?

cc @geoffkizer @Priya91 @wfurt

[stephentoub]

I think there's some confusion on this thread. We already rely on this Kerberos infrastructure / kinit / etc. from various parts of corefx, like NegotiateStream and SqlClient for integrated auth. I believe all @hongdai is asking for is that rather than our current implementation of UseDefaultCredentials:
C# public bool UseDefaultCredentials { get { return false; } set { } }
i.e. a nop, we instead track it and if true behave as if CredentialCache.DefaultNetworkCredentials was specified to the creds. @hongdai, am I understanding correctly? If so, aside from tests (which are complicated for this due to the infrastructure requirements), this is a trivial change, maybe 5 lines, and we should just do it.

[hongdai]

@stephentoub Yeap, that's exactly what I ask. Thanks for helping clarify!

[stephentoub]

@hongdai, does this do what you want?
https://github.com/stephentoub/corefx/commit/8499dc22409f59db6b83ad8a4da9cfac9357b6f9
If it looks like what you're hoping for, I'd appreciate it if you could test it out, as I don't currently have infrastructure set up to do so.

[hongdai]

@stephentoub I'm happy to help testing. Please be aware it will take some time as we don't have automated tests for this scenario. I will get back to you once it's done.

[stephentoub]

Thanks! I've put it up as a PR as well:
https://github.com/dotnet/corefx/pull/18627

[stephentoub]

Reopening for validation of the fix...

[karelz]

@stephentoub Did you mean to reopen?

[stephentoub]

Did you mean to reopen?

Oops! Yes :) Thanks.

[karelz]

@hongdai did you get chance to verify it? We are getting closer to 5/10 ...

[hongdai]

@karelz I should be able to do it next Monday - waiting for server merges to happen in our branch.

[karelz]

Great, thanks!

[karelz]

@hongdai any update?

[hongdai]

The test has passed!

[karelz]

Thank you @hongdai for confirmation!