[Fusionforge-general] [RFC] Revamping the pluggable authentication mechanisms

Christian Bayle gforge at free.fr
Tue Feb 8 23:08:35 CET 2011


Le 08/02/2011 22:22, Alain Peyrat a écrit :

> There is one case I would like to keep if possible.
>
> In the current implementation, when an auth plugin is not able to
> answer, for example, if the ldap server is down, the current LDAP plugin
> will let the regular database auth code do the job and then, the system
> will use normal database login. Even with a load balanced LDAP server,
> this has proven to be very valuable.
>
> Current code is performing a logical AND, to allow only if all auth
> components are ok.
>
> Alain.
>
>   
I think this can be done by adding hook priorities
and deal with hook return code, and notion like
required/requisite/sufficient/optional

Christian

> Le 08/02/2011 21:56, Manuel Vacelet a écrit :
>   
>> I try to answer/react/propose in one message:
>>
>> I much like the "authoritative" approach, it's what is in use in
>> apache and so far it works. If we set enough constraint (only one
>> authoritative for instance) it might be manageable without plugin's
>> priorities. Otherwise, I would fear inconsistent results.
>>
>> I share the view of Olivier: PAM/Sasl & co are proved system but I
>> would prefer to rely on PHP proved systems. I don't know Zend_Auth but
>> it might address some of the issue we face and even if it doesn't, we
>> can contribute.
>>
>> For the factories stuff, I was mabye not clear enough but I was
>> thinking to a model where the Core would have, for instance a
>> AuthFactory and Auth (default FF auth model) and the plugins would
>> inherits from Auth (or implement an interface). The hook magic would
>> be in AuthFactory and would deal with priorities, authoritative and
>> all issues while the consumer (for instance the login page) would only
>> care to interact with a Auth object (either it's CoreAuth, LdapAuth,
>> OIDAuth, ...).
>>
>> Manuel
>>
>> On Fri, Feb 4, 2011 at 1:55 PM, Roland Mas <lolando at debian.org> wrote:
>>     
>>> Manuel Vacelet, 2011-02-03 22:36:35 +0100 :
>>>
>>>       
>>>> Hi all,
>>>>
>>>> It's a very interesting thread/work you start !
>>>>
>>>> After a first read I have one question and one suggestion:
>>>> * Question: how do you intend to manage (for each step/hook) several
>>>> plugins that might answer ?
>>>> For instance I have 2 identification plugins running: ldap & CAS + FF
>>>> default (for admin accounts for instance).
>>>> How to manage that ldap and CAS might have different answers (one
>>>> allow authentication, one disallow) ?
>>>>         
>>>  That would need to be configurable per-plugin.  A plugin could be
>>> configured to be authoritative when it says yes, or when it says no, or
>>> both (I'm not sure there's a use case for never being authoritative);
>>> and its implementation of the check_auth_info hook would then return
>>> "yes", "no" or "I don't know" accordingly.  Then the local administrator
>>> would have the responsibility to define a sane authentication policy
>>> with no conflicts.
>>>
>>>       
>>>> * Suggestion: for pluggable mecanism like sessions or authentication,
>>>> the usage of Factory pattern would be a great help.
>>>>         
>>>  I think we already use something very much like a factory in the
>>> PluginManager::GetPluginObject() method.  And it's not restricted to
>>> authentication, it applies to all plugins :-)
>>>
>>> Roland.
>>> --
>>> Roland Mas
>>>
>>> C r  ' s  d   a  u    e   e    ll r   a  u i r .
>>>  -- Signatures à collectionner, série n°1, partie 1/3.
>>>
>>> _______________________________________________
>>> Fusionforge-general mailing list
>>> Fusionforge-general at lists.fusionforge.org
>>> http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
>>>
>>>       
>> _______________________________________________
>> Fusionforge-general mailing list
>> Fusionforge-general at lists.fusionforge.org
>> http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
>>
>>     
>
> _______________________________________________
> Fusionforge-general mailing list
> Fusionforge-general at lists.fusionforge.org
> http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
>   




More information about the Fusionforge-general mailing list