Runtime: Expose interface to support SASL compliant authentication protocols

[Priya91]

In .NET the authentication protocols implementation is available as an internal type NTAuthentication but the API surface area is designed for Windows compatible NTLM, Kerberos and WDigest auth. We need an API like IAuthenticationModule, that is more generic, and not tied to WebRequest.

[Priya91]

cc @karelz @saurabh500

refer comments here and here

[Carbenium]

@Priya91 Do you already have a rough time frame for an implementation? I think this API would help a lot of people to get Kerberos authentication going.
Unfortunately I haven't come across any library which could be used on Linux in the meantime.

[karelz]

@Carbenium the milestone is Future, so there is no timeframe currently.

[Carbenium]

Thanks for the answer.
Is there any chance you might consider this for 2.1?
GSSAPI, which this API would expose (?), is basically the only authentication method that does not have any decent .NET support.

Just as an example the people from MailKit would probably be interested in this feature, since it's the only method missing from their list.
I guess even https://github.com/dotnet/corefx/issues/2089 might profit from this?

Anyway, keep up the great work. It's a pleasure to see .NET Core evolving :smile:

[karelz]

We have a long list of high-value work items in Networking for 2.1 already. Unless there is strong evidence of business need (more votes, ask from important partners, like MailKit, etc.), it will likely not fit into 2.1.

[jorgebay]

I wanted to voice our interest in seeing SASL support on a generic API (with GSSAPI support) on .NET Core, according to rfc 4422.

Though it may be possible to create a custom solution for Windows-only with .NET Standard 2.x (using SSPI), for a multiplatform enterprise-friendly .NET Core application a SASL client is needed.

As an example, Java has very nice API: Sasl.createSaslClient(mechanism, ...), Sasl.createSaslServer(mechanism, ...).

cc @csplinter

[Priya91]

Any updates on this?

[karelz]

No update. It is early for 2.2 plans. This is not top paint-point though.
Do you have some interesting scenario in mind @Priya91?

[Aarthiumayaval]

Voicing interest for public GSSAPI in Dotnet core as soon as possible. Can you please let us know when is 2.2 release? will System.Net.Security will have public GSSAPI in 2.2 ?

[Aarthiumayaval]

the above comment is a question of GSSAPI support from non windows. when we can have public GSSAPI support from LINUX and MAC ?

[karelz]

@Aarthiumayaval what kinds of scenarios do you need it for?
Currently it is not too high on our backlog (i.e. unclear if it happens in 2.2). Understanding some of the scenarios better could help prioritize it higher.

[Aarthiumayaval]

Hi,

We are having dotnet security client library which talks to our linux teradata server using SPNEGO(which is turn use Kerberos ). Our application runs on net framework(452) and so we are using AuthenticateAsclient() implementation. Now we are porting our library to net core so that we can run on LINUX and MAC(dotnet data provider is the application which will use our security library). For this we need GSSAPI public API from LINUX/MAC platform too other than windows.

Thanks,
Aarthi.

[EDIT] Remove email reply by @karelz

[Priya91]

Do you have some interesting scenario in mind @Priya91?

Hey Karel! We are using an azure relay library (azure/azure-relay-dotnet), which maintains a custom implementation of ClientWebSocket as it targets netstandard1.3, and the ClientWebSocket is not available there. So, I was extending that custom implementation to support proxies, and as a result of which I had to handle authentication for the proxy. If this library had been available, I could have used this library to get the authentication challenge tokens, instead of having to implement the auth protocols from scratch. Ofcourse the proper solution would be for the azure relay library to support netstandard2.0 and for us to upgrade to netcoreapp2.1 (to get the proxy support in ClientWebsocket), both of which are out of scope at the moment.

[jorgebay]

Here is the use case we are interested in support:
We have a C# client driver library for our database (DataStax Enterprise). The server supports GSSAPI (Kerberos v5) authentication. We currently support GSSAPI authentication via SSPI (Windows-only APIs) on the C# driver, we are interested for a solution that runs on both Windows and Linux.

We need a way to authenticate the client to the server (server-to-client would be needed for anyone interested in developing a C# server with Kerberos support) on any platform.

[blowdart]

OK folks, give me survey love :)

https://microsoft.qualtrics.com/jfe/form/SV_9LvT1hbZ2nHHcFv will help us understand what you want, you might even get followup calls to discuss it in greater detail. Free feel to spread the survey link around.

[davidsh]

We expect dotnet/corefx#36896 to be the answer to this issue.

[karelz]

We believe it will be mostly solved by dotnet/corefx#36896

[karelz]

Duplicate of dotnet/corefx#36896

[davidsh]

Tracking issue moved to: https://github.com/dotnet/runtime/issues/29270