[Tickets #10980] Re: Create the possibility of two alternative authentication modules

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10980
------------------------------------------------------------------------------
  Ticket             | 10980
  Updated By         | c.denis at mrduck.fr
  Summary            | Create the possibility of two alternative
                     | authentication modules
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


c.denis at mrduck.fr (2012-02-13 10:26) wrote:

The idea to allow an arbitrary number of authentication modules (in an  
array for example) appeals to me:
$conf['auth']['driver'] = 'multiple_auth';
$conf['auth']['params']['subriver'] = array('module1' , 'module2' ,  
'module3', ... )
But I see a Problem to nicely define the parameters to the subsequent  
modules, which would need to look something like the following  
incredibly long and complex line (nothing like the usual config style):
$conf['auth']['params']['subriver-conf'] = array('module1' =>  
array('table' => horde_users', 'username_field' => 'user',... ),  
'module2' => array(), 'module3' => array());
Something like this can be realised by using this module multiple  
times and adding one authentication module per layer.

> But this would be a very simple looping idea: the  
> 'single_validation' config could not be a part of this.
I do not need this single_validation and added it in the hope to make  
it more general :) If there was to be a driver to choose from multiple  
authentication modules, one might as well want to validate the login  
in the local password cache, but get it confirmed by a befriended  
organisation. (external co-worker, who quits the organisation which  
dispatched him to my organisation, would see his account revoked or  
blocked)

The one-time-password module I am working on, will only be published  
here soon. Though it would be possible to force users to always use a  
single-use password, I picture the use-case, where I have the  
permanent password saved in my browser on a trusted machine at home  
and only use the otp scheme when I am at an airport terminal. Using  
such an 'alternative' module would allow to use either authentication  
module without modifying the flow of the login mechanism.

> (not to mention that this driver is lacking all details on how the  
> admin auth methods would work)
This is because there already is a module providing this  
functionality: composite
My previous configuration example illustrates how these two modules  
would be combined to provide for admin methods and additionally allow  
multiple authentication modules.

I concede this could as well be implemented as an extention of the  
existing composite module. Would that seem more useful to you?