Allow other sites to use drupal.org user identities for login (in D7 infrastructure, without shared secrets)

I think this would be really great to have an OpenID server, and I agree with Gabor that this could be an important first step. In fact, I believe this is in the critical path of the redesign process, so I'm marking this critical. It will make the task of redesigning and splitting d.o possible. The sooner we can tackle this, the better.

How would you want to handle this? It does not seem as if the core openID module could act as a server, so we'd need to run other software? Could we bug somebody to create a Server version?

I don't think I want to rely on a 3rd party for this.

I was always assuming we'd run our own server (whether it is a Drupal module or not).

The project page http://drupal.org/project/openid says that there is code to run a server with Drupal in one of the older versions. We should ask walkah how stable that is and then port it.

Cool, in that case we could simply switch that module on on d.o and be done :)

I had some long discussions with walkah about this and asked him to writeup his thoughts. He gave me this doc which we always considered a first draft. I didn't share it because I asked some followup questions of walkah and received no reply.

Please read attached doc - is informative.

As I understand it, we will need OpenID clients on *.d.o either way. Unless we're planning to require that users use only Drupal's own provider, would it make sense to go ahead and install the D5 OpenID module now so that users can begin migrating to OpenID already? Or are we planning to lock it down to just the one self-hosted provider? (Many people already have OpenID accounts that they could use, and may prefer to continue to use.)

That makes sense, thanks. I guess allowing additional provider logins is a post-upgrade feature request then.

I'd just like to mention Darren Ferguson and I have spent an huge amount of time debugging and extending the openid_provider and openid_ax modules for Drupal 6. They will be an important part of the software we provide to our biggest customer, so we have a lot of interest in making them work and work well. I'd like to see where we can cooperate on this to save duplicated efforts.

Thanks for taking the time to start this issue, Gabor!

Yes, Moshe and I have had some discussions about how to implement this - what things could look like, etc for converting the *.drupal.org infrastructure to OpenID based logins.

The current work to follow is the OpenID provider module : http://drupal.org/project/openid_provider

Yes, Darren Ferguson has put some work in and he and I have spoken about future directions.

I am traveling today but will keep an eye on this - and am still willing to lead the direction on the implementation for this (but will greatly appreciate help from Darren and others).

subscribe

subscribe

subscribe

One of my site is upgrading to 6.x, and actually started converting external drupal user to local accounts. Wish I have seen this issue earlier. I take it we can safely assume that drupal.org accounts will be continue supported (whether through transitional site_network.module or the new openid.module)? If that's the case, I will keep all drupal.org account on our site.

Now a noob question, openid is new to me. According to Gabor's #1 post:

I think we should also provide a Drupal 6 and 5 module which would replace or override drupal.module and intercept drupal.org usernames. When such usernames are used, the module should inform the user on the new correct OpenID to use to log in.

Does it mean username will have to change when this openid server takes place after drupal.org upgraded to 6.x? Or it's just internal check, and will be transparent to external site?

Also, if the decision is made. I think there should be a front-page post to announce the plan, to assure the drupal.org accounts will continue to work after 6.x upgrade. It affects many sites upgrading to 6.x. It would be helpful to me and save me some time, if I learned it earlier. Thanks.

Wouldn't username.id.drupal.org be more conventional? The other OpenID account I have uses that format. (Says someone who is not even close to pretending to be an expert on the subject.)

@Crell: openid.net/get lists some formats, four of which are host/username, five are username.host. Personally, I would opt for id.drupal.org/username.

So, how will we go about doing the migration? Actually setting up the infrastructure for single sign-in amongst *.drupal.org implies more than just setting up an OpenID provider. I have started a book page listing the necessary steps.

This won't happen this week.

i hope
- *.d.o will allow all openid providers, but make sure it prefers id.d.o
- the openid will be more a sso solution within *.do and not for a global internet id aproach (supersilo the *.d.o silos)
- an id on id.d.o can not be used outside *.d.o (hence only whitelisteing *.d.o). drupal does not need to become an identity service provider (at this stage). there are lots and lots of downsides on being an identity service provider (legal, start ticket etc)
- users can pick from the d.o/user (aka id.d.o) page the accounts the have on [infra|association|groups|etc]d.o. when one logs in wth the old credentials on etc.d.o a message will apear that accounts will be merged with main id of id.do.o
- all signups will go to id.d.o
- al passwords resets will go to id.d.o
- when a person logs in on etc.d.o with an id that hasnt been merged from id.d.o, a warning message will be displayed with a link towards id.d.o
- after x month whn a user logs in on etc.d.o with an unmerged account, it will redirect to id.d.o
- no ""local" is'd will be left on the server except one or two for admin puposes when the id.d.o is down (only last resort)
- we should look on how the yahoo/flickr intergration went ?

btw: it might not happen 'this week', but will happen.

Hi Gabor

I don't get how *.d.o would allow any OpenID login but also limit signups to id.do (people could then sign up with a different OpenID, so I think these two points are contradicting)

What I meant was allow johndoe@openid.example.com to authenticate on d.o but if people will go to groups.drupal.org/user it will redirect to id.drupal.org. Even not to sure if we should enable oher OpenID's

d.o is already an "identity provider" in that is has drupal.module enabled and will have the successor site_network enabled for quite some time to not break this overnight... we'd still might want to provide a migration path for that to OpenID, instead of shutting that existing service down

Yes, however both technologies are completely different.

If I use my user@drupal.org id to post unwanted content on example.com the admins of example.com can give all data to an authority to investigate if the demand this. example.com has all three elements of AAA (accounting, authorisation, authentication)

However if I post with my user@id.drupal.org account unwanted content to example.com and authorities demand all logging to make sure user@id.drupal.org is who he claims he is, the admins can only provide half the log data. This since the AAA model has been taken to parts, Accounting and Authentication on the ISP side, Accounting and Authorisation on teh endpoint. This means that the ISP (id.drupal.org) has to offer log data as well; start and stop tickets. Meaning, if we enable our OpenID to be used elsewhere on the net, we will run in to situations where we have to give data to authorities. A complex task, legal and time wise. Note, the current user@drupal.org method works technical different.

Other downer when becoming an ISP; people will expect uptime of service that is not our core.

So I think it is better to use our legacy method exists for a year and then when d.o hits 7 drop support.

There is a lot of use for drupal.org logins within the Drupal user community but outside the Drupal domain. See http://drupal.org/node/371237 for one use, demonstration sites for Drupal themes and Drupal modules. Current demo sites provide a login of demo/demo then people with no Drupal experience go mad with the settings and the poor site admin has to reset everything. Locking down the site stops experienced Drupal users from conducting useful experiments. If Drupal was an Open ID provider of any sort today, we could set our demo sites to accept Drupal users with a higher level of access.

Has anybody ties with existing OpenID providers? How do other providers deal with this?

Bert: you're overly concerned. This is the exact same situation as with the Drupal logins. example.com could be big scary site that user posts on, that just happened to have Drupal logins enabled. I understand your technical points about AAA ... but it's really not warranted.

To properly vet people across all d.o. domains, we will need to verify a login. Likely this will still be with email, even if we allow account creation using an external OpenID login. The alternate is to require one full user / account sign up on d.o. for new users, just as works today. Then people can add external OpenID accounts to login with.

In short:
* I think there are less legal problems than you think there are -- please go dig up proven examples rather than made up ones (or contact the OpenID foundation for their opinion)
* if we're going to "lock down" usage of OpenID -- which means writing a bunch of extra code that doesn't exist today -- then we may as well not use OpenID
* there are many benefits to using an open standard like OpenID, that works the same on d.o. as it works elsewhere
* I "trust" Drupal a lot more than many other big providers, and would be ecstatic to be able to use my Drupal ID in a wider context

@kvantomme Yes, my company runs GetOpenID.com. It's a little old (but it works), and we'd happy update it or apply our knowledge from implementing it to help the Drupal project.

subscribe

subscribe

subscribe

Looking forward to progress on getting an drupal.org account OpenID server so those of us using the site_network.module can stop using it ASAP.

I consider this of a very low-level priority now. So low that I am inclined to mark it "won't fix".

I am very sad that we are back in "Drupal Ghetto" land, where we rolled our own for SSO rather than working in the context of the wider open web and using standards.

That is all.

We can still discuss allowing OpenID for authentification on drupal.org itself.

How the running of yet another OpenID server on d.o was going to help the web will remain a mystery, I guess.

I concur with Boris. I don't like OpenID much, but I do like open web and using standards.

You don't like it but you want us to use it?

That's rather strange.

Anyway: the offer is openid client or nothing.

Request to turn on OpenID module at #556220: Turn on core OpenID module for d.o.

I understand that bakery is being used "internally" for the *.d.o. family of sites.

This doesn't help solve the issue of using d.o. "credentials" for external authentication that used to work with distributed auth. This would enable / allow the continued functionality of allowing people with d.o. accounts to easily sign into any site that is an OpenID consumer.

4 years ago I created an account on the spreadfirefox site which suggested that my login to that site was part of a network of sites using Drupal and that I could log into all of them using the spreadfirefox credentials. That planted a seed in my mind that made me think "oh, maybe I should learn more about Drupal." I'm not so self-important to think that my contributions should justify us running a centralized identity server, but I think that this ability to use Drupal.org identities in other places may have played a role in the growth of Drupal over the last years and we should consider installing OpenID server on a D.o address:

1. To continue providing a service that we have provided for X years (where X is greater than 4)
2. As a way to continue promoting Drupal.org as a site that embraces and promotes awesome technology

I am all for promoting awesome technology. However, OpenID has a distinct lack of awesome.

The "service" we provided was rather laughable and people should have called us out on the distinct lack of security that it had.

The "service" is also no longer provided for about half a year. I've yet to see the many complaints about that. I think Boris was the only one who even noticed.

I also don't see that the Infrastructure team has the capacity to run an OpenID server atm.

If we should run an OpenId server at later time, it would not be integrated with the main site. In principle, anybody could run an openID server as "openid.drupal.org" as long as he get's the subdomain from Dries.

From Greggles:

As a way to continue promoting Drupal.org as a site that embraces and promotes awesome technology

I would modify that to say "As a way to continue promoting D.o. as a site that embraces and promotes awesome, standards-based open web technology". I hate hate hate that we "rolled our own" SSO solution. But I'm not going to get into that here.

I've changed the title of this issue to clarify the goal -- as I see it -- which is to use my trusted Drupal.org identity as an OpenID identifier.

As Gerhard points out, there are multiple ways to implement this.

1. Local server

Implement / run an OpenID Provider directly on Drupal.org so that e.g. drupal.org/user/4426 can be used as an OpenID to log into other sites.

2. Delegation (local)

Use drupal.org/user/4426 as the OpenID identifier, but put the necessary headers on each user page so that a delegated server is run at, for example, http://id.drupal.org. This would be relatively transparent, other than some user syncing to be done. Choice of server / technology is theoretically open.

It is not true that "anyone" could run an openid server -- the point being to use/reuse existing d.o. user identities.

3. Do nothing

No OpenID identifiers tied to trusted Drupal.org logins, no way to identify other members of the d.o. community on remote websites (e.g. set it so that only d.o. identities can login to a site). No way to point to D.o. 's participation and support of open web standards.

Gerhard says that the Infrastructure team does not have enough capacity. What extra capacity would you need?

Drupal OpenID for logging in all over the internet might be a nice thing to have, but I find that the OpenID is more often *not* the ID that is presented to the open public. Even if we made it so I could login as id.drupal.org/deekayen, more likely than not, most of the sites I would log in to would present an entirely different username. This is a good step for security's sake and why we have at least one module like http://drupal.org/project/alt_login, but only if OpenID was the login and the username was merely a nickname (not used for credentials).

Even Drupal presents a traditional username instead of the OpenID, so as a matter of promoting Drupal, I think that argument is garbage, at least with the current state of dominant OpenID implementations.

I think we have at least one huge issue to resolve before we start talking about adding more services to maintain on drupal.org. One big huge issue of marketing and "embracing awesome technology", to paraphrase earlier comments: upgrade drupal.org to use the latest stable release when it comes out instead of a year or two later.

Even Drupal presents a traditional username instead of the OpenID, so as a matter of promoting Drupal, I think that argument is garbage, at least with the current state of dominant OpenID implementations.

When people provide an OpenID login they'll say "Get a login from X." If id.drupal.org ran people who administer sites that are openid enabled could say "Get a login from id.drupal.org." We happen to know some people who administer sites. That would help market Drupal.

Ok, I'll grant a small token of marketing there, to people who probably already heard of Drupal anyway. There is still the larger, sun-sized issue of falling further and further behind on upgrading drupal.org to match major updates and this feature adding another complication to that process.

I'm not dismissing the idea wholesale, but I don't see a compelling reason to do this. What problem are we trying to solve?

If you convert d.o to an open standard and have D7 core handle the identity from the d.o id, every new D7 site is immediately open to the 75 gazillion people from d.o that will drop in to buy beer or book a holiday in Bundaberg or whatever. When peterx visits the D7 version of example.com, example.com should reserve peterx as the user name for peterx@drupal.org. If peterx is already in use at the site, reserve peterx@drupal.org for peterx@drupal.org. Sites will convert to Drupal and announce on d.o just to get peterx and everyone else visiting. Of course, they would have to offer something interesting to get the visits, a new theme or a free holiday in Bundaberg. After the general upgrade to D7, there will be a couple of million sites where we can use our open id.

I suppose it might be fair to disclose I'm in favor of removing OpenID from core to bring context to my argument.

see also #556380: Remove OpenID from core

@killes: I did not say I wanted us to support OpenID explicitly. I do want us to support an open standard, rather than roll our own without compelling reasons. I find OpenID to be overly complex and highly fragile, having spent many hours in its code. Pick any open standard for SSO that enjoys reasonable community support. If that means the choice is limited to OpenID, then while it may not be a perfect solution, it is still better than a one-off, home-grown, proprietary solution like we have now.

As for running id.drupal.org being difficult -- Drupal community members like David Strauss over at Four Kitchens already run public OpenID providers (http://getopenid.com/), so there's plenty of expertise and experience on doing that available.

@Chris:

The solution that has been developed and deployed is customized to domains that share a common second level domain.

It has the advantage that it does not require any user interaction.

If you are aware of any similar tool, I'll gladly evaluate it.

We could look at CAS, the system Yale runs with Drupal. There are also OpenSSO+OpenDS and SAML-based solutions. The main issue is that we want something that works now, and Bakery has fewer lines of code that the files it would take to start *configuring* some of these other tools. Tools like CAS and OpenSSO would also require us to add significant additional software to our infrastructure.

If we were authenticating to a broad range of software systems, a highly standardized solution would make sense because we wouldn't want to write plugins for each tool. But for *.drupal.org, we're authenticating from Drupal to Drupal.

That said, I'd happily consider some of the standard SSO tools for security reasons once Bakery is broadly deployed and operational. Bakery uses a single, shared private key, which is non-ideal but acceptable across mutually trusting sites.

@Gabor I had totally forgotten about this legacy, I beleive it should be switched off because it encourages bad security processes.

#558038: Switch off site network module

Not part of the redesign and I'm guessing won't fix.

FYI - There is an open task regarding OpenID for d.o. here:

"Set up the core OpenID module on drupal.org"
http://drupal.org/node/375894

Reopening this issue. We were talking about ways to keep data closer to home for #1236290: Decide on a course of action for improving support options on Drupal.org and providing OpenID identities for Drupal.org users would help a lot. I'd be willing to do the testing of openid_provider to make sure that it will work correctly for our purposes.

Bumping this: Maybe someone can give an estimation if this is more feasible in D7.

This would open tremendous possibilities for drupal related community sites and the whole drupal ecosystem.

Given that Open ID has been removed from Drupal 8 as it has apparently "lost the war", I don't think this is ever going to happen.

Tempted to won't fix, but will leave to one of the infra people.

I agree that OpenID is unlikely, but the need is still strong. Maybe d.o. could run a public LDAP server?

To be clear, OpenID was not removed from core because it lost any war. It was removed from core because it was stagnant and behind the standards. It just can't move fast enough in core, and in contrib.

There's no reason to rule out OpenID at this point, in my opinion. It's still widely supported, and extremely easy to deal with.

Agreed with #73 and updating the title.

Mozilla Persona? http://www.mozilla.org/en-US/persona/
There is already a Drupal module to accept the login.

#76: so you mean
https://drupal.org/project/persona (client) and
https://drupal.org/project/browserid_idp (server)
exciting idea!

what would be the next steps to make some progress on this issue?

re #78 - https://drupal.org/node/1293124 how you can make drupal.org awesome and code changes and the sub-pages and linked pages from those guides. One of the biggest things in my mind: has anyone reviewed browserid_idp for security or scalability? Has anyone considered the policy implications of being an identity provider (there must be a video of James Walker and/or others giving a presentation on identity as it related to OpenID that would be useful to review and consider).

drupal.org should definitely not become an IDP - that is not the business we are in

@jbrown - care to expand on that thought with some pro/con?

Becoming an IDP is a truely massive undertaking. This year drupal.org was down for a whole day and also was hacked. If you are an IDP you must be sure that these two things can never happen again. It would cost 10s of millions of dollars a year to achieve this.

If someone gets into your email account you are totally screwed because they can reset all your passwords for different accounts that you use. The same is true of an IDP. An email account is really a poor man's IDP.

One solution would be to only allow signing into *.drupal.org websites with @drupal.org email addresses, but this totally undermines the concept of federated authentication. Email address is the primary key of identity and it's extremely important that people can use the same ID across many different sites, not just drupal.org sites.

One of the goals of federated authentication is to stop people from giving the same password to every website. If they still have to create an account specifically for drupal.org many people will just use a password they already use.

I consider allowing passwords to be entered into drupal.org to be a security vulnerability (and in Core for that matter). With Mozilla Persona the responsibility for looking after the password column is outsourced to an identity provider so it is one less thing we need to pay for.

Allowing users to use any IDP means that they can use something like Google which has very advanced security features like two factor authentication.

Mozilla have been working hard to fix authentication. It would be unfortunate to implement their API in a way that was not their intention.

--

The solution is just to use Persona for authentication on every drupal.org website. However Persona is not yet mature enough for this and is still going through radical changes.

Thanks for the further explanation, @jbrown. I disagree or would quibble with some of your comments, but overall I think you lay out some good reasons that this issue should be marked "won't fix."

thanks for the links @greggles, but it sounds like the first step is actually to get more input/consensus on whether this is something we want to do in principal before deciding on a technical approach.

@jbrown - i'd be curious to hear whether you would feel the same way about oauth.

If its not obvious, I think the primary use case for this is when people want to offer services/websites within the drupal ecosystem but which aren't ready or intended for the DA to take on. A good example would be something like http://drupalmentoring.org which needs the ability to maintain user accounts, and even has a strong reason to link to a D.O user account, but doesn't have ability to get setup with the bakery SSO component for *.d.o. I think the ability to create sites/services like this allow for more experimentation and innovation in our community without additional burden and fragmentation (it also, in theory, makes it easier to integrate that innovations into the mainstream "core" d.o infrastructure at some point if desired) Perhaps a bit more debatable, but I can also imagine many people would appreciate not having to recreate a user account for every drupalday/camp/con/summit website.

Considering this was also previously something that was achievable/available, I would imagine some thought went into the ramifications then as well. Reading past issues, this doesn't really feel like something that was deliberately removed, but more so was removed/postponed from an effort & timeliness perspective

just adding this link for some historical context http://drupal.org/node/926664

How about just OAuth without OpenID?

Other websites would use OAuth + a Drupal.org REST API to figure out who you are on Drupal.org, similar to Twitter, Google, etc, are doing with app developers.

Marking "won't fix" as per greggles' comments above.

We distribute software and provide services for development of that software, but that's IMO it.

@killes I guess you mean #83? I didn't lay out any reasons really. I just think that :

1. after this many years nobody has had the motivation to make this feature happen
2. it will require some improved security practices that will take a fair bit of effort both one-time and ongoing

Seems like a won't fix situation. I'd be very open to reopening this issue at some point if someone with experience running an identity provider can provide leadership to get it done.