Ubuntu-fr

mrjk

Single Sign On: Comment organiser ldap? NetAdmin

Bonjour!

Alors, avant de rentrer dans les détails, ma question est comment organiser de manière efficace/flexible un annuaire OpenLDAP afin de gérer des utilisateurs, leur droits et groupes ainsi que certains de leurs paramètres?

Donc voila, question posée, j'ai un petit serveur Debian famillial avec différents services:
- blog
- ftp
- openvpn
- partages samba
- divers service web (pmwiki, tt-rss, drupal .... )
- access ssh - sur plusieurs machines
- etc ...

Alors tout ça fonctionne à peu près pas trop mal, mais maintenant, j'aimerai mettre en place un système de SSO, et centraliser un maximum de choses.

Alors j'ai vu qu'ils y avait plusieurs solutions, mais je m'y connais pas très bien:
- logiciel <-> ldap
- logiciel <-> CAS <-> ldap
- logiciel <-> FreeRadius <-> ldap
Mon avis est qu'ils peuvent être complémentaire, mais bon, je vous pose la question.

Donc, dans un premier temps, j'ai essayé le premier point, mais je me suis vite rendu compte que organiser l'annuaire est un vrai défi. j'aimerai avoir un truc du genre:
uid=toto
+ Parametres modifiables par l'user (mdp, nom, email ...)
+ Paramètres d'admin (groupe, home, droits ...)
+- Serv1_SSH
+- Serv1_Drupal
+- Serv2_SSH
+- etc ...

L'interet de mettre les choses ainsi, c'est que ça permet une bonne visibilité des entrées d'un utilisateur, que c'est organisé et que ça évite de la redondance. J'ai aussi pensé à un modèle à plat, mais c'est bcp moins lisible, mais ça reste envisageable (grace aux objets AUXILLIARY) Pour arriver à ça, je me suis crée mes propres shemas, en faisant des mixs de ce qui existe déjà.

Mais j'ai des problèmes:
- Un client ldap ne peut pas chercher différentes informations sur deux chemains différents (ou en tout cas, ça dépends de l'implémentation du client) => Chaque client est un cas particulier à configurer, et souvent, ça ne marche pas.
- Je peux utiliser les schemas déjà fournis par des apps (genre samba, postfix, etc ...), mais alors je casse le principe de non redondance.

Alors mes questions sont:
- Ma manière d'organiser mon annuaire, est-elle bonne? Qu'elle sont vos expériences?
- Est-ce qu'utiliser CAS ou FreeRadius simplifierai mes problèmes? Ou même d'autres solutions?
- Comment bien gérer mes permissions? Ex: tel user à le droit d'utiliser le wiki, mais le SSH sur telle machine.

Bin, déjà c'est pas mal si je peux avoir des retours d'expériences, des avis et des conseils ^^ Hésitez à me demander des éclaircissements!

Merci bcp

Note: ce sujet est une copie de http://forum.hardware.fr/hfr/reseauxper … 9154_1.htm ... Parceque sur FHW, ils ont pas l'air très interessé....

mrjk

Re : Single Sign On: Comment organiser ldap? NetAdmin

Personne ? :s Ptet que je suis pas dans la bonne catégorie ?

cbo

Re : Single Sign On: Comment organiser ldap? NetAdmin

Disons que la réponse n'est pas si simple de plus, j'ai l'impression que tu mélanges, du moins de mon point de vue, différents concepts.

SSO (si tu entends par là "Single Sign On" qui permet à l'utilisateur de s'authentifier une seule fios pour accéder à plusieur services), ne dépend pas du DIT (Directory Information Tree, c'est à dire la structure de LDAP) mais de la solution commune à tous les services pour valider que l'utlisateur est déjà authentifié.
Ce pourrait par exemple ête l'obtension d'un ticket Kerberos, pourquoi pas basée sur une authentificaiton LDAP, soit directement soit via Radius. Bref, on peut complexifier à souhait mais au final, ce n'est pas le backend d'authentifcation qui fourni la foncitonnalité SSO.

Si par SSO tu entends en revanche "Same Sign-On" (c'est à dire que l'utilisateur dispose d'un seul compte et mot de passe pour tous les services, alors la structure de LDAP est importante. Pour éviter les confusions, je parlerai ici de CSO, c'est à dire "Common Sign-On".

Mon conseil est de n'utiliser, quel que soit le DIT, une seule entré par utilisateur, laquelle contient les classes d'objet (objectclass) contenant les attributs nécessaires aux fonctionnement des différents clients et services.
La plupart des solutions construites pour s'appuier sur LDAP viennent soit avec un schéma propriétaire soit un schéma défini dans une RFC.
Il est très fortement souhaitable d'utiliser ces schéma plutôt que re-inventer le sien sauf si tu dois developper ta propre application ou personnaliser la manière dont le client LDAP formule ses requêtes.

Pour le dire différement, il est beaucoup plus simple d'utiliser Samba avec les attributs standards plutôt que reinventer son propre schema.
l'entrèe contient juste plusieurs objectclass ce que tu n'as probablement pas encore bien assimilé car tu associes, de manière erronée, la structure de l'entrée (le fait d'utiliser plusieurs objectclass) avec le DIT.

Quelques commentaires supplémentaires, pas liés avec LDAP:

- Radius est un protocole réseau initialement concu pour transporter l'authentification remote d'utilisateurs. L'authentificaiton elle même peut être LDAP, Kerberos, One Time Password etc...)
- CAS, si tu entends par là "Central Authenticaiton Service" est une solution qui vise à fournir du SSO, initialement pour des applications de type "web". Le principe est très proche de Kerberos (obtention d'un ticket auprès d'un serveur d'authentifcation central qui est ensuite contacté par les applications). C'est très bien mais:
- totallement démesuré pour un déploiement "at home"
- assez simple (quoique, au niveau de quesitons que tu te poses, c'est encore un peu compliqué) pour des appli "web" mais un peu plus difficile quand ca n'existe pas "out of the box" pour les appli non web.

Bref, répondre à ta question qui adresse beaucoup de domaines et concepts différents nécessite plus que quelques pages de "consulting"

Pourquoi ne pas commencer progressivement par définir le DIT en fonction de besoins de délégation ou de performance, encore que je pense qu'aucun de ces 2 point ne soit valide à la maison ou même dans une petite à moyenne entreprise, raison pour laquelle j'organiserai le DIT par type d'entre: people, groups etc...

Travaille ensuite par service pour implementer une version du service qui s'appuie sur LDAP en utilisant l'entrée utilisateur existante: le point de passage quasi obligatoire, si tu veux une interface d'admin conviviale, va être de développer ton propore client de gestion des entrées qui va vérifier que tu utilises la bonne classe d'objet pour le bon service.

La mise en oeuvre d'un SSO se trouve encore quelques étapes plus loin, ou alors il faut aller directement vers des solutons "tout Micro$oft".
Du point de vue que tu décris, ca marche plutot bien. Il y a juste quelques inconvenients et c'est plutôt un choix de religion que technique

I hope this helps.
Christian

mrjk

Re : Single Sign On: Comment organiser ldap? NetAdmin

Salut CBO :-)

Tout d'abord, merci beaucoup d'avoir pris le temps de m'avoir répondu :-) C'est cool, tu m'as appris plein de vocabulaire!!! Alors, dans l'ordre:

Si par SSO tu entends en revanche "Same Sign-On" (c'est à dire que l'utilisateur dispose d'un seul compte et mot de passe pour tous les services, alors la structure de LDAP est importante. Pour éviter les confusions, je parlerai ici de CSO, c'est à dire "Common Sign-On".

Oui, c'est dans ce sens là que je l'entendais, mais je savais pas que SSO avait plusieurs signification. En effet, faire du single sign-on ne m'interresse pas plus que ça, les browser le font très bien avec la mémoire des mot de passes, et sinon avec les cookies ...

Mon conseil est de n'utiliser, quel que soit le DIT, une seule entré par utilisateur, laquelle contient les classes d'objet (objectclass) contenant les attributs nécessaires aux fonctionnement des différents clients et services.
La plupart des solutions construites pour s'appuier sur LDAP viennent soit avec un schéma propriétaire soit un schéma défini dans une RFC.

Parfaitement d'accord!

Il est très fortement souhaitable d'utiliser ces schéma plutôt que re-inventer le sien sauf si tu dois developper ta propre application ou personnaliser la manière dont le client LDAP formule ses requêtes.

Là il y'a un problème dans mon cas! C'est que justement le fait que tous les shemas soient fournis implique des redondances, principalement le nom d'utilisateur et le mot de passe (on va prendre que ces deux là pour faire simple, mais y'a aussi le home, le nom, le prenom, le mail ...). Donc comment faire pour régler ce problème, sans refaire soit même ses schemas? Ce qui m'amène au point suivant...

Pour le dire différement, il est beaucoup plus simple d'utiliser Samba avec les attributs standards plutôt que reinventer son propre schema.

Hé bien enfait, je ne crée pas mes schémas, je me base sur les schemas fournis pour faire les miens. Par exemple, pour la l'objet INETORGPERSON, je m'en suis crée un équivalent, avec les attributs qui m'importaient: c'est une sorte de simplification, et ça me parait plus claire. Et si ça me limite pour utiliser d'autres apps, je comptais lui rajouter un aubjet en AUXILLIARY. Ca me paraissait assez souple de faire ça. Mais donc, d'après ton expérience, ce n'est pas la manière élégante de faire??? Et dans ce cas, je me retrouve avec le problème de redondance du point précédent :s

l'entrèe contient juste plusieurs objectclass ce que tu n'as probablement pas encore bien assimilé car tu associes, de manière erronée, la structure de l'entrée (le fait d'utiliser plusieurs objectclass) avec le DIT.

Hum, c'est vrais que l'on peut faire ça, ça m'était sortie de l'esprit... Bah alors, c'est quoi la différence entre avoir une entrée avec plusieurs objectclass et entre plusieurs une entrée avec plusieurs objectclass de type AUXILLIARY (bien sur avec au moins une classe normale, ou 'top')??? J'ai peut être loupé un truc sur ce point comme tu dis ...

- Radius est un protocole réseau initialement concu pour transporter l'authentification remote d'utilisateurs. L'authentificaiton elle même peut être LDAP, Kerberos, One Time Password etc...)
- CAS, si tu entends par là "Central Authenticaiton Service" est une solution qui vise à fournir du SSO, initialement pour des applications de type "web". Le principe est très proche de Kerberos (obtention d'un ticket auprès d'un serveur d'authentifcation central qui est ensuite contacté par les applications). C'est très bien mais:
- totallement démesuré pour un déploiement "at home"
- assez simple (quoique, au niveau de quesitons que tu te poses, c'est encore un peu compliqué) pour des appli "web" mais un peu plus difficile quand ca n'existe pas "out of the box" pour les appli non web.

Oui, je ne crois pas que ce soit adapté à ce que je veux faire ... en tout cas pour le moment

Pourquoi ne pas commencer progressivement par définir le DIT en fonction de besoins de délégation ou de performance, encore que je pense qu'aucun de ces 2 point ne soit valide à la maison ou même dans une petite à moyenne entreprise, raison pour laquelle j'organiserai le DIT par type d'entre: people, groups etc...

I did, mais à chaque fois que je rajoutais un nouveau service, je me disais que je pouvais faire tout ce que j'avais fait précédamment de manière plus élégante ... Je t'accorde que c'est extremement peu productif, mais bon, ça me permet d'avancer au niveau des connaissances techniques :-) Je fait ça sur mon temps de loisir, alors, ça peut encore le faire ^^

Travaille ensuite par service pour implementer une version du service qui s'appuie sur LDAP en utilisant l'entrée utilisateur existante: le point de passage quasi obligatoire, si tu veux une interface d'admin conviviale, va être de développer ton propore client de gestion des entrées qui va vérifier que tu utilises la bonne classe d'objet pour le bon service.

He bien, c'est prévu a moyen terme (une bonne occase d'essayer d'apprendre Zend...) Donc faire une interface web qui gererait ça, mais moins y'a de script, plus ça veut dire que c'est simple, et on ne démontre plus la bienfaisance du simple

La mise en oeuvre d'un SSO se trouve encore quelques étapes plus loin, ou alors il faut aller directement vers des solutons "tout Micro$oft".

De quoi donc tu parle? Connait pas de phrase positives avec à la fois le mot serveur et Microsoft dedans </troll>. Nan, c'est clairement pas le but ici, j'ai envie de faire les choses bien, aussi bien dans le sens éthiques des choses que monétaires ;-)

Voila, donc, merci pour ta réponse, et je te redonne encore un peu de travail si tu as encore du courage :-)

Mercii

cbo

Re : Single Sign On: Comment organiser ldap? NetAdmin

Mrjk,

Tu n'as pas encore bien compris le fonctionnement de LDAP et je te suggère la lecture de quelques bouquins pour acquérir "les bases" (Tim Howes en a écrit un très bien). Sans ces bases, compte tenu des quesitons et des points que tu soulèves, je ne pense pas que tu arrives à quelque chose de sérieux.

Si tu as plusieurs entrées par utilisateur pour des raisons de non compréhension de la gestion du schéma, l'utilisateur devra utiliser plusieurs logins, ce qui va exactement à l'encontre de ce que tu veux obtenir (et d'ailleurs PERSONNE ne fait ca, du moins "sérieusement" )
Une des raisons est que le process d'authentification devrait être le suivant:
- l'application demande à l'utilisateur son login/pwd
- connexion au serveur LDAP en mode anonyme.
- recherche de l'entré qui match le login: le résultat DOIT être une entrée UNIQUE
- ldapbind avec le DN de l'entrée trouvée et le pwd fourni.

Dans un autre ordre d'idée: la modificaiton de classes d'objets "standard" pour en créer une qui ne reprend qu'une partie des attributs ne préesente pas d'intèrêt sauf si tu souhaites changer le caractère optionnel ou obligatoire d'un attribut (par exemple ne pas utiliser un attribut qui est déclaré comme obligatoire dans le schéma standard ou au contriare rendre obligatoire un attribut qui ne l'est pas.