Note: If you never used an "@drupal.org" login to a site then you can gleefully ignore this post. It was a feature launched long ago and not widely used.

Hey Everybody,

It's been a long time coming, but we are now approaching the point where the old "distributed authentication" mechanism will be turned off on drupal.org.

For a while, the distributed authentication method was a great idea. Sites like spreadfirefox.com used the distributed authentication and it helped spread awareness of Drupal. It was an early idea for identity and federated websites and distributed social and all those fancy buzzwords.

But while the concept might have been visionary the implementation was not. It is not a super secure architecture, as perhaps the biggest complaint.

So, we will turn it off on drupal.org on November 1st, 2010.

Goodbye legacy, hello new hotness

If your site allows logins like "username@drupal.org" then you should know that it will be turned off soon. Users will still be able to login with that account and the password they last used. But there could be some scenarios where they get locked out. Even worse, if they never updated their account then their mail will not be stored in your database so they cannot use the "self-service" password retrieval system.

If you want to use something similar, consider using OpenID module that's in Drupal core these days. It allows federated logins without all the architectural security problems.

If you relied on this service

Site owners who relied on this service should...

  1. Get people to enter their e-mail on their profiles
  2. Alert people that the connection to drupal.org is going away and their passwords will no longer stay in synch.

Yay progress!

Comments

christefano’s picture

Are there any stats for how much Distributed Authentication is used on Drupal.org?



Christefano  
Founder, CEO
Large Robot
954-247-4786
http://www.largerobot.com
JohnForsythe’s picture

According to the issue below, about 9000/requests a day, most of them from Drupal.ru.

NaX’s picture

Is Drupal.org moving to OpenID or something else. It just seems a little strange to remove a feature without replacing it with something else/better/new.

Is their a reason for turning it off, is the primary reason only security, is their maybe a a discussion or issue we can reference to see more detail on how Drupal.org came to this decision.

PS. I use it and will miss the feature.

christefano’s picture

Drupal.org and the *.drupal.org sites are using the Bakery module:

Bakery provides a "single sign on" feature for Drupal based sites that are on the same second-level domain (i.e. example.com, subsite.example.com, subsite2.example.com). It could also provide support for any other website that implements the same web cookie, xmlrpc, and POST methods.

As far as I know, Bakery is the only reason that DrupalCon sites are now on *.drupal.org instead of *.drupalcon.org (since chicago2011.drupal.org, for example, can use the same cookie as drupal.org and drupalcon.org cannot).



Christefano  
Founder, CEO
Large Robot
954-247-4786
http://www.largerobot.com
Gábor Hojtsy’s picture

Bakery is not a replacement for non drupal.org sites, it only works for sites on the same main domain. Drupal.org does not currently have plans for a replacement service, so that you could use your drupal.org identity elsewhere.

Phasing out this distributed authentication mechanism was discussed in #375899: Phase out support for Drupal distributed authentication, #558038: Switch off site network module and finally #926544: Disable site_network (legacy Drupal authentication) November 1 and post the news on the front page. Possibly putting an OpenID Provider in place, so you can use your drupal.org identity as an OpenID was discussed in the past 2 years and won't fixed in the summer at #353425: Allow other sites to use drupal.org user identities for login (in D7 infrastructure, without shared secrets), that is probably the best issue to discuss this further.

Rainy Day’s picture

Thanks for the heads-up on Bakery. Looks useful.

Never liked the Distributed Authentication module. It always seemed insecure to me, so stayed away from it.

fago’s picture

It would be very nice to have drupal.org as openid provider as this would be useful for lots of drupal related sites, like all the drupalcamps.

greggles’s picture

Drupal.org is not (yet) moving to be an OpenID provider nor client (relying party). There are issues about that posted by Gabor that detail why/why not.

Ultimately the reasoning here is something like: the architecture of service is not secure, allowing people to keep using it encourages insecure behavior, there are better alternatives, we should promote those alternatives and disable this service.

chipway’s picture

Was very useful for me.

Will try some other solution.

Drupal Consultancy, Development & Training, Lyon, Paris, France, Suisse. https://chipway.com.

redpuma’s picture

Three weeks notice isn't long for site owners to find out and react to this. I wonder if the first some site owners know about this is when the service stops?

Taxoman’s picture

Although I have not used this feature myself, I think people should have had several months notice of such changes. What if an admin happens to have taken a month holiday last week - and on the other end of this - what with that admins users that also could have gone on holiday for a month or two, and therefore would not be able to adjust their email address in time? It would have shown the Drupal community's respect to anyones situation if given a longer deadline. Think of it as contributing to strengthening our reputation.

greggles’s picture

This was originally posted September 29 in response to an issue in the infrastructure queue: #926544: Disable site_network (legacy Drupal authentication) November 1 and post the news on the front page. As you can see in that issue, there's been a bit of research and consideration.

In general, this service has been headed toward shutdown for several years. There hasn't been a front page announcement about it, but in various posts (See Gabor's links above) it has been discussed.

It's never a good time to stop offering a service that people rely on, but at some point it has to be done.

Gábor Hojtsy’s picture

Well, if an admin goes on holiday for a month, they better appoint someone in their place. There are at least four Wednesdays in that timeframe when security releases of Drupal core or contributed modules might come out, leaving the site vulnerable if not acted on.

Taxoman’s picture

Well, I assume that we care about small sites administered by only one person as much as for big operations?
My impression is that most of the Drupal sites are in fact small, but they can still be important for the admin, he or she can still have several users and sites to cater for. Even if they have delegated some monitoring tasks etc. to another person while away, I imagine that this situation typically calls for the main admin to make the considerations and decisions, and take some actions.

I just think that it would be a sign of good will to give people 2-3 months or so to handle this.

greggles’s picture

We also proactively mailed sites that make heavy use of this service.

If we made it 2-3 months someone would feel that wasn't long enough. The standard for notification on drupal.org is 2 weeks, that's how abandoned projects work, for example.

So, by some measures the 4 weeks is a long time to give notice.

If you want to get involved and help those small sites let me know. One task is just advertising this more broadly, like on twitter. Another would be to contact sites using the module. You can do that by searching for strings found in the module like this one or this one.

C-Logemann’s picture

Hello everybody,
every user who can use this feature on other drupal-sites is also a user of drupal.org. If there is a technical way to find out which d.o-users have ever used this feature we can only contact these users. If not we can ask every user of drupal.org. With this massmailing we can tell everybody to set their email on these drupal-websites. And we can ask them to tell their drupal-admins about this changing on drupal.org.

This is a service for many websites out there. To many website admins and normal users are affected.
Each of them could be angry of this drupal way.
Even the site_network.module is still available.
I suggest to hold this service a little bit longer and do more information work.

kind regards
Carsten Logemann

--
There is a module for that!
My company: Nodegard GmbH

greggles’s picture

There is not a way to find who the users are who use this module as far as I know.

The site_network.module is still available because it's possible to make it use any website (not just drupal.org) as the hub of the logins.

I appreciate your suggestion, but can you do that work? If not, it's unlikely to happen.

C-Logemann’s picture

Hello Greg,
I am not involved in d.o-organisation so I can't decide and do massmailing to d.o-users by myself. If not already in action a module like mass_contact can create an email like this. I think the subject and body of this/your node can be reused.
So we only have to find out who can decide and organize this massmailing to all d.o-users.

kind regards
Carsten Logemann

Update: I have created an issue ( #944700: Selectively mail the people who use distributed authentication) for d.o-webmasters
Update2: I have informed the german community: News on drupalcenter.de

--
There is a module for that!
My company: Nodegard GmbH

C-Logemann’s picture

In the logic of identity management of drupal.org the personal contact form could be used.
An affected user can switch on this form on d.o only for a while if he/she wants. Then the admin of the affected drupal sites can send him/her login-information on this way if she/he is asking for.
This could be a lot of admin work on drupal sites where this feature is in heavy use. But the admins of such websites are already identified and contacted as I understand.

This solution should be easy to find on d.o and any affected drupal site. If there is or would be any way to automatically inform affected users on failed login this would be great.

--
There is a module for that!
My company: Nodegard GmbH

Anodonta’s picture

Such authorization as @drupal.org is only suitable for groups of sites contained in a single "Internet conglomerate" specific company (such as authorization from Microsoft, Adobe, etc.), but not for separate sites of different owners.

greggles’s picture

It's worth noting that after all the concern in this thread there wasn't a single complaint to the drupal.org infrastructure queue, contact tab, webmaster queue, etc. when the deed was actually done.