> la phase d'authentification [...] peut être effectuée [...] par [...] tout [...] méthode d'authentification disponible dans Apache2

> De plus, toutes les applications Web utilisant des protections Apache (par exemple par htaccess) sont nativement compatibles

Donc, si j'ai bien compris, ça permet (outre le SSO) d'unifier les méthodes d'identification web, quelles qu'elles soient entre LemonLDAP::NG et le serveur sur lequel on souhaite s'authentifier ? Par exemple, forcer l'utilisation d'un certificat de smartcard pour accéder à un service à la base "protégé" par htaccess... Intéressant.



D'autant que suis justement en train de me repencher sur LDAP - j'avais arrêté de le tester il y a un moment en me disant que le faible nombre d'utilisateurs que j'ai inhibait ses bénéfices, mais en fait, vu le nombre de machines que je finis par avoir avec les conteneurs OpenVZ/Vserver, j'ai maintenant dans l'idée de m'en servir comme base de données que mon CFengine maître utiliserait pour personnaliser les fichiers qu'il exporte aux clients, en faisant gaffe à gérer le cas d'indisponibilité du LDAP, et afin de répartir les données dans le réseau sans forcément les dupliquer à leur définition.

Par exemple, savoir sur quelles machines tourne quoi et à partir desquelles autres elles peuvent être jointes est utile pour configurer iptables sur les routeurs, pour configurer les serveurs, _et_ pour configurer les clients - or tant que le CFengine maître est le seul à connaître toutes ces données, rangées proprement dans une base de données LDAP, les ACL LDAP ne deviennent pas trop un enfer (par rapport à si je déléguais la recherche aux clients CFEngine)...

... pour ce qui est des ACL CFEngine, ie les "grant" du cfservd.conf, je pense "simplement" essayer de les fabriquer à partir des FDQN des hôtes (en créant autant de répertoires exportés que d'hôtes, et où seront personnalisés des fichiers de conf génériques, en fonction de certaines classes, assignées dans l'annuraire), et de LDAP...



Je n'ai pas encore trop réfléchi à comment bénéficier, au passage, de LDAP pour les authentifications (vu que ce n'est pas mon but initial), mais j'ai dans l'idée que je n'aurai pas trop de mal à trouver une place dans cet ensemble à LemonLDAP, entre autres.

Ce projet m'intéresse a priori car, après avoir exploité l'authentification intégrée et la délégation d'authentification avec Internet Information Server, je me suis longtemps demandé si et comment on pouvait faire pareil avec Apache. A première vue, c'en est un bel exemple.

Par contre, le simple fait d'utiliser XML pour les fichiers de configuration me donne de l'urticaire. Je vois de plus en plus de projets adopter XML en tant que support de données. Et la modification de ces données à la main est un vrai cauchemar pour monsieur-tout-le-monde.

D'après ce que j'ai constaté la plupart du temps et tel que je l'ai vu mis en oeuvre:

* XML n'est pas intuitif.
* XML n'est pas lisible facilement pour un humain.
* XML n'est pas convivial.
* XML possède trop de contraintes syntaxiques pour des choses simples (des commentaires, par exemple, via l'utilisation de sections CDATA et autres...)

Comparé à de simples fichiers INI, par exemple, ou d'autres types de fichiers texte, XML est totalement indigeste. XML est adapté à l'échange de données entre machines (c.-à-d. là où l'humain n'est pas sensé intervenir), pas au stockage, surtout si les données doivent être modifiées par l'humain et c'est souvent le cas.

Les exemples que j'ai sous la main pour illustrer mon opinion sont les fichiers de configuration de eINIT, de Xfont, de Hal... Je ne remets évidemment pas en cause tout ce beau projet. Je mets simplement l'accent sur le fait qu'il est préférable de ne choisir XML que s'il est inévitable.