Project

General

Profile

Evolution #239

Authentification LDAP

Added by Laurent Pelecq over 9 years ago. Updated over 2 years ago.

Status:
Rejeté
Priority:
Normal
Category:
Core
Target version:
-
Start date:
05/06/2012
Due date:
% Done:

0%

Estimated time:
Vote:

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
  1. L'URL LDAP
  2. DN de connexion
  3. Mot de passe de connexion
  4. Filtre de recherche
  5. 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) :
  1. connexion à l'annuaire pour récupérer le DN de l'utilisateur grâce
    au filtre de recherche,
  2. contrôle de l'accès avec le filtre de sélection s'il existe
  3. 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.


Related issues

Is duplicate of Galette - Souhaits #764: Client OpenIDRejeté12/21/2013

Actions
#1

Updated by Johan Cwiklinski over 9 years ago

  • Assignee set to Johan Cwiklinski
  • Category set to 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.

#2

Updated by Anonymous over 9 years ago

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.

#3

Updated by Johan Cwiklinski over 9 years ago

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.

#4

Updated by Laurent Pelecq over 9 years ago

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.

#5

Updated by Laurent Pelecq about 9 years ago

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.

#6

Updated by Johan Cwiklinski almost 8 years ago

  • Status changed from Nouveau to Rejeté

OpenID me semble une idée bien plus pérenne, et ne serait pas limitée aux seuls serveurs LDAP.

#7

Updated by Blaise Dulaurent over 2 years ago

Est-ce qu'il y a quelque chose dans le tuyau côté LDAP ou OPENID ?

Also available in: Atom PDF