Ajout LDAP
Il serait important que Chill puisse se connecter à un LDAP. Nous connaissons au moins deux exemples où cela serait nécessaire.
Actuellement, j'ai l'impression qu'il vaudrait mieux imaginer un système de synchronisation de la base de donnée postgresql avec le LDAP, par exemple par un script cron ou une fonction qui serait exécutée lors de la connexion d'un utilisateur.
Cela aurait pour impact que, après la modification du LDAP pour ajouter un nouvel utilisateur (ou en supprimer un), il faudrait attendre quelques minutes avant que le nouvel utilisateur puisse se connecter.
Par contre, on pourrait faire en sorte que les mots de passe soient vérifiés auprès du LDAP, plutôt qu'auprès de la base de donnée. Cela permettra à un utilisateur de se connecter directement avec le nouveau mot de passe s'il vient de le changer.
Donc on aurait les modifications suivantes à apporter :
- créer un script qui importe les utilisateurs depuis le ldap ;
- ajouter un
custom authenticator
qui vérifierait les mots de passe auprès du LDAP (http://symfony.com/doc/current/cookbook/security/custom_password_authenticator.html);
Améliorations possibles
cas des utilisateurs avec un portail interne
Il existe des utilisateurs qui ont un portail interne / intranet et voudraient que les utilisateurs puissent être authentifiés directement en cliquant sur un lien vers chill, depuis le portail.
Et on peut imaginer également créer un champ dans le ldap avec une information aléatoire (24 chiffre au hasard, ...) qui servirait à l'authentification depuis une URL (exemple d'URL : http://vers.chill.social/?auth=jkel55eslenb6s5ee4d53). Sur le portail, on ajoute cette clé dans l'URL vers chill et, quand Chill détecte cette clé, il vérifie la valeur dans le LDAP et, le cas échéant, ouvre une session pour l'utilisateur.
Import des groupes et droits
Chill vérifie les droits sur les entités en fonction de deux à trois paramètres : l'utilisateur doit posséder les droits sur des cercles de la ressource, et pour le centre donné:
- les droits: il s'agit, en gros, des actions: voir une personne, modifier le dossier d'une personne, créer une activité, etc.
- le centre: les utilisateurs ont certains droits dans certains centres.
- le cercle (optionnel) : un utilisateur peut publier / voir des informations dans un cercle particulier, par exemple le cercle psy, le cercle administratif, etc. On peut imaginer que les psy peuvent voir l'administratif, mais pas l'inverse.
La page 23 de cette présentation illustre ça : http://chill.social/files/presentation_rencontres_chill_2015-09-22.pdf#23
Tout ça est stocké en base de donnée.
Le plus simple est de conserver la création et l'authentification à partir du LDAP, et gérer les groupes/cercles/centres dans l'interface de Chill, comme c'est le cas maintenant.
Mais si on a déjà des groupes dans un LDAP, cela risque d'être une gestion en doublon (on crée les groupes dans le LDAP pour d'autres applications, et on doit les re-créer dans Chill).
On pourrait faire en sorte que le script d'import importe également les groupes et les droits de chaque groupe. Donc, dans le LDAP, on aurait ceci :
dn: cn=medecins,ou=blabla,dc=mass,dc=be
objectClass: top
objectClass: groupOfNames
cn: medecins
# ajouter ici les informations sur les droits (centre, cercles, etc.)
member: uid=membre1
member: uid=membre2
# ....
Et le script d'import créerait les groupes requis et y ajouterait les membres membre1
, membre2
, etc.