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

Christian Bayle gforge at free.fr
Tue Feb 8 22:57:35 CET 2011


Le 08/02/2011 14:46, Olivier Berger a écrit :
> Le lundi 07 février 2011 à 15:59 +0100, Christian Bayle a écrit :
>   
>> Le 03/02/2011 22:36, Manuel Vacelet a écrit :
>>     
>>> 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's why I suggested to inspire from PAM model that manage this kind 
>> of cascading.
>>
>>     
>
> That looks nice but I fear reinventing some wheel may be overkill
> here...
>
> I mean, getting inspired by a working system like PAM is fine... but
> implementing a whole new PHP engine for this... hmmm. Ain't there any
> PHP libs to reuse that lead us closer to the goal ?
>
>   
>> I see several eprouved model to check with
>>
>> -PAM
>> -SASL
>> -SAML
>> -Shiro
>>
>>     
> Anything in PHP ? How are the folks at Drupal or other big/modern web
> apps do ?
>
>
>   
I've seen many but I couldn't extract anything in common , all webapp
seems to redo his own
-Mediawiki is plugin based, logic as mediawiki is mostly a plugin engine
-Mailman is creating as many cookie as possibilities to log
-I don't know about Drupal, but would like to know
-GLPI has an instersting way to deal on both ldap and deal with apache auth
-Shiro (http://shiro.apache.org/) has the ambition to provide simple
api, available for all language and may be interesting at least for api
naming (See http://shiro.apache.org/10-minute-tutorial.html)

I was talking about model, not implementation
How pam is chaining, take in account fallback, allow local auth is in
itself interesting
I recommend the read of

man pam.conf

It may not be the best model, but for exemple you wonder about cascading
auth, it defines

required/requisite/sufficient/optional which I think is at least
interesting to have in mind.

All this has also to be able to work based on php implementation as much
as external auth,
but external auth is quite simple subcase in php

>> pestered by Olivier, or reuse system based goodies
>> (e.g. oauth can be either based on php code or on apache module)
>>
>>     
> Ah, yes.
>
> Zend_Auth may be a first good candidate, and otherwise, there's still
> SimpleSAMLPhp, but it's a beautiful gas engine... so, I'm not sure (the
> initial investigations we lead on it weren't so much conclusive, at
> least for normal humans).
>
> My 2 cents again.
>
>   
Except zend, there don't seem any common implementation, but even with zend
you can for example reimplement the way you generate a session cookie. 

Cheers

Christian




More information about the Fusionforge-general mailing list