Community
Participate
Working Groups
This is going to be long-winded. We currently rely on two authentication sources for the various services at eclipse.org: - LDAP: this source contains Committer accounts only. It is an open standard, and just avout every service out there supports LDAP auth - Bugzilla: this application-specific source is used by Bugzilla; however, many other web-based services such as Wiki, Forums, Eclipse Live and Eclipse Marketplace have custom code to query this data source directly for authentication I'm now at a crossroads for two reasons: 1. While deploying Gerrit, I can choose LDAP or HTTP as auth sources, but not both. Committers and Community must be able to log in, and I must reference Committer groups stored in LDAP, LDAP seems to be the obvious choice, but excludes the user community. I either choose LDAP, or write some custom auth code. 2. For the new Project Management infra, it is highly desirable to centralize auth. The most straightforward solution is to a) import Bugzilla accounts into LDAP b) Configure Bugzilla itself to use LDAP for auth c) Configure the Eclipse Site login to use LDAP for auth (that will cover Wiki, Forums, Friends) d) Alter Live, Marketplace, the current Portal and all other services to use LDAP for auth Three complications arise from this approach: - Bugzilla stores passwords using the SHA-256 hash, which is not (easily) supported by LDAP. The workaround here would be to import all the user data except the password, and send out an email to all the Bugzilla users to notify them of the new auth configuration and ask them to set a new password via some crafted page. This is a bit disruptive, but I've seen this type of activity happen before. - Since we currently rely on the Bugzilla "Create An Account" page to allow users to sign-up for our various services, we would need to disable that and write our own page, which would create an LDAP entry. This is a highly desirable step towards a single sign-on and an official "Eclipse.org account". - It may not be possible/easy to migrate a bunch of services over to LDAP auth without causing a large disruption. To bridge the gap, the "Create an LDAP account/reset my LDAP password" pages we create to solve the two issues above could not only generate LDAP auth info, but also mirror that auth info to the Bugzilla database in SHA-256 format. That would allow the "legacy" Bugzilla auth source to continue to be used.
Sounds like something that really needs to be done anyway. There are so many benefits to a single sign-on.
After some fiddling around, I think it will be easier to simply NOT import the Bugzilla sha256 password into LDAP, and request users set a new LDAP password (which we will hash sha1 to LDAP and sha256 to BZ). Here's the plan: 1. Develop a "Create an account/reset my password" page to accompany our site login. That will enable users to create a new "global" LDAP account. 2. Import existing BZ accounts into LDAP, carefully eliminating committer BZ accounts (their committer account is already ldap-enabled). 3. Test various services for LDAP authentication (mostly BZ) 4. Send out an email to all BZ users asking them to provide a new password (they will need to supply their 'old' password, which we will verify against the existing sha256) before the change is accepted 5. Gradually update services to use LDAP auth instead of the shadowed BZ auth
Will changing bugzilla to LDAP affect tools like Mylyn? I've CCd Steffen just so he's aware of this.
(In reply to comment #3) > Will changing bugzilla to LDAP affect tools like Mylyn? I've CCd Steffen just > so he's aware of this. Great question. AFAICT, users will still be submitting their email address and password to the same old web form... It's the underlying auth mechanism that will change. So I don't think Mylyn will need any code changes. Mylyn users will have to update their password as I mentioned in my previous comment. But for that I'll be sending out an email to all the BZ users.
Thanks Ian. Mylyn relies on the standard post request/cookie for Bugzilla authentication. If that doesn't change I don't foresee any problems.
As long as this is going to be an invasive change for users, how about looking at a technology like BrowserID (https://browserid.org/)? AFAIK BrowserID shouldn't stop Eclipse from using the existing LDAP authentication system but should allow for single sign-on for more Eclipse based services without giving all service owners access to LDAP. I can follow-up with some colleagues working on this technology if this of interest.
> As long as this is going to be an invasive change for users, how about looking > at a technology like BrowserID (https://browserid.org/)? https://bugs.eclipse.org/bugs/show_bug.cgi?id=243930#c13 s/open id/browserid/g
(In reply to comment #7) > > As long as this is going to be an invasive change for users, how about looking > > at a technology like BrowserID (https://browserid.org/)? > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=243930#c13 > > > s/open id/browserid/g Some excellent points Denis. Clearly this would be a big undertaking. I spoke directly with one of the guys who works on BrowserID. If you're interested in pursuing a project like moving to BrowserID in the future I can try and set up a meeting so that you can speak directly with the guys who implement the technology (if that's helpful).
I have this working on my local dev environment. - LDAP account creation, account updates (mail, fname, lname) & password reset - Site login uses email address for auth, then performs LDAP auth - Site login "logs into Bugzilla for you" to make sure your local BZ account is created, and your local BZ account password is updated. What's left to do: 1. Test this out with Nathan and Matt 2. Create an import script that dumps bugzilla accounts into ldap 3. Commit changes live, test 4. Upgrade Bugzilla to 4.0 if 3.6.3 ldap auth is borked I'm planning on doing 3 and 4 before the XMas shutdown. I'll post dates up shortly.
Plan on committing changes Thursday: http://www.eclipse.org/org/press-release/20111219_eclipse_account_changes.php
I just found a "Eclipse.org Account Change" email in my spam folder. This email account is hosted by gmail, I guess lots of you may have the same problem.
Just noticed that IPzilla is not connected to LDAP. It uses the old Bugzilla email with the old Buzilla password before migration. Did that fall off somehow or is it just my account that isn't synchronized?
(In reply to comment #12) > Just noticed that IPzilla is not connected to LDAP. It uses the old Bugzilla > email with the old Buzilla password before migration. Did that fall off somehow > or is it just my account that isn't synchronized? There are a whole bunch of services that still use the Bugzilla DB to authenticate, and we need to migrate all of those as well. The mistake I made was claiming committers didn't need to change their LDAP password. When you "log in" to Bugzilla using LDAP, Bugzilla runs a SHA-256 on your password and stores it locally, which, in fact "syncs" it with LDAP. But since none of the committers have re-logged into Bugzilla since the auth change, the BZ password is still the old password.
Denis, I did re-login to Bugzilla but the IPZilla password is still the old one and not in sync with the LDAP one. Same is true for the portal. Portal: committer ID + LDAP PW: SUCCESS email + LDAP PW: FAILED email + old Bugzilla PW: SUCCESS IPZilla: committer ID + LDAP PW: FAILED email + LDAP PW: FAILED email + old Bugzilla PW: SUCCESS Bugzilla: committer ID + LDAP PW: FAILED email + LDAP PW: SUCCESS email + old Bugzilla PW: FAILED
(In reply to comment #14) > Denis, I did re-login to Bugzilla but the IPZilla password is still the old one > and not in sync with the LDAP one. Same is true for the portal. I have the same problem, I can log out and into bugzilla with the email+LDAP, but IPZilla still wants the old bugzilla password. PW
I'm in the same boat as Paul.
(In reply to comment #15) > I have the same problem, I can log out and into bugzilla with the email+LDAP, > but IPZilla still wants the old bugzilla password. Rats. I'm on it.
> I have the same problem, I can log out and into bugzilla with the email+LDAP, > but IPZilla still wants the old bugzilla password. *sigh* I was under the impression that when you log into Bugzilla with the email+LDAP password, it automatically updated its local database with the correct password hash. I swear I had tested this to be true, but it is not the case. rats rats rats rats rats So I've altered our site login / password reset / password change mechanisms to re-hash the password with SHA-256 and store it in Bugzilla, even at login time. This will allow our sites that still use the BZ db to authenticate correctly. However, IPZilla won't get the new password has unless people re-login to dev.eclipse.org/site_login again. I can only think of 1 solution: Put a prominent notice on IPZilla's home page, asking users to re-login to the site login if their IPZilla login doesn't work. *sigh* I can't wait for all this auth stuff to be fully centralized.
After logging in at dev.eclipse.org/site_login I can confirm that the passwords are in sync and I can log into IPZilla using the same password as Bugzilla (which continues to function correctly). Thanks, Denis.
> are in sync and I can log into IPZilla using the same password as Bugzilla <best Matrix imitation> There is no bugzilla password </> Thanks for verifying. I'll plop something up on IPZilla.
Removing the blocker for Gerrit, but I want to keep this bug open to track the sub tasks of migrating auth away from the Bugzilla DB.
I changed my password using https://dev.eclipse.org/site_login/myaccount.php but when using git.eclipse.org I get the "Your password has expired" error. Thoughts?
> I changed my password using https://dev.eclipse.org/site_login/myaccount.php > but when using git.eclipse.org I get the "Your password has expired" error. There could be some attribute caching involved. If I look at your account, it says that your password was changed today. Since it's already been over 30 minutes, can you confirm (via webmaster@eclipse.org) if it's working or not? If not, I'll force the caches to clear and we can try to solve this that way. Thanks
This is all done.
Fixed is even better.
