There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?

40

Closed

Authentication support for private repositories

description

As i got the state of the current code base it is not possible to authenticate through any HTTP supported mechanisms (Basic+SSL/NTLM/....).
The current architecture does not make it easy to integrate such a feature. The console window in Visual Studio does not allow to call unmanaged code as the credui standard networking credentials dialog.

I think it would be a great addition especially to corporate environments to be able to authenticate against a repository.

Are you interested in starting the discussion around this topic? Are there any existing plans?

This would be a huge step foward for our
www.myget.org "private feed as a service". We would love to offer a real private feed protected by either basic auth of, which would be even better, by using Windows Identity Foundation. +1!

I then modified NuGet.HttpClient and added a CredentialCache that mapped my URL with the correct credentials. This was bound to the request in InitializeRequest(). I hard coded for the test.

I re-ran the nuget list command and sure enough, it authenticated and returned the package list. Sweet!

I'm now in the process of updating the Add Package Source dialog to allow the user to specifiy credentials. Those will be encrypted and stored in NuGet.config. This will then be used to build the credential cache.

@Kiliman - this sounds really nice. So for VS, the credentials would be set in the "Package Sources" dialog? How about nuget.exe? Something similar SetApiKey? I think we need to figure out how this authentication relates to the publishing API
key. I doesn't seem right to same a login/password for read access and an API key for write access.

And the dialog will be the Windows-provided credentials dialog, right? We already have one in the code base, in the PowerShellHost project (NativeMethods.cs). We need to factor that out somewhere else to reuse it in the Options project.

Also, please make sure the code change will work with Integrated Authentication too. I think that's the more common case in enterprise environment.

@TripleEmcoder, The credentials are stored in NuGet.config which is also used by the nuget command line. So if you've already added a package source URL with credentials in VS, then it'll use the correct credentials even from the command line.

However, if you don't have VS installed (e.g, a CI server) then yeah, I see where you'll need something like a SetCredentials command in nuget. I'll add that to my TODO list.

As for how this relates to APIKey, I think they're separate use cases. I think the primary use for the new authentication support is to only grant access to certain users even if the NuGet repo is publically accessible. For example, DevExpress embeds an authentication
token in the URL to restrict access to its customers. With authentication, they can simplify this whole process.

Also the new MyGet project (myget.org) would benefit as well by authenticating users to their own private feeds.

@Kiliman, let's not store credentials in nuget.config. We already have support for authenticating proxies which uses the Windows credential store for properly prompting and storing credentials. Ilyalozovyy was working on implementing this feature, so please
start a discussion with him. I don't want your two changes to step on each others.

@haacked & @Kiliman I am now back from my vacation and I am back on finishing up the Proxy support for the last step which is Visual Studio package.
I was hoping that we could refactor the proxy functionality to re-use it's basic framework and use it for this feature which I've already talked about with @davidfowl

Ok, we just discussed this over here and we agree that Proxy support is a bit different than Authentication support. Proxy support depends on what network you happen to be joined to. That can change as you take your laptop to different places for example.

But authentication information is strictly tied to the specific package feed and is unlikely to change. So it does make sense to store auth credentials with the package source rather than requiring prompting.

Kiliman, can you start a discussion with the proposed changes and a mock-up of the UI? It's easier for people to join a discussion than to comment on the issue (Issues don't allow responses via email).

@haacked there seems to be an existing discussion that was started and we can use that to continue this discussion:
http://nuget.codeplex.com/discussions/237995
I would also like to comment on the proxy support and the mentioned difference between the proxy and repository authentication. The functionality that they provide is different
however the feature of discovering credentials is not. The way that the credentials are stored and retrieved for the proxy functionality can be totally re-used for the authentication with a small bit of refactoring
by simply changing and possibly re-naming the ProxyFinder to return the credentials for the given url instead of returning the IWebProxy this way we can re-use as much of the code base as possible especially because most of the
code needs to be duplicated in things like nuget.exe, bootstrapper, and the now "excluded" Package Explorer project :)