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

[Mark]

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 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()
>
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 at 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 at drupal.org'.  If a 
user attempted to register using 'weitzman at 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