Using distributed authentication

Note:

Drupal 6 installations should use the site network module : http://drupal.org/project/site_network

Distributed authentication

One of most dreaded obstacles users are confronted with these days is the need to continually create new accounts for themselves at every website they come across. Logging into a website to check out it's features should be a fun process, not a chore. Forcing each visiting user to create a new account by filling out your carefully crafted registration form is tedious, boring, and repulsive. Luckily for Drupal users, there's a built in system that removes a lot of this drudgery. It's called Distributed Authentication, and it's built into the core.

For example, on groups.drupal.org, you do not have to fill out a registration form if you are already a member of drupal.org. This capability is fantastic for getting users to instantaneously interact with your site if they happen to already be a member of a sister site.

Enabling the feature

To enable this feature, turn on the 'drupal' module at Administer > Site Building > Modules (D5), and configure it at Administer > Site Configuration > Distributed authentication.

The Settings

Authentication service: Enabled
Default authentication server: (the URL of the master authentication server)
Only allow authentication from default server: Enabled

How it works

Drupal knows how to communicate with external registration databases. For example, lets say that new user \'Joe\' is already a registered member of Delphi Forums. Drupal informs Joe on registration and login screens that he may login with his Delphi ID instead of registering with this site. Joe likes that idea, and logs in with a username of joe@remote.delphiforums.com and his usual Delphi password. Drupal then contacts the remote.delphiforums.com server behind the scenes (usually using XML-RPC, HTTP POST, or SOAP service) and asks: "Is the password for user Joe correct?". If Delphi replies yes, then the originating site creates a new account for Joe and log him into it.

When the username Joe doesn't exist locally but it does exist on the remote system, and the correct remote username/password is provided by Joe, Drupal lets Joe in and creates the username 'joe' locally, assigning default roles to him. He can then go and change his profile, even change the local password - both remote and local passwords will still work.

There's a surprise when the username already exists locally - it lets the user in with a remote password and impersonates the existing user - so make sure that when you select "Only allow authentication from default server" you trust your default server.

Note: Distributed authentication fails when your users...

This module will not work correctly when your users have used an email address as their username (which is permitted by Drupal). Suppose a user registers his username as joe@joeserver.com on a Drupal instance at drupalserver.com
When he tries to do a remote login, then his username is treated as "joe", and "joeserver.com" is treated as the server part of his DrupalID. Technically though, his username is joe@joeserver.com and his DrupalID should be joe@joeserver.com@drupalserver.com.

Logging in remotely will fail, because the drupal instance at joeserver.com will try to find a username joe, instead of joe@joeserver.com.

Solutions:

Restrict the username from containting anything other than [a-zA-Z0-9].
Comment out the code that stripped the @domain portion of the login. I.e. hacking core, a very bad idea!