Problèmes d’accès et de visibilité des workflows AEM causés par la configuration de la liste de contrôle d’accès
Dans AEM, les utilisateurs peuvent perdre l’accès aux modèles de workflow, voir les workflows qu’ils ne doivent pas voir ou ne pas démarrer les workflows lorsque le contrôle d’accès est appliqué de manière incorrecte. Ces problèmes sont généralement causés par des listes de contrôle d’accès sur les nœuds d’exécution de workflow sous /var/workflow/models, des règles de refus trop larges, des restrictions de rep:glob manquantes ou des requêtes qui font toujours référence à des chemins d’accès de /etc/workflow/models hérités. L’appartenance à un groupe peut également déterminer si les utilisateurs voient uniquement leurs propres workflows ou tous les workflows. Corrigez la portée de la liste de contrôle d’accès, validez le chemin d’accès au modèle de workflow et passez en revue les autorisations en vigueur afin que la visibilité et l’exécution du workflow correspondent à l’accès prévu.
Description description
Environnement
- Adobe Experience Manager as a Cloud Service
- AEM Managed Services
- Logiciel On-Premise Adobe Experience Manager
Problème/Symptômes
- Les utilisateurs ne peuvent pas voir les modèles de workflow dans la console Workflow même s’ils appartiennent à
workflow-usersouworkflow-administrators. - Les utilisateurs voient toujours les modèles de workflow par défaut, tels que
InboxRequestaprès l’application des règles de refus. - Les utilisateurs peuvent déclencher des workflows qu’ils n’étaient pas censés utiliser.
- Les requêtes d’API échouent avec
400 Bad RequestetUnknown workflow model with id /etc/workflow/models/.... - Les modèles de workflow n’apparaissent pas dans les sélecteurs d’autorisations lorsque les administrateurs et administratrices tentent de les cibler dans les entrées de contrôle d’accès.
Cause
La visibilité et l’accès aux workflows sont contrôlés par des listes de contrôle d’accès sur les nœuds d’exécution des modèles de workflow sous /var/workflow/models. Des problèmes surviennent lorsque les listes de contrôle d’accès sont appliquées au mauvais emplacement, lorsque les restrictions de rep:glob sont manquantes ou trop larges, lorsque les règles de refus remplacent les règles d’autorisation prévues ou lorsque les requêtes de workflow font toujours référence à des /etc/workflow/models plutôt qu’au chemin d’exécution. Dans certains cas, les administrateurs s’attendent également à ce que les autorisations de workflow s’appliquent par modèle sans ajouter de restrictions basées sur le chemin.
Résolution resolution
Pour résoudre les problèmes d’accès et de visibilité des workflows causés par la configuration de la liste de contrôle d’accès :
- Déterminez quel problème d’accès aux workflows s’applique : visibilité manquante, visibilité involontaire, accès à l’exécution inattendu, échec de l’API ou échec de l’application ACL.
- Vérifiez que le modèle de workflow existe sous
/var/workflow/modelset pas uniquement sous/etc. - Vérifiez l’appartenance de l’utilisateur concerné au groupe et confirmez que l’utilisateur est affecté au groupe de workflow approprié pour le niveau d’accès requis.
- Recherchez les entrées de
jcr:readrefusées sur les chemins d’accès/var/workflow/modelsou parents et supprimez ou réduisez toute règle qui bloque involontairement le modèle de workflow requis. - Pour masquer un modèle de workflow spécifique à un groupe, ajoutez une entrée de contrôle d’accès de
jcr:readde refus sur les/var/workflow/modelsavec une restriction derep:globqui cible ce modèle de workflow, par exemple/InboxRequest. - Pour autoriser uniquement des modèles de workflow sélectionnés, appliquez des règles d’autorisation spécifiques avec les restrictions de
rep:globappropriées au lieu d’utiliser des autorisations générales. - Si une requête d’API échoue avec une erreur de modèle de workflow inconnu, mettez à jour la requête afin qu’elle pointe vers le chemin de modèle correct sous
/var/workflow/models. - Si les listes de contrôle d’accès sont appliquées par le biais du code, assurez-vous que le dossier cible existe avant d’appliquer la liste de contrôle d’accès afin que le déploiement n’échoue pas sur un chemin inexistant.
- Testez à nouveau en tant qu’utilisateur affecté et confirmez que les modèles de workflow prévus sont visibles, masqués ou exécutables comme prévu.
- Si le modèle de workflow existe sous
/var/workflow/models, que les groupes et listes de contrôle d’accès appropriés sont en place et que les utilisateurs ne peuvent toujours pas voir, démarrer ou restreindre les modèles de workflow prévus comme prévu, soumettez un dossier à l’assistance Adobe et incluez le chemin d’accès du modèle de workflow concerné, le groupe d’utilisateurs, le comportement attendu et toute erreur telle queUnknown workflow model with id /etc/workflow/models/....