RE: [spip-dev] gestion des users sur un serveur ldap

Ben non ... encore persone à priori. J'ai déjà posé la question 2 fois
et rien ...

Je n'ai pas encore mis mes mains dans ce camboui là ... mais je ne
vais pas tarder ... dès que je sort le nez de mes projets actuels.

En tout cas, cela voudrait dire complétement abstraire la gestion des
utilisateurs ... ce qui n'est pas le cas ... bref, LDAP/SPIP, ça
demandera une refonte d'une partie de SPIP ... Mais je crois
franchement que le jeu en vaut la chandelle ... ce serait un sacré pas
en avant.

Pour une utilisation pro oui, mais va trouver un serveur LDAP chez un
hébergeur gratuit :o)

Mikaël

si tu connais dacode , il existe bien cohabitant sur le config.php les parametres ldap (nom de serveur, le dn , les ou, …) et les parametres internes. L’un n’empeche pas l’autre .
De plus on peut tres bien imaginer de synchroniser les tables de spip et le contenu des entrees ldap et ensuite d’utiliser spip comme maintenant, ce qui limite les modifs a faire dans spip.

Scrizzi Mikaël wrote:

le Thu, 14 Feb 2002 18:50:20 +0100
patrick scotto <patrick.scotto@wanadoo.fr> écrivait :

si tu connais dacode , il existe bien cohabitant sur le config.php
les parametres ldap (nom de serveur, le dn , les ou, ...) et les
parametres internes. L'un n'empeche pas l'autre .
De plus on peut tres bien imaginer de synchroniser les tables de spip
et le contenu des entrees ldap et ensuite d'utiliser spip comme
maintenant, ce qui limite les modifs a faire dans spip.

heu ... là ... ce serait juste un
bricolage pour intégrer vaille que vaille un spip dans un environement
hétérogéne tournant avec LDAP comme pierre de voute ...

J'ai déjà fait ce genre de bricolage et .. au final .. on perd tout ce
qu'apporte LDAP.

L'approche que j'imaginait serait d'avoir une gestion des utilisateur
"à la pam" ou le mode de gestion est laissé à une sorte de plugin,
toute l'utilisation de la gestion des users passant par une API.

question logique : qu’attends t on du ldap ?

pour moi , dans l’application se debarrasser du nom prenom password et toutes les “choses” attachées a un user , ensuite avoir en plus dans l’entree ldap un UIN (unique identifiant Number) qui assure la liaison coherente avec l’application . Dans l’application gerer les “roles” du user pour une appli , et les copier dans un object class spipserver1 de l’entree du user.
l’heterogeneite est normale … a un moment ou un autre ;-), ne serait ce que de passer de openldap a iplanet directory server
qu’attends tu du ldap ?

Arnaud Fontaine wrote:

patrick scotto (patrick.scotto@wanadoo.fr) a écrit:

question logique : qu'attends t on du ldap ?

pour moi , dans l'application se debarrasser du nom prenom password et
toutes les "choses" attachées a un user , ensuite avoir en plus dans
l'entree ldap un UIN (unique identifiant Number) qui assure la liaison

uidNumber : (extrait du schema nis : RFC2307) tu veux dire ?

coherente avec l'application . Dans l'application gerer les "roles" du
user pour une appli , et les copier dans un object class spipserver1 de
l'entree du user.
l'heterogeneite est normale .... a un moment ou un autre ;-), ne serait
ce que de passer de openldap a iplanet directory server
qu'attends tu du ldap ?

Pourrais-tu reformuler ta réponse j'avoue ne pas avoir tout compris.

Arnaud Fontaine wrote:

>le Thu, 14 Feb 2002 18:50:20 +0100
>patrick scotto <patrick.scotto@wanadoo.fr> écrivait :
>
>>si tu connais dacode , il existe bien cohabitant sur le config.php
>>les parametres ldap (nom de serveur, le dn , les ou, ...) et les
>>parametres internes. L'un n'empeche pas l'autre .
>>De plus on peut tres bien imaginer de synchroniser les tables de spip
>>et le contenu des entrees ldap et ensuite d'utiliser spip comme
>>maintenant, ce qui limite les modifs a faire dans spip.
>>

la gestion de LDAP daCode est un peu "douteuse" il me semble.
Leur schema n'est pas tres propre non plus.

>
>heu ... là ... ce serait juste un
>bricolage pour intégrer vaille que vaille un spip dans un environement
>hétérogéne tournant avec LDAP comme pierre de voute ...
>
>J'ai déjà fait ce genre de bricolage et .. au final .. on perd tout ce
>qu'apporte LDAP.
>
>L'approche que j'imaginait serait d'avoir une gestion des utilisateur
>"à la pam" ou le mode de gestion est laissé à une sorte de plugin,
>toute l'utilisation de la gestion des users passant par une API.

oui c'est une bonne solution.
Une classe (classe abstraite dans d'autre langage) qui permetrait
une authentification transparente en SQL,LDAP ou je ne sais quoi
d'autres (NIS :slight_smile:

dans une implementation de ce type il faut faire également
attention au format du mot de passe (crypt,md5...)

Fabien

le Thu, 14 Feb 2002 20:12:10 +0100
Fabien VALLON <fabien.vallon@fr.alcove.com> écrivait :

la gestion de LDAP daCode est un peu "douteuse" il me semble.
Leur schema n'est pas tres propre non plus.

C'est le moins que l'on puisse dire.
Je pense qu'ils ne connaissent pas bien LDAP et les schémas standards
qui existent. Ceci dit, LDAP dans DaCode, c'est vraiment pour dire que
DaCode ça déchire grave et que ça fait aussi du LDAP en plus du café
:slight_smile:

dans une implementation de ce type il faut faire également
attention au format du mot de passe (crypt,md5...)

On peut du coup utiliser le format "classique" :
(oops ... j'ai un trou, là sur la syntaxe ...)
cryptage:forme codée dans ce cryptage

par exemple :
crypt:$1$g5uTDWF0$ilTVliGOG5u3qqd8URg1t/

Le mot de passe est stocké seulement dans la base ldap , et codé (ex: sha1 dans directory server) par le serveur ldap lors du ldapadd ou ldap modify .
Pour identifiie un user et verifier ses droits on a juste a mettre le script dans le dossier “identifie ldap” , ce qui declenche le code 401 du navigateur , saisie log password et l’apache rend l’identification ok ou non , que du tres classique quoi ?

Je ne vois vraiment pas pourquoi s interesser au codage du mot de passe ?

Arnaud Fontaine wrote:

le Sat, 16 Feb 2002 10:21:32 +0100
patrick scotto <patrick.scotto@wanadoo.fr> écrivait :

Je ne vois vraiment pas pourquoi s interesser au codage du mot de passe ?

Ben ... pour pouvoir vérifier le mot de passe :slight_smile:

Soit on fait un binding ldap et là ... ldap doit savoir quel est le
codage du mot de passe, soit on récupére les infos utilisateur et la
forme cryptée (pas question d'avoir les mots de passe stockés en
clair), et il faut connaitre le codage pour faire nous même la vérif.