[drupal-devel] remote auth and required email/password fields
mark at nullcraft.org
Wed Mar 16 23:45:57 UTC 2005
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
> 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
>> (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
> 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?
More information about the drupal-devel