Yop,
SPIP a une gestion de LDAP en tant que source d'authentification. C'est
une gestion minimale: on peut valider un couple login/password sur un
serveur LDAP, et voilà.
On utilise le processus typique d'auth LDAP :
1. On se connecte en anonyme au serveur pour retrouver le DN
correspondant au login fourni. DN signifie l'identifiant complet de
l'utilisateur au sein de l'annuaire.
2. On essaie de se connecter une seconde fois au LDAP, cette fois pas
en anonyme mais avec le DN précédemment déterminé, et avec comme mot
de passe celui proposé par le visiteur.
3. Si le serveur LDAP accepte la connexion, ça veut dire que le mot de
passe est bon, sinon non.
Tout ça est bel et bon, mais "plus tard" dans la session on aimerait
bien faire d'autres actions (lectures et écritures) sur l'annuaire, et
le tip-top serait de le faire en tant que le visiteur connecté, pour
bénéficier des droits et restrictions qui lui sont associés.
Un exemple simple: changer le mot de passe d'un utilisateur. Il faut
obligatoirement être connecté au serveur LDAP en tant que l'utilisateur
concerné, car lui seul peut changer son propre mot de passe.
Pour se connecter en tant que cet utilisateur, il faut donc connaître
son mot de passe actuel. Or, autant on connaît le mot de passe lors de
la phase d'authentification, autant le reste du temps on ne le connaît
plus. Donc c'est problématique pour se connecter en autre chose
qu'anonyme.
Autre exemple courant: lire des informations du LDAP (au hasard pour
avoir des boucles LDAP) en tant que l'utilisateur connecté à SPIP, et
non pas en tant qu'anonyme. Même problématique.
La seule solution que j'imagine est de stocker le mot de passe en
session après une authentification LDAP réussie, pour le réutiliser
quand c'est nécessaire. Protestation immédiate: niveau sécurité
intuitivement ça ne semble pas top. En vrai, peut-être que ce n'est pas
"si pire".
Qu'en pensez-vous ? Avez-vous d'autres idées ? On pourrait utiliser le
compte "root" du LDAP pour tout, mais ce n'est pas vraiment une
solution.
La question est centrale si l'on souhaite rendre SPIP capable de taper
dans un serveur LDAP de façon "individualisée", pour bénéficier de
toute la gestion de droits, chose qui manque au protocole SQL, et qui
est source de la plupart, voire la presque totalité, des failles de
sécurité. Dans OpenLDAP, Active Directory, etc., on peut choisir
quelles informations chaque utilisateur peut lire/écrire en fonction
de réglages très fins.
PS: J'ai conscience que tout le monde n'est pas familier avec LDAP,
alors j'ai essayé d'expliquer à peu près clairement, mais si des choses
restent floues je peux clarifier un peu plus.
