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