You can clone with
HTTPS or Subversion.
For those who use NuGet Gallery on-premise (rather than just nuget.org), it'd be a big win for the Gallery to support LDAP for authentication rather than (or in addition to) the NuGet Gallery database authentication store.
Depending on how much interest there is, I might be able to contribute this change.
I've often wanted OAuth login support as well, and we've done some work with Active Directory Federation inside Microsoft. Might be time to start planning a more robust, pluggable, authentication system.
Excellent - OAuth + LDAP + native DB would cover most bases I think.
We'd be happy to take a pull request. As @anurse pointed out, it would be really nice to have OAuth on the gallery.
I have written an implementation that enables LDAP authentication.
The pull request is here: #562
The fork is here: https://github.com/grenade/NuGetGallery-LdapAuth
What if the status of this pull request? Seems to have quieted down over the last few months.
We'll try to take a look soon. Since the fork is available, and LDAP wasn't needed for nuget.org, we hadn't gotten to this yet.
Sorry, I don't know the best place to ask this question as there is no issues tab on the fork. I've tried running the fork on top of an existing installation of the project, and got an error that DbMigrations could not be applied because it would remove data. What can be done to massage the migrations through?
Not terribly long ago, we added some migrations that shrank some text fields from nvarchar(MAX) down to have logical lengths. I'm guessing you have data in your database that would get truncated.
The changes were made in commit e1f2302.
We're also looking to host an internal gallery... this would be huge! I was going to try and see if I could get the fork running on my machine. Seems like there would be a ton of merging to do since this was last updated.
We're working on some other Auth stuff as well and hopefully LDAP will be able to be a more modular plugin to that model. I don't think we'd take LDAP auth in the main code at first, but hopefully it would be easier to maintain a clean fork that just adds that component.
+1 For LDAP Auth. We want this for our Enterprise gallery. Is there any talk of symbol server support as well or can I just add use this in my NuGet Gallery installation?
+100 for LDAP
Now we have to use fork by grenade and I really can't imagine how to merge it with actual code.
We are also looking for some other solution for enterprise nuget repo, but unfortunately with no results.
@maslakov We eventually went with Artifactory Pro, which has built-in NuGet support, including LDAP auth.
I've started a port of @grenade work with LDAP into a current version of the gallery. If there is any guidance in cleaning up the auth process, I'm all for incorporating it as part or a separate issue.
Any news on the integration? LDAP for NuGet Gallery sounds really promising. We are currently using ProGet and it just causes so many problems, needs to be restarted all the time etc.
We still don't have direct plans for LDAP as our primary audience is the nuget.org site (we definitely want to make it as easy as possible to host private galleries, but we're a very limited team :)).
We do have very concrete plans for pluggable auth in the near future (specifically focusing on OAuth right now). With that model, it would be quite straightforward to maintain an LDAP authentication component that could easily be integrated into the Gallery. It wouldn't be as simple as just editing config, but it should be a very light fork that just adds a few classes.
Also I'm looking foward this implementation
If there is an issue or fork related to the pluggable auth mentioned earlier, I am happy to work with other contributors for implementing the LDAP module. I am now working with a third enterprise client who require this and it always feels sloppy to make them use my fork rather than the main gallery code.
#253 is the closest to discussion on that topic. We're working on a few elements to make "shallow-forking" (i.e. forking the gallery to make minor additions/rebranding) easier and Authentication is one of them. There's now a PR out to add support for these pluggable authenticators, and while they may not be perfect for LDAP yet, we're certainly willing to take infrastructure changes to make them more pluggable (though we are less confident about taking a full LDAP feature :))
I want to use an OpenID. I don't want to create account to contribute.
If you add barriers to people who want to help, you are going to get less help.
@anurse I'm starting work on this with the newer code and looking over the new credentials code - It doesn't look too easy to drop an assembly in but rather that it requires integration with the NuGet Gallery code.
Does that sound right?
Yes, some integration with the gallery is still required, though it's much less invasive than it would have been prior to the new credentials code. Happy to help out if you have specific questions about the integration :).
Is there any progress on this? Any plugin available for LDAP auth?
Working on it right now.
LDAP support is a bit of an oddball area here - I'm betting no one wants to setup a separate LDAP application in which the sole purpose is to have a username & password screen that then sends them back to nuget gallery when the gallery is on the same network as the LDAP. It would ideally reuse the existing username/password boxes that'd also support autoenroll as @grenade did.
I'm also trying to figure out the best way to fit it without being invasive to the existing local usercode as a result.
Well it would ideally use integrated authentication to avoid username/password boxes, but at least allowing AD login is a good MVP.
I can only add another +1 from my side to get Integrated Auth
This just isn't something we're able to prioritize in the core Gallery. We'd be happy to accept PRs which improve the extensibility of the authentication model so that this can be easily integrated into custom Gallery deployments.
is it actual?
+1 for windows auth