Evolution #239
fermé
Authentification LDAP
0%
Description
L'authentification peut soit être codée en dur dans Galette (Solution 1) ou mise à disposition dans un plugin à condition de permettre de déléguer l'authentification aux plugins (Solution 2). La deuxième solution est plus flexible.
Solution 1 : codage direct dans Galette¶
Il faut une page d'administration qui permette de saisir- L'URL LDAP
- DN de connexion
- Mot de passe de connexion
- Filtre de recherche
- Filtre de sélection
L'URL est de type ldap://HOSTNAME ou ldaps://HOSTNAME. On peut aussi accepter HOSTNAME:PORT.
Le DN de connexion sert à rechercher le DN de l'utilisateur à l'aide du filtre. Il peut-être vide si une connexion anonyme suffit. Le filtre de recherche contient un emplacement pour insérer le login de galette.
Dans l'exemple suivant, on utilise $login comme variable :
(&(objectClass=inetOrgPerson)(uid=$login))
Le filtre de sélection permet de restreindre l'accès aux utilisateurs appartenant à un groupe donné par exemple. Le résultat de la requête doit être non vide. Les variables seront les champs récupérés dans l'entrée LDAP de l'utilisateur lors de la première recherche ($dn pour le DN, $mail pour le mail, ...). Pour sélectionner que les membres du groupe galette, on mettra par exemple :
(&(objectClass=groupOfUniqueNames)(cn=galette)(uniqueMember=$dn))
La page doit permettre d'activer ou désactiver l'authentification. Les paramètres peuvent être sauvés dans un fichier ou dans la base (prévoir la mise à jour). Ils devront être accessible aux plugins qui utiliseront LDAP.
L'authentification se fera en 3 temps (cf. exemple d'autehntification) :- connexion à l'annuaire pour récupérer le DN de l'utilisateur grâce
au filtre de recherche, - contrôle de l'accès avec le filtre de sélection s'il existe
- connexion avec le DN de l'utilisateur et le mot de passe.
En cas d'échec, on s'authentifie avec la méthode par défaut ce qui permet d'avoir des comptes d'administration gérés en dehors de LDAP.
Le changement de mot de passe devra d'abord être délégué à LDAP (cf. implémentation) puis au mécanisme de base. La recherche de l'utilisateur se fera de la même façon avec les deux filtres.
Solution 2 : la délégation au plugins¶
La page d'administration LDAP et l'implémentation de la classe d'authentification seront déléguées au plugin. Il faudra prévoir une page d'administration qui propose les méthodes d'authentification fournies par les plugins. On peut envisager de chainer les mécanismes dans un ordre particulier. Le changement de mot de passe devra aussi être délégué aux plugins dans le même ordre.
Le plugin fournira un fichier login.php qui contiendra une classe d'authentification qui implémentera au moins les méthodes suivantes :- login(username, password)
- changePassword(username, password)
- exists(username)
Il n'y a pas de méthode logout. C'est Galette qui gère le cycle de vie des sessions. Le plugin ne fait qu'authentifier l'utilisateur.
Mis à jour par Johan Cwiklinski il y a plus de 12 ans
- Assigné à mis à Johan Cwiklinski
- Catégorie mis à Core
Merci pour cette demande bien détaillée :)
Je pense aussi que la seconde solution serait probablement préférable ; et amènerait d'avantage de possibilités. Le système de plugins ne propose à l'heure actuelle rien qui permette d'implémenter ça ; mais je suis parfaitement pour que ce soit fait.
Je vais réfléchir à la question.
Mis à jour par Anonyme il y a plus de 12 ans
En lisant un peu la documentation à destination des développeurs de plugins je me demandais pourquoi ne pas mettre en place un système événementiel à base d'observer ou de hooks comme dans la majorité des logiciels supportant des plugins ? La mise en place de différentes méthodes d'authentification s'accomode très bien de ces méthodes (il suffit de réagir à certains événements comme vérification de mot de passe ou demande d'authentification), et cela pourrait permettre la mise en place de méthodes génériques pour faciliter l'extensibilité de Galette par la suite.
Actuellement j'ai l'impression que c'est un peu fait au cas par cas (tel fichier nommé de telle façon pour faire cela, etc.), je pense que ça permettrait d'anticiper la suite et d'accroître les possibilités offertes aux développeurs de plugins. Chaque association a des besoins uniques et ça me semblerait cohérent de conserver une base réduite et d'offrir plus de possibilités aux plugins.
Je (re)découvre Galette, désolé si ce que je dis a déjà été débattu ailleurs.
Mis à jour par Johan Cwiklinski il y a plus de 12 ans
Vincent P. a écrit :
En lisant un peu la documentation à destination des développeurs de plugins je me demandais pourquoi ne pas mettre en place un système événementiel à base d'observer ou de hooks comme dans la majorité des logiciels supportant des plugins ? La mise en place de différentes méthodes d'authentification s'accomode très bien de ces méthodes (il suffit de réagir à certains événements comme vérification de mot de passe ou demande d'authentification), et cela pourrait permettre la mise en place de méthodes génériques pour faciliter l'extensibilité de Galette par la suite.
C'est en effet une idée.
Actuellement j'ai l'impression que c'est un peu fait au cas par cas (tel fichier nommé de telle façon pour faire cela, etc.), je pense que ça permettrait d'anticiper la suite et d'accroître les possibilités offertes aux développeurs de plugins. Chaque association a des besoins uniques et ça me semblerait cohérent de conserver une base réduite et d'offrir plus de possibilités aux plugins.
Je (re)découvre Galette, désolé si ce que je dis a déjà été débattu ailleurs.
Je me suis lancé dans l'intégration de plugins dans Galette sans avoir trop d'idées de ce que tout ça devrait faire, j'ai découvert un peu les choses au fur et à mesure (je n'ai pas la chance d'avoir jamais travaillé sur un projet implémentant un tel système).
Ce que tu propose me semble intéressant, aurais-tu un exemple de logiciel qui pourrait me servir de référence en la matière ?
Je suis parfaitement conscient que le système de plugins actuel n'est pas extensible à l'infini en l'état ; et s'il faut le changer, ça peut être pas mal que ce soit fait avant que de trop nombreux/complexes plugins aient vu le jour.
Mis à jour par Laurent Pelecq il y a plus de 12 ans
Drupal utilise un système de hook (http://drupal.org/node/292). Les fonctions qu'on peut implémenter sont prédéfinis (http://api.drupal.org/api/drupal/includes!module.inc/group/hooks/7), chaque plugin préfixe le nom de la fonction par son nom de module.
Il y a un exemple de module d'indentification avec openid (http://drupal.org/node/880666). Il est intéressant parce que l'authentification ne ce fait pas par login/password. On peut voir ce que donne une authentification openid ici (https://www.openstreetmap.org/login). Selon le fournisseur qu'on choisit, on est redirigé vers une page externe.
Il faudrait pouvoir déléguer le formulaire dans la page de login elle-même. L'utilisateur choisit le type d'authentification, ce qui fait apparaitre le formulaire approprié ou redirige vers un autre site par exemple.
Mis à jour par Laurent Pelecq il y a plus de 12 ans
Il y aurait une autre approche. Ce serait de ne supporter que l'authentification OpenId en plus de l'authentification de base.
Un logiciel comme LemonLDAP permet de proposer OpenId avec des dizaines de backend dont LDAP.
http://lemonldap-ng.org/documentation/1.2/start
Ça permet de proposer une authentification générique en déléguant la mécanique à un logiciel spécialisé pour ça.
Mis à jour par Johan Cwiklinski il y a presque 11 ans
- Statut changé de Nouveau à Rejeté
OpenID me semble une idée bien plus pérenne, et ne serait pas limitée aux seuls serveurs LDAP.
Mis à jour par Blaise Dulaurent il y a presque 6 ans
Est-ce qu'il y a quelque chose dans le tuyau côté LDAP ou OPENID ?