[development] Generic Authentication Bridging

[Chris Johnson]

No, actually I was just thinking of possibly making small modifications to 
core to allow site admin-selectable encryption or hashing algorithms for the 
password, i.e. sort of a hook_hash() call.  Other flexibility can all be added 
via a module, such as yours.  Core just seems like the right place that kind 
of thing, but it could be added to sql_auth easily enough, I guess.

In general, I am thinking about what kind of core changes are needed to 
support -- but not implement -- modular authentication schemes that 
single-signon and enterprise-wide usage might need.  Maybe it will turn out 
that there are no core changes needed at all (though I do think user.module 
really needs refactoring), and everything can be done via modules, sql_auth 
among them.

I'm just looking at the big picture because I'm interested in fitting Drupal 
into the enterprise environment, and because someone else brought this topic 
up and volunteered to do some work on it.

..chrisxj

Bèr Kessels wrote:
> Are you talking about making sqlauth a core module? I hope not. It is fien 
> where it is. It does what you describe below, just fine. In case you find any 
> missing (but badly needed) features, the module is open for suggestions and 
> improvement. 

> Op zaterdag 15 april 2006 18:07, schreef Chris Johnson:
>> 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?
>>
>> ..chrisxj
>