hist_ldap.md

Sur le LDAP Frankiz

A l'origine Frankiz, le prédécesseur de sigma, avait sa propre base de données qu'il importait toutes les 3h dans un LDAP énorme et sale, qui contenait le strict minimum. Ce LDAP s'est révélé très utile à différents sites binets qui ont fait un usage très libre de cette ressource.

De sorte que quand il fallut remplacer Frankiz, la destruction du LDAP n'était pas possible sans revoir plusieurs sites binets (à voir, le CAS était peut-être une solution suffisante). On a donc choisi de tuer la BDD Frankiz, mais seulement après avoir considérablement enrichi le LDAP pour en faire la BDD utilisateurs et groupes principale de sigma.

Une documentation vieillissante est disponible sur le wikix par rapport au LDAP de Frankiz.

Le BR2017 a mené un gros travail de réorganisation du LDAP donc beaucoup d'informations sur le wikix ne seront plus valides.

Connexion LDAP

Tous les mots de passe utilisateurs sont stockés hashés dans le LDAP, et c'est donc lui qui sert finalement à toutes les opérations d'authenfication. Pour autant, on choisit de ne jamais se connecter au LDAP avec des identifiants utilisateurs pour trois raisons principales :

• Gestion de session : On sait pas comment gérer les sessions d'un point de vue LDAP ; il faudra garder en mémoire qui est connecté depuis quand jusqu'au LDAP, ce qui est lourd. En fait d'un point de vue sécurité on ne peut pas faire confiance à n'importe quelle requête GraphQL, donc l'authentification doit se faire avant le LDAP
• Performance : On ne peut bind qu'un seul utilisateur à la fois, donc c'est beaucoup plus efficace de faire des requêtes avec le service sigma direct
• Simplicité : Si on a un utilisateur sigma de toute façon, autant s'en servir pour faire les recherches aussi...

Ainsi, toutes les connexions au LDAP se font via un utilisateur sigma dédié doté de tous les droits imaginables. Cette connexion est ouverte au lancement du serveur et reste ouvert par la suite.

Nouvelle organisation du LDAP

Le LDAP a été significativement enrichi depuis Frankiz, puisqu'il contient la majeure partie des données utilisateurs et groupes de sigma. Les champs parent et child permettent aux resolvers afférents de faire descendre les admins et remonter les membres, mais n'a pas d'influence à l'intérieur de l'API LDAP.

Configuration

L'équivalence pratique entre champs du LDAP et champs du code est dans le fichier de configuration ldap_config. Idéalement, ce .json serait ensuite porté en une calsse dynamique dans le code. En atendant une structure pareille, on se contentera des structures de données décrites dans config.

Une structure particulière

Les admins et membres sont de deux types ; les admins et membres stricts, acceptés par un administrateur dans le groupe, et les admins et membres hérités, qui ont rejoint ce groupe en remontant ou en descendant la structure de parenté ; voir {@tutorial hist_rights}.

En termes pratiques, on garde dans l'arbre User une version horizontale des permissions des utilisateurs, et on stocke dans l'arbre Group les rôles stricts au minimum.

Etat de l'API

Cette API est voulue comme la plus simple et la plus minimaliste possible ; en effet, elle sera à réimplémenter sur toutes les instances différentes de sigma pour s'adapter aux structures de données des différentes écoles qui choisissent d'adopter sigma. On peut administrer des groupes depuis sigma, mais pour s'interfacer d'instances à instances seules deux fonctions sont indispensables ; peek et search.

Cette API, bien que relativement naïve, doit être capable de garder la syn,chronisation entre les deux arbres du LDAP et ainsi que les problèmes de récursion posées par le choix de la structure en admin descendant et membres montant.

Le détail de chaque fonction est disponible dans la documentation JSDOC : (User et Group).

La lutte contre les injections est faite au plus bas niveau possible en utilisant ldapEscape directement dans la classe Basics. En effet, les injections LDAP sont relativement voyantes et ne peuvent pas se faire avec des caractères usuels.