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

Search Results: 3 of 27 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: __.. \ /.__ __. (__ \| >< [__)(__ .__)\|___/ \\| \.__)
Comment	> 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?
Attachment
Watch this ticket

Saved Queries