Question subsidiaire : dans le concept de base, j'ai prévu un rôle intermédiaire qui permet de créer des espaces de travail. Cela signifie, si j'ai bien compris la pratique LDAP qu'il faudrait que mon soft puisse créer des groupes dans LDAP, ce qui est à bannir (cf citation ci-dessus).
Ce n’est pas nécessairement à bannir. Le truc c’est que j’ai vu des applis web qui demandaient le mot de passe root, et ça je dis non.
À mon avis le mieux est de créer un groupe privilégié avec des ACL bien taillées pour l’usage (par exemple, qui a seulement le droit de créer des groupes dans une arborescence particulière et rien d’autre), et tu crées un utilisateur de maintenance qui appartient à ce groupe.
Le problème des applis web qui font du LDAP, c’est que toi tu peux administrer le LDAP et quelqu’un d’autre développe l’appli web, et là tu n’as pas la moindre envie de mettre ton mot de passe root dans un fichier de config.
Typiquement tu fournis un espace disque, un server http, un serveur mysql, un serveur ldap déjà peuplé, il faut que quelqu’un d’autre que toi crée un blog qui soit accessible de tout utilisateur connu du ldap.
À ce quelqu’un d’autre tu donnes un dossier avec les bon droits unix, tu mets la bonne config apache/nginx, tu fournis une base de donnée, mais non, tu ne donnes pas le mot de passe root de ton LDAP, le plus simple est encore de ne faire que de l’authentification (aucun mot de passe à donner, ça utilise celui de l’utilisateur), et si tu as besoin que l’appli créée de groupes, et bien fait des ACL. Le fait de se limiter à la simple authentification simplifie beaucoup les choses, mais bien évidemment, parfois ça ne suffit pas.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Je profite de la présence de compétences LDAP sur ce fil de discussion...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Disputatio : Samba, Kerberos et LDAP. Évalué à 3.
Ce n’est pas nécessairement à bannir. Le truc c’est que j’ai vu des applis web qui demandaient le mot de passe root, et ça je dis non.
À mon avis le mieux est de créer un groupe privilégié avec des ACL bien taillées pour l’usage (par exemple, qui a seulement le droit de créer des groupes dans une arborescence particulière et rien d’autre), et tu crées un utilisateur de maintenance qui appartient à ce groupe.
Le problème des applis web qui font du LDAP, c’est que toi tu peux administrer le LDAP et quelqu’un d’autre développe l’appli web, et là tu n’as pas la moindre envie de mettre ton mot de passe root dans un fichier de config.
Typiquement tu fournis un espace disque, un server http, un serveur mysql, un serveur ldap déjà peuplé, il faut que quelqu’un d’autre que toi crée un blog qui soit accessible de tout utilisateur connu du ldap.
À ce quelqu’un d’autre tu donnes un dossier avec les bon droits unix, tu mets la bonne config apache/nginx, tu fournis une base de donnée, mais non, tu ne donnes pas le mot de passe root de ton LDAP, le plus simple est encore de ne faire que de l’authentification (aucun mot de passe à donner, ça utilise celui de l’utilisateur), et si tu as besoin que l’appli créée de groupes, et bien fait des ACL. Le fait de se limiter à la simple authentification simplifie beaucoup les choses, mais bien évidemment, parfois ça ne suffit pas.
ce commentaire est sous licence cc by 4 et précédentes