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

[Moshe Weitzman]

>> 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?
>
> 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 at 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.