Last updated August 9, 2011.
Single sign-on has been implemented with Bakery.
Issues tagged with "drupal.org identity" cover this topic. This page lists the planned initial steps to set up single sign-on among *.drupal.org sites putting those issues into context.
- Only accept user registration on the main identity site. Either run the OpenID Provider module or an OpenID server we can run and feed with user data. This should be the only site accepting new user registration on *.drupal.org. #353425: Use drupal.org user identities as OpenID logins
- On each of the other sites (drupal.org groups.drupal.org, association.drupal.org, etc.), activate the core openid module, and set it up to only accept drupal.org OpenIDs. Disable all other ways to sign-up. #375894: Allow OpenID logins on drupal.org
- We should phase out the Drupal distributed authentication support. The upgraded site will run site_network module, but we might get rid of it by either not giving anything in its place or by providing the OpenID identity to be used elsewhere as well: #375899: Phase out support for Drupal distributed authentication
- Connect existing users to their master user and migrate people who do not have master users to have one. #372033: Relate the subsite users to the master identity users
- Implement profile field sharing, so that people can use their profile fields on multiple subsites. Disable editing of shared fields on the subsites, but possibly allow for subsite specific profile data. #372021: Implement shared user profiles
- Some subsites, like infrastructure or security might not want user accounts being autogenerated by people logged in on the master site and stumbling on the subsite, so implement ways to limit people to not be able to autojoin such sites when they lack privileges. #372026: Implement single-sign-on blockers for users