[drupal-devel] remote auth and required email/password fields

Gerhard Killesreiter killesreiter at physik.uni-freiburg.de
Wed Mar 16 08:11:58 UTC 2005

On Wed, 16 Mar 2005, Mark wrote:

> I've been working on the livejournal authentication module, and I've
> noticed some odd things in the process.  Most of this would apply to
> any remote auth configuration.

Note that the Drupal remote auth mechanism should be reworked. It is
pretty insecure.

> When a user joins a site using
> remote authentication, their email address and password are not
> collected when the account is created.  When such a user edits their
> profile information, though, they are forced to enter an email
> address, and password fields are presented to them.  I'm wondering
> what the consequences would be if the email address were no longer
> required for these users.

Several modules assume that there is an email address for each user.
One could argue that it is the module author's fault to not take remote
auth into consideration.

> Additionally, it doesn't make sense for them to enter a password
> since they are authenticated using a remote server.


> I can see one problem arising from the profile edit page's current
> design.  What happens when a user changes their name from
> "user at authserver" to be just plain "user" (or vice/versa)?
> Will that same account no longer be authenticated against the remote
> server?


> If I require that any username that they choose have a remote
> authentication server, would there be problems with this?

I dob't get what you want to do.

> What happens to normal, locally authenticated users who change their
> username from "someuser" to "someuser at someotherauthserver"?

Not much, local auth is always used as backup.

> How would they ever get logged back in if they changed their
> username to, say, their email address? (I'm sure this has happened
> before)

See above.

> Some ideas to consider:
> Many auth servers provide full name, email address, etc., but
> there's currently no way of attriibuting these values to a local
> account.  What about changing the hook_auth mechanism so that
> profile data collected at the time of signup can be applied to a new
> user's account.

This has been discussed in the "social software" session at the code
sprint. The problem is to establish a connection of the remote server's
fields to local Drupal fields (for example: we use "name" for the
Drupal name, another software could think that is the given name).

> Consider altering the profile edit page so that if username contains
> the '@' character (i.e. remotely authenticated),

This is not neccessary true, see above.

> then email address is no longer required and local password fields
> don't appear.

Could be done. "@" should then be forbidden as a name component for
other accounts.

> This sounds oversimplified, but I cannot see any reason that these
> fields would be required/needed for remotely authenticated users.
> The password field would be especially confusing, since the new
> password is typically not applied to the authentication server
> (though I suppose it could be on some servers via hook_user).


This is actually the insecure part of the whole Drupal remote auth
process: You give your password to a foreign site.

> Any thoughts on this?  Your ideas would be greatly appreciated.

An idea (proposed by somebody else) for secure remote auth would be to
let the user authenticate at the "home server" and only send a "yes" or
"no" to the remote server. The remote server would pass the session ID
along and get it back if authentication was succesfull. I am not
completely sure, if this process is safe from exploits, though.

Ideally, the whole process should be encrypted.

In general, the whole remote authentication process is not of much value
(at least to me) as long as there is no way to have a closed set of
sites that can build a trusted network. I also rather create a new
account because firefix remembers my passwords for me and the remote
auth process has thus not much benefit for me. ;)


More information about the drupal-devel mailing list