Closed (won't fix)
Project:
Drupal.org infrastructure
Component:
Other
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
17 Feb 2009 at 20:50 UTC
Updated:
27 Sep 2013 at 11:07 UTC
As part of the drupal.org identity setup, we should set up OpenID module on all subsites and configure it to only let people use their drupal.org identity to log in. We should not allow people to register with any other identity (including a username, password). Only users on the master site should become users on any subsites.
Comments
Comment #1
chrisschaub commentedHas any work been started on this limiting id server feature? I'm curious if there's a good place to hook in to the openid provider module or some other approach. This would be really handy for dev teams that have a central intranet openid Drupal side -- and want to have logins on all of their client sites. But don't want to allow logins from any other openid servers.
Comment #2
gábor hojtsyOn the subsite setups (which issue is about), we'd limit by the format of the OpenID. Limiting the OpenID server to serve login requests from only some hosts might be more tricky. Considering possibility of fake hostnames and such.
Comment #3
Chris Johnson commentedI think I must not understand exactly what it is you want here, Gábor.
The current D6 OpenID client built into core has an admin config option for "List of allowed domains that can be logged into with OpenID." It's at http://example.com/admin/settings/openid_client_domain.
What am I missing? Couldn't we just put drupal.org there and that would suffice?
Comment #4
gábor hojtsyI did not say we need to write code to solve this issue :) It is kept up until we get there, so we do not forget to do it. First we need to resolve outstanding issues with the provider module. Stuff I've opened issues for there.
Comment #5
chrisschaub commentedNot to derail the issue, but I don't see any such option (as mentioned in #3) on the latest Drupal 6.
/admin/settings/openid_client_domain
Does not exist. Do I need HEAD version? I'm on 6.10. Don't see any mention of this anywhere in cvs. Was this feature removed?
Comment #6
joshk commentedI will take the lead on this during the upcoming sprint as either Greg or I will need to implement this for g.d.o.
Comment #7
gábor hojtsyWell, setting up the clients themselved would not get us too much further unless some hard decisions are made at #353425: Allow other sites to use drupal.org user identities for login (in D7 infrastructure, without shared secrets), namely:
1. Do we actually run the OpenID Provider module (tests seem to show it runs fine for us, but has some ugly UI problems)?
2. Do we serve as a public OpenID server?
3. Do we set up another Drupal site at say id.drupal.org to host this or will it be part of drupal.org?
These are all to be answered there. I've opened issues to solve in OpenID Provider module to make it look better for our deployment (assuming the answer to 1 is yes). All related issues are at http://drupal.org/project/issues/search?issue_tags=drupal.org%20identity
Comment #8
Chris Johnson commentedMy take on Gabor's latest questions.
1. Yes, we should run the OpenID Provider module. We can improve the Drupal core and contrib code incrementally if the UI is not up to par. This will benefit Drupal in general, as well.
2. Absent legal problems which stop us, I would say we do nothing to prevent public use of our OpenID server, but perhaps we not promote it as such.
3. It sounds like, so far, the use of id.drupal.org will simplify some of the upgrade steps needed to move from the older Drupal auth to OpenID.
Comment #9
drummNot part of the redesign, but could happen anyway.
Comment #10
gregglesI don't think we are going to remove bakery any time soon.
So, this seems like it is about using OpenID on drupal.org (i.e. from core) so I'm updating the title.
Or, this should be marked won't fix.
Comment #11
damien tournoud commentedOpenID in Drupal 7 got better. We might reconsider whenever we will be rolling Drupal 7.
Comment #12
boris mann commentedStill would like to see people be able to create new accounts using OpenID. It's part of core, turning it on shouldn't be an issue. Broken, you say? Guess we'll have to work in some bug fixes for 6.18 then.
Comment #13
colanSubscribing.
Comment #14
juliangb commented+1 for this.
It'd be great to have one less password to remember.
Comment #15
c960657 commentedAre there any particular improvents in D7 that you miss in D6? I guess AX support is an importing thing that is still not in D6 (#634562: OpenID AX support), but I don't think this is a show-stopper (it only makes the sign-up process a bit less automatic for some users).
There are a few backports waiting for review:
http://drupal.org/project/issues/search/drupal?status[]=Open&version[]=6...
Comment #16
danepowell commentedDefinitely +1 for seeing OpenID logins on Drupal.org - I think it's bad form to distribute such a useful feature in core and then claim that it's not good enough for D.O! :)
Comment #17
colanBecause of some of the protocol problems that have just been fixed, maybe we should wait until the site gets upgraded to D7, but either way, wouldn't be it as easy as one of the admins running this single command to allow logins?
Users who care can then start logging in with their OpenIDs, and everyone else can ignore it. Or am I missing something? I have a feeling it won't affect performance too much as not many folks will be using it.
Making the title clearer so as to distinguish it from #353425: Allow other sites to use drupal.org user identities for login (in D7 infrastructure, without shared secrets).
Comment #18
eliza411 commentedClosing old issues. Please re-open if needed.