Principe général des AACLS
Les AACLS sont des règles de droits d’accès aux informations suivant des règles complexes à même de respecter des règles hiérarchiques et organisationnelles. Les droits abordés au travers des AACLS sont :
 lecture des attributs d’une entrée (r),
écriture sur des attributs, c’est-à-dire création, modification et suppression d’un attribut (w),
création d’une entrée (c),
suppression d’une entrée (d).
Par défaut, aucun droit n’est accordé par le serveur. Les ACLs classiques précisées sur le serveur AACLS ne font que restreindre les droits donnés par les AACLS.
Les AACLS considèrent six éléments principaux :
l’acteur de l’action qui est l’entrée utilisée pour accéder à l’annuaire,
la cible de l’action qui est l’entrée visée par l’action,
la liste des attributs concernés par l’autorisation,
le ou les droits, c’est alors une combinaison,
la relation qui lie l’acteur et la cible et qui donne accès à l’action, pour l’acteur, sur les attributs de la cible,
la base d’application de l’AACL (concernant la cible), c’est-à-dire le DN d’un des pères des entrées protégées, si l’AACL concerne tout l’annuaire, c’est le contexte de nommage de l’annuaire.
Les actions possibles sont :
lecture des attributs d’une entrée (opération ldapsearch) qui correspond au droit de lecture,
modification des attributs d’une entrée (opérations ldapmodify et ldapmodrdn) qui correspond au droit d’écriture,
ajout d’une entrée (opération ldapadd) qui correspond au droit de création,
suppression d’une entrée (opération ldapdelete) qui correspond au droit de suppression.
Chaque opération sur l’annuaire est décomposé de façon atomique : que ce soit une recherche ou une modification, chaque attribut va être vérifié de façon à déterminer si cette action est autorisé. Lors d’une recherche les différentes valeurs d’un attribut ne sont retournées que dans le cas où l’attribut de l’entrée cible considérée est lisible par l’acteur de l’action. Si l’entrée n’a pas d’attribut lisible, l’entrée n’est pas retournée du tout. La modification, quant à elle, nécessite que l’ensemble des attributs soient modifiables (en fonction des AACLS) pour que la modification soit opérée. Sinon elle est rejetée avec le code d’erreur XXXXX.
Le cas de la création et de la modification sont similaires à la modification, à la différence, que dans le cas général les attributs précisés se résument au mot clé « entry » qui fait référence à la cible dans son ensemble, et non aux attributs de celle-ci.
De façon à être le plus dynamique et facilement administrable, les AACLS sont des entrées de l’annuaire de données. Le mode de fonctionnement est simple :
lors du démarrage du serveur proxy AACLS, celui-ci charge les AACLS sur le serveur LDAP de données
par la suite tout accès au serveur AACLS utilise ces règles pré chargées afin d’effectuer le contrôle des données en effectuant des recherches sur l’annuaire LDAP de données pour évaluer les AACLS.
Le principal élément est la relation. Celle-ci se compose de différents éléments paramétrables :
des fonctions permettant de naviguer dans l’arborescence,
des remplacements afin d’utiliser le DN ou le RDN de l’acteur et de la cible,
l’utilisation de certains attributs comme source d’information.
Le fonctionnement de cette relation est lié à des ensembles : le résultat de chaque recherche est, en général, considéré comme un ensemble de DN. Dans le cas de l’évaluation d’une fonction contenant des paramètres eux-mêmes résultats d’autres fonctions, un produit cartésien est alors déterminé pour trouver chacune des évaluations à réaliser. Par exemple, l’expression suivante exprime l’utilisation de la fonction « f » sur deux ensembles :
f ( « uid=sebastien,ou=Personnes,dc=linagora,dc=com », « uid=pierre,ou=Personnes,dc=linagora,dc=com » , « givenName=S* », « givenName=P* » )
Cette relation va générer les évaluations suivantes :
f ( « uid= sebastien,ou=Personnes,dc=linagora,dc=com » , « givenName=S* » )
f ( « uid= pierre,ou=Personnes,dc=linagora,dc=com » , « givenName=S* » )
f ( « uid= sebastien,ou=Personnes,dc=linagora,dc=com » , « givenName=P* » )
f ( « uid= pierre,ou=Personnes,dc=linagora,dc=com » , « givenName=P* » )
L’évaluation de la relation est bonne si l’ensemble de résultat de l’opération la plus générale n’est pas vide.
Les fonctions disponibles prennent toutes deux arguments :
recherche dans tout le sous-arbre « search », dont le premier argument est la base de la recherche et le second est le filtre,
recherche au sein des fils direct de l’entrée « list », dont le premier argument est la base de la recherche et le second est le filtre,
lecture de l’entrée « read », dont le premier argument est la base de la recherche et le second est le filtre,
recherche des parents d’un DN « sup », dont le premier argument est le DN d’origine et le second est un nombre indiquant nombre de niveau à « remonter » ou 0 dans le cas où l’on souhaite l’ensemble des parents (l’entrée y compris),
un filtre précisant le critère pour déterminer le parent visé (en cours d’intégration),
fonction d’intersection et d’union des ensembles de résultats « and » et « or »,
recherche du premier parent satisfaisant un critère donné « fsup », dont le premier argument est le DN d’origine et le second est le critère
fonction de test de lecture, d’écriture, de création et de suppression au sein d’une AACL : « readable », « writable », « creatable », « deletable ».
Les remplacements effectués dans les chaînes de caractères sont :
« $authorDN » : qui est remplacé par le DN de l’acteur de l’action,
« $authorRDN » : qui est remplacé par le RDN de l’acteur de l’action,
« $targetDN » : qui est remplacé par le DN de l’entrée considérée (la cible),
« $targetRDN » : qui est remplacé par le RDN de l’entrée considérée (la cible),
« $fatherDN » : qui est remplacé par le DN du père direct de la cible (utilisé lors de la création d’une entrée),
« $fatherRDN » : qui est remplacé par le RDN du père direct de la cible (utilisé lors de la création d’une entrée).
|