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.
Right.
I can see one problem arising from the profile edit page's current design. What happens when a user changes their name from "user@authserver" to be just plain "user" (or vice/versa)? Will that same account no longer be authenticated against the remote server?
Right.
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@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).
Right. 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. ;) Cheers, Gerhard