Fonctionnalité en rapport avec le ticket #892

Objectif

Utiliser le moteur de règles génériques pour :
  • affecter des utilisateurs à des entités
  • affecter des droits à des utilisateurs

Les attributs utilisés pour la définition des règles proviennent de l'annuaire LDAP ou des informations de connexion IMAP/POP.

Définition

Affectation d'un utilisateur à une entité

On se base sur des attributs de l'annuaire :
  • ou
  • o
  • dc
  • etc...
    On peut aussi utiliser des valeurs internes à GLPI comme :
  • nom du serveur LDAP
Pour IMAP/POP, 2 attributs sont pris en compte :
  • serveur IMAP/POP
  • email

Affectation à un utilisateur d'un profil

L'affection se fait aussi à l'aide de règles. Celles-ci permettent d'affecter à un utilisateur un droit.
Elles peuvent être du type :
  • vérification de la valeur d'un champs LDAP
  • vérification de l'appartenance d'un utilisateur à un groupe
  • etc...

Ce qui a été implémenté

Un nouveau type de règle a été crée.
La définition des règle se fait par :
  • entity.form.php : on peut directement crée une nouvelle règle d'affectation à l'entité sélectionnée. Il est possible, si on le désire de préciser si l'on veut aussi définir en même temps un profil et si le droit d'accès à l'entité est récursif ou pas
  • rule.form.php : sélectionner le type "règles d'affectations des utilisateurs à des entités". Il suffit ensuite de cliquer sur le bouton + pour créer une nouvelle règle
3 types de règles d'affectations ont été implémenté :
  • affectation d'un utilisateur à une entité
  • affectation d'un profil à un utilisateur
  • affectation d'un utilisateur à une entité avec un certain profil
Ces règles peuvent s'appuyer sur une liste de critères :
  • entrés manuellement par l'administrateur (o, dn, mail, etc...)
  • des critères provenant de GLPI : à l'heure actuelle les critères disponibles sont
    • pour LDAP
      • groupe
      • serveur LDAP
    • pour POP/IMAP
      • email
      • serveur POP/IMAP

Déroulement de la phase d'affectation

On suppose que l'utilisateur s'authentifie sur un annuaire LDAP.
  • un utilisateur se connecte avec son login/password
  • GLPI se connecte (soit en anonymous, soit via le rootdn et le rootpassword) à l'annuaire LDAP
  • GLPI effectue un bind avec le login/password de l'utilisateur
  • GLPI récupère les informations LDAP nécessaires (précisée dans la configuration du serveur LDAP)
  • GLPI effectue une 2ème requête sur l'annuaire afin de récupérer les attributs LDAP de l'entrée utilisateur nécessaires pour la vérification des règles d'affectation : Les règles d'affectation doivent obligatoirement être basées sur des attributs de l'entrée utilisateur dans l'annuaire
  • GLPI essaye de vérifier toutes les règles d'affectation : le moteur ne s'arrête pas à la première règle qui est vérifiée
  • GLPI récupère les informations d'affectation sous la forme de 3 tableaux :
    • affectation complètes : la règle avait pour action l'affectation à une entité et avec un profil précis
    • affectation à une entité : la liste de toutes les entités qui ont été récupérés via les règles
    • affectation d'un profil : la liste de tous les profils qui ont été récupérés via les règles
  • GLPI ajoute dans un premier temps les droits des affectations complètes
  • GLPI parcours le tableau des entités à affecter, et pour chacune des entités associe tous les profils trouvés
  • GLPI connecte l'utilisateur à l'interface en lui affectant les bons profils et les bonnes entités

Considération sur les règles

Il convient de factoriser au maximum les règles d'affectation car elles seront exécutées à chaque authentification de l'utilisateur.

Exemple de factorisation

Hypothèses :
  • On dispose de 3 entitées :
    • A
    • B
    • C
  • 2 droits sont utilisés :
    • Admin
    • Normal
  • Tous les utilisateurs ont accès à une entité en fonction de leur dn avec profil Normal
  • Certains utilisateurs ont accès à l'entité A avec profil Admin si leur entrée utilisateur contient l'attribut departmentNumber à la valeur admin
Première possibilité :
  • On définit une règle générale d'affectation du profil :
    • si le dn est * (sera toujours vérifié) on assigne le profil Normal
  • On définit 3 règles d'affectation aux entités :
    • si l'utilisateur a le dn qui contient ou=entiteA alors affectation à l'entité A
    • si l'utilisateur a le dn qui contient ou=entiteB alors affectation à l'entité B
    • si l'utilisateur a le dn qui contient ou=entiteC alors affectation à l'entité C
  • On définit une règle d'affectation spécifique :
    • si l'utilisateur a l'attribut departmentNumber a 'admin' alors on assigne le profil Admin pour l'entité A
Deuxième possibilité :
  • On définit 4 règles d'affectation spécifiques :
    • si l'utilisateur a le dn qui contient ou=entiteA alors affectation à l'entité A avec profil Normal
    • si l'utilisateur a le dn qui contient ou=entiteB alors affectation à l'entité B avec profil Normal
    • si l'utilisateur a le dn qui contient ou=entiteC alors affectation à l'entité C avec profil Normal
    • si l'utilisateur a l'attribut departmentNumber a 'admin' alors on assigne le profil Admin pour l'entité A
*Comparaison : *
  • Dans la première possibilité, le changement du profil par défaut ne demande la modification que d'une règle
  • Dans la deuxième possibilité le moteur ne traite que 4 règles au lieu de 5 dans la première
  • La première possibilité est plus lisible, puisque l'on a 2 types de règles bien séparées (profil et entité) et une pour traiter des cas spécifiques