Beaucoup d'annuaires ont des ACI compatibles avec celles de l'annuaire Sun (issu des sources de Netscape) :
- Sun / Oracle DSEE
- 389DS / Red Hat Directory Server
- Oracle OUD
- Sun OpenDS / Wren DS
- Forgerock OpenDJ
- Ping Directory.
Dans ces annuaires, les ACI peuvent être positionnées directement sur les objets eux-mêmes ou sur des objets plus proches de la racine.
Le mécanisme d'évaluation est globalement le suivant :
- On traverse le DIT depuis la racine de l'annuaire jusqu'à l'entrée que l'on tente d'accéder
- On collecte toutes les ACI rencontrées sur le chemin
- Les ACI collectées sont séparées en 2 paquets : DENY (refuser) et ALLOW (autoriser)
- Chaque paquet est trier pour que les ACI les plus simples/faciles/rapides sont évaluées en premier
- Le paquet "DENY" est évalué en premier. Si une ACI correspond, l'analyse s'arrête et la requête est refusée
- Si on arrive à la fin du paquet "DENY", on traite le paquet "ALLOW"
- Si une règle ACI ALLOW est trouvée, alors l'analyse s'arrête et l'accès est autorisé
- Si à la fin du traitement du paquet "ALLOW" aucune règle ne correspond, c'est un accès implicite "DENY". L'accès est refusé.
On peut donc en déduire les règles suivantes :
- le placement d'une ACI affecte uniquement son périmètre
- l'ordre d'évaluation est indéterminé. Une règle ACI plus "proche" d'une entrée n'est pas plus prioritaire que celle tout en haut du DIT
- le fait de placer une ACI proche d'une entrée permet seulement de s'assurer que l'ACI ne sera évaluée que lorsqu'on tente d'accéder à la donnée (amélioration des performances)
- par défaut, l'annuaire ne donne pas accès (au moins sur les nouveaux, type Forgerock, Ping). Les règles "DENY" doivent être très rares, et à manier avec précaution (puisqu'elles sont évaluées en premier).
Catégorie