dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.27k stars 4.73k forks source link

Expose interface to support SASL compliant authentication protocols #19860

Closed Priya91 closed 4 years ago

Priya91 commented 7 years ago

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 commented 7 years ago

cc @karelz @saurabh500

refer comments here and here

Carbenium commented 7 years ago

@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 commented 7 years ago

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

Carbenium commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

Any updates on this?

karelz commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

karelz commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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

karelz commented 5 years ago

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

karelz commented 5 years ago

Duplicate of dotnet/corefx#36896

davidsh commented 4 years ago

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