[drupal-devel] remote auth and required email/password fields
Greetings, 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. 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. 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@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? What happens to normal, locally authenticated users who change their username from "someuser" to "someuser@someotherauthserver"? 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) 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. Consider altering the profile edit page so that if username contains the '@' character (i.e. remotely authenticated), then email address is no longer required and local password fields don't appear. 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). Any thoughts on this? Your ideas would be greatly appreciated. -Mark
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
On Wed, 16 Mar 2005, Karoly Negyesi wrote:
account because firefix remembers my passwords for me and the remote auth process has thus not much benefit for me. ;)
So says the only core contributor who has a drupal.org username with @www.drop.org in it :)
Well, I had once created that account to test out the remote auth mechanism. Some time later I had forgotten my password and got myself a new one from drupal.org (not drop.org). Since then the "@www.drop.org" part is not really needed, but I kept it nevertheless. Since about one year ago, I am using browsers with password managers and really see no use for the remote auth mechanism as it is now. The only advantage would be that I don't have to wait for the password email. Cheers, Gerhard
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. It is not safe for a 'man in the middle' exploits. If somebody manages to pretend to be the 'home server', the they rule.
It is possible though, to devise a scheme which can avoid that, something along the lines: prerequisite - some form of trust established between remote and home, preferably some form of signing the messages. --------------- user: remote, I want to login, I'm a foreign user my home site is xxx remote: user, OK, then, I know of them, redirect to http://xxx/remote/login/url user: home, it's me and my password is .... home: user, wait a bit home: remote, user is fine [message signature] home: user, redirect to remote/whatever user: remote, show me whatever ---------------- A conversation like that is feasible, but is less flexible than the current remote auth. Every software must support such a redirection, login exchange scheme. Redirection is good, since it will help to reduce the user clicks. Between Drupal sites though it could be done. This conversation roughly mimicks the conversations your web browser make with key servers, to verify a certificate, so in spirit at least it should be fine. Vlado
On Wed, 16 Mar 2005, Vladimir Zlatanov wrote:
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.
It is not safe for a 'man in the middle' exploits. If somebody manages to pretend to be the 'home server', the they rule.
Yeah, I guess.
It is possible though, to devise a scheme which can avoid that, something along the lines:
prerequisite - some form of trust established between remote and home, preferably some form of signing the messages.
I was actually thinking to use gpg keys to do the encryption I spoke about. "Unfortunately" all the sites I would want to have in a trusted network will run on the same server and so I will simply share the user table. So I will not code this. Cheers, Gerhard
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.
Wrong. The authmap table maps the remote username to local uid. Look at the source in user_login()
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"?
you can't put an @ in your username unless you register via remote auth
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)
again, we don't allow this.
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.
we already have this capability in foaf.module. That module takes advantage of hook_user('login'). Once you see that module, and read up on user.module, I think many of your doubts will be answered. You can use hook_user('login') too with these auth servers if they don't use foaf.
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).
again, see foaf module. it does this mapping
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.
see http://alec.bohemiandrive.com/perm/2005/02/18/distributed- authentication for the vision of where we intend to go with this. noone has volunteered to code it yet.
Ideally, the whole process should be encrypted.
not necessary.
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.
yes there is. you can use sso.module if you have a central authoritative drupal site for identity. or if all sites share a database server, you can use a solution as described at http://lists.drupal.org/archives/drupal-devel/2004-07/msg00737.html. but even if you just have a bunch of independant trusted sites, you may employ username validation rules to shut out untrusted servers.
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. ;)
this is strange logic (especially for a scientist). firefox will remember passwords whether they are local or remote. it is just a textbox as far as it knows.
On Wed, 16 Mar 2005, Moshe Weitzman wrote:
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.
Wrong. The authmap table maps the remote username to local uid. Look at the source in user_login()
Right, I was wrong. The code is in user_authenticate.
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"?
you can't put an @ in your username unless you register via remote auth
user_validate_name would not complain. Just tested it locally, works fine.
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)
again, we don't allow this.
Apparently we do.
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.
we already have this capability in foaf.module. That module takes advantage of hook_user('login'). Once you see that module, and read up on user.module, I think many of your doubts will be answered. You can use hook_user('login') too with these auth servers if they don't use foaf.
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).
again, see foaf module. it does this mapping
Right, was that mentioned at the meeting?
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.
see http://alec.bohemiandrive.com/perm/2005/02/18/distributed-
Yeah, that was the link.
authentication for the vision of where we intend to go with this. noone has volunteered to code it yet.
That's the problem with all the nice ideas.
Ideally, the whole process should be encrypted.
not necessary.
That is why I wrote "ideally". ;)
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.
yes there is. you can use sso.module if you have a central
Will have a look (the module isn't available in head).
authoritative drupal site for identity. or if all sites share a database server, you can use a solution as described at http://lists.drupal.org/archives/drupal-devel/2004-07/msg00737.html.
Will read that up.
but even if you just have a bunch of independant trusted sites, you may employ username validation rules to shut out untrusted servers.
Ah, yes, I had forgotten that. Maybe we should write a book page about that.
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. ;)
this is strange logic (especially for a scientist). firefox will remember passwords whether they are local or remote. it is just a textbox as far as it knows.
Well, to do remote registration, I'd need to remember my drupal.org password. Since ff does that for me, I don't bother to do that. I can't find a flaw with that logic. :o) (Yes, I could look the pw up in the password tab, but just registering anew is faster for me). Cheers, Gerhard
Sorry for the delayed response, but thank you all for your comments. Moshe Weitzman wrote:
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.
Wrong. The authmap table maps the remote username to local uid. Look at the source in user_login()
Ok, after a little code browsing and some empirical study, I've seen that neither of these scenarios is a problem.
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"?
you can't put an @ in your username unless you register via remote auth
Yes you can, but it doesn't confuse the auth system. You can, however, keep a user authenticated through a remote site from registering with your site using remote auth. For instance, I could register as a local user 'javanaut', then change my username to 'weitzman@drupal.org'. If a user attempted to register using 'weitzman@drupal.org', the name would already be taken. Not a huge problem, but perhaps something 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.
we already have this capability in foaf.module. That module takes advantage of hook_user('login'). Once you see that module, and read up on user.module, I think many of your doubts will be answered. You can use hook_user('login') too with these auth servers if they don't use foaf.
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).
again, see foaf module. it does this mapping
I'll look at this module. For my current purposes, livejournal does offer foaf data for its users.
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.
see http://alec.bohemiandrive.com/perm/2005/02/18/distributed- authentication for the vision of where we intend to go with this. noone has volunteered to code it yet.
Excellent read. The only concerns I would have would be with sites that aren't located at or have access to the root of a domain (like http://example.com/~user/drupal/). His suggestion was to make doc root level assumptions about the location of various config files and to use SSL for server-to-server communication, which might not be available everywhere. I would think the encryption method/communication channel should be configurable and allow for minimum-security arrangements (assuming all site admins supported this). This article definitely deserves its own thread, and from the looks of it, I missed out on that thread already :(
Ideally, the whole process should be encrypted.
not necessary.
As mentioned above, I would think that some commonly available encryption scheme could be used. Perhaps a public key system? I would want to accommodate the lowest common drupal denominator with a very basic hosting package.
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.
yes there is. you can use sso.module if you have a central authoritative drupal site for identity. or if all sites share a database server, you can use a solution as described at http://lists.drupal.org/archives/drupal-devel/2004-07/msg00737.html. but even if you just have a bunch of independant trusted sites, you may employ username validation rules to shut out untrusted servers.
I'll have to look into this module. I'm currently dreading the thought of using the ldap module to talk to an active directory server for various intranet sites :(
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. ;)
What happens when your desktop gets stolen? ;)
Thank you for your comments. One question, though, I didn't see any conversations here or on drupal.org regarding the revised distributed auth conversation. Was there one? Thanks, -Mark
see http://alec.bohemiandrive.com/perm/2005/02/18/distributed- authentication for the vision of where we intend to go with this. noone has volunteered to code it yet.
Excellent read. The only concerns I would have would be with sites that aren't located at or have access to the root of a domain (like http://example.com/~user/drupal/). His suggestion was to make doc root level assumptions about the location of various config files and to use SSL for server-to-server communication, which might not be available everywhere. I would think the encryption method/communication channel should be configurable and allow for minimum-security arrangements (assuming all site admins supported this). This article definitely deserves its own thread, and from the looks of it, I missed out on that thread already :(
we really didn't discuss it much. AdrianR and I described it over beers and Dries nodded in approval. Perhaps you will start a thread on drupal.org about it. You bring up a couple legit issues. Perhaps we can have a fallback mechanism where we try https and if that fails, we use plain http ... i think the path thing is a non issue since all drupal requests go to index.php. i see no problem with sites in subdirectories, just like today.
I'll have to look into this module. I'm currently dreading the thought of using the ldap module to talk to an active directory server for various intranet sites :(
yeah, thats usually overkill. see webserver_auth.module as well. it is very simple, yet powerful. it runs on my company's intranet.
Karoly Negyesi wrote:
have a fallback mechanism where we try https and if that fails, we use
When I have tried introducing HTTPS into Drupal, it was said that something named phplib is the solution not https. May or may not be relevant in this discussion.
Not sure what the context was, but AFAIK, phplib is just a library of PHP classes and functions. I didn't see anything about SSL or HTTPS on their website. http://www.sanisoft.com/phplib/manual/intro.php#intro.whatis.phplib
Karoly Negyesi wrote:
have a fallback mechanism where we try https and if that fails, we use
When I have tried introducing HTTPS into Drupal, it was said that something named phplib is the solution not https. May or may not be relevant in this discussion.
I would say that PHPLIB's technique[1] for avoiding sending auth information in clear text is a good solution for those who can't afford to go the HTTPS route. Adding SSL code to Drupal's remote or local auth would be a black hole for resources. Local auth HTTPS should remain at the server. If an admin is running a site where security is that important, his or her server ought to be running HTTPS, and most browsers out there support it directly. That does not solve the remote auth problem, however. But HTTPS seems more work than it is worth at this point. [1] client side: crlogin.ihtml: http://tinyurl.com/6ysow server side: local.inc, Example_Challenge_Auth(): http://tinyurl.com/3wvyo -- Chris Johnson
Moshe Weitzman wrote:
see http://alec.bohemiandrive.com/perm/2005/02/18/distributed- authentication for the vision of where we intend to go with this. noone has volunteered to code it yet.
Excellent read. The only concerns I would have would be with sites that aren't located at or have access to the root of a domain (like http://example.com/~user/drupal/). His suggestion was to make doc root level assumptions about the location of various config files and to use SSL for server-to-server communication, which might not be available everywhere. I would think the encryption method/communication channel should be configurable and allow for minimum-security arrangements (assuming all site admins supported this). This article definitely deserves its own thread, and from the looks of it, I missed out on that thread already :(
we really didn't discuss it much. AdrianR and I described it over beers and Dries nodded in approval. Perhaps you will start a thread on drupal.org about it. You bring up a couple legit issues. Perhaps we can have a fallback mechanism where we try https and if that fails, we use plain http ... i think the path thing is a non issue since all drupal requests go to index.php. i see no problem with sites in subdirectories, just like today.
The concern that I had was that there was no mention of allowing "username"@"example.com:8080/~user/drupal/" to be a valid username. It seemed like "username"@"example.com" was the only format that would work. Specifying the port may be outside of the normal scope, but definitely rooting the drupal install in a subdir is very common.
I'll have to look into this module. I'm currently dreading the thought of using the ldap module to talk to an active directory server for various intranet sites :(
yeah, thats usually overkill. see webserver_auth.module as well. it is very simple, yet powerful. it runs on my company's intranet.
Thanks!
Perhaps you will start a thread on drupal.org about it.
Here it is: http://drupal.org/node/19113 -Mark
participants (7)
-
Chris Johnson -
Gerhard Killesreiter -
Karoly Negyesi -
Mark -
Mark Howell
-
Moshe Weitzman -
Vladimir Zlatanov