[development] Generic Authentication Bridging
chris at tinpixel.com
Sat Apr 15 16:07:29 UTC 2006
Gary (Lists) wrote:
> b) I really need a way to (easily) bridge user authentication
> between Drupal `userid` and several other SQL db's user entries
> Project: Generic User Authentication Look-up Bridge Framework
> Project Description:
> I wish to create a basic, super-admin-only set of PHP functions to
> bridge the Drupal user's table to (any) other SQL table.
> The Drupal `userid` will be looked up in any of the named DB's and will
> considered valid if both `userid` and `password` are the same in both
> Functionality would be modular, allowing the addition of
> application-specific bridges for common OSS user-based tools
> (i.e., pMachine, Olate Download, etc.)
> Project Hopes:
> 1) Simple, flexible design.
> 2) Drop-In Install, Single-Page Management.
> 3) Eventual addition of 'Authenticate and Migrate User' functionality.
I was just thinking about the need for things similar to this for
enterprise-wide use of Drupal, and for making life easier for my extranet
users at my employer, where I am busily converting our existing web
applications to Drupal.
Here's one part of what I think needs to happen. Note that Drupal already has
some capabilities for various kinds of plug-in authentication. But the
ability to use other SQL databases and their user entries is a missing and
I could easily hack the user.module to do what I need. But I don't want to
have to re-port my changes every release of Drupal. What needs to happen is
user.module be modified to accept a plug-in user authentication method, which
can be locally customized, just like sites/defaults/settings.php allows for
various other pieces of Drupal. Perhaps that is even the correct place do fit
this scheme in.
In my case, I have a table of existing usernames and passwords. I would just
import them all into drupal.users except for one major problem: Drupal uses
md5() password hashing and my existing table uses crypt(md5) hashing. That's
right -- they both use the md5 algorithm, but the resulting strings are vastly
different, and as far as we can tell, there's no way to translate them.
At the moment I'm thinking that the user_load(), user_save() and
user_pass_rehash() functions be re-written so as to call a configurable
hashing algorithm. That would allow me to change the algorithm in my
installation from md5() to crypt().
More generally, changes should also occur to allow authenticating the user
against a configurable table. This would require slightly more extensive
changes in user_load() and user_save(), but should still be straight-forward.
Gary, how does this fit with what you are planning?
More information about the development