Commande de listes de contrôle d’accès avec RepoInit dans Adobe Experience Manager LTS
Cet article décrit comment les modifications de l’ordre d’insertion des listes de contrôle d’accès avec RepoInit dans les versions LTS de Adobe Experience Manager (AEM) peuvent entraîner le remplacement des autorisations d’autorisation de groupe personnalisées par les règles de refus par défaut. Il décrit également les étapes à suivre pour garantir le bon ordre des listes de contrôle d’accès.
Description description
Environnement
- Adobe Experience Manager (AEM) 6.6.x (LTS SP2)
- Adobe Experience Manager (AEM) 6.5.x
Problème/Symptômes
Lorsque des groupes de création et des listes de contrôle d’accès personnalisés sont créés à l’aide de Sling RepoInit, l’ordre des entrées de contrôle d’accès (ACE) diffère entre AEM 6.5 et AEM LTS (6.6.x). Dans AEM 6.5, les entrées de contrôle d’accès personnalisées sont ajoutées après default/product entrées de contrôle d’accès sur les mêmes chemins. Dans AEM LTS, les listes de contrôle d’accès personnalisées sont insérées avant les entrées de contrôle d’accès par défaut. Par exemple, sur un chemin d’accès tel que /content/projects, un groupe personnalisé Autoriser l’entrée peut apparaître avant une entrée par défaut Refuser à tout le monde. Comme tous les utilisateurs sont membres du groupe Tout le monde, l’entrée Refuser peut remplacer les autorisations de groupe personnalisées, ce qui a une incidence sur les autorisations de suppression et d’écriture de ces groupes. Aucun message d’erreur n’est consigné, mais les autorisations effectives sont affectées.
Cause
Une modification de l’ordre d’insertion de la liste de contrôle d’accès RepoInit dans le LTS AEM entraîne l’insertion d’entrées Autoriser personnalisées avant les entrées Refuser par défaut, ce qui entraîne la substitution des autorisations personnalisées par les règles Refuser. La suppression et le rajout explicites des listes de contrôle d’accès via RepoInit garantissent le bon ordre.
Résolution resolution
Pour résoudre le problème, procédez comme suit :
-
Mettez à jour votre configuration RepoInit pour supprimer explicitement les listes de contrôle d’accès personnalisées existantes des chemins affectés avant de les ajouter à nouveau. Par exemple :
code language-none set ACL for remove * on /content/projects allow jcr:lockManagement, jcr:read, jcr:versionManagement, jcr:write on /content/projects end
Remplacez <custom-group> par le nom réel du groupe.
2. Déployez la configuration RepoInit mise à jour via votre pipeline de déploiement standard.
3. Après le déploiement, vérifiez que l’ordre des listes ACL est conforme aux attentes et que les autorisations de groupe personnalisées sont effectives. Vous pouvez utiliser CRXDE ou la console de sécurité d’AEM pour confirmer que les entrées Autoriser personnalisées apparaissent après les entrées Refuser par défaut pour les chemins d’accès appropriés.
4. Testez les opérations de suppression et d’écriture pour les groupes concernés afin de vous assurer que les autorisations sont correctes.
5. Évitez la réorganisation manuelle des listes de contrôle d’accès dans CRXDE pour les environnements de production, car il ne s’agit pas d’une solution évolutive ou prise en charge à long terme.