Groupes d’utilisateurs fermés dans AEM closed-user-groups-in-aem
Présentation introduction
Depuis AEM 6.3, une nouvelle mise en œuvre des groupes fermés d’utilisateurs et d’utilisatrices est disponible pour résoudre les problèmes de performances, d’évolutivité et de sécurité liés à la mise en œuvre existante.
L’objectif de la nouvelle mise en œuvre est de couvrir les fonctionnalités existantes si nécessaire, tout en résolvant les problèmes et les limites de conception des versions plus anciennes. Le résultat est une nouvelle conception de CUG avec les caractéristiques suivantes :
- Séparation claire des éléments d’authentification et d’autorisation, qui peuvent être utilisés individuellement ou combinés ;
- Modèle d’autorisation dédié pour refléter l’accès en lecture restreint aux arborescences de CUG configurées sans interférer avec d’autres exigences de configuration et d’autorisation du contrôle d’accès ;
- Séparation entre la configuration de contrôle d’accès de l’accès en lecture restreint, nécessaire sur les instances de création, et l’évaluation des permissions souhaitée uniquement sur l’instance de publication
- Modification d’un accès en lecture limité sans transmission de privilèges ;
- Extension de type de nœud dédiée pour signaler l’exigence d’authentification ;
- Chemin de connexion facultatif associé à l’exigence d’authentification.
Nouvelle mise en œuvre d’un groupe personnalisé d’utilisateurs et d’utilisatrices the-new-custom-user-group-implementation
Un CUG, dans le contexte d’AEM, comprend les étapes suivantes :
- Restreignez l’accès en lecture sur l’arborescence qui doit être protégée et autorisez uniquement la lecture pour les principaux qui sont soit répertoriés avec une instance de CUG donnée, soit exclus de l’évaluation des CUG. Il s’agit de l’élément d’autorisation.
- Appliquez l’authentification sur une arborescence donnée et spécifiez éventuellement une page de connexion dédiée pour cette arborescence qui est ensuite exclue. Il s’agit de l’élément d’authentification.
La nouvelle mise en œuvre a été conçue pour distinguer les éléments d’authentification des éléments d’autorisation. Depuis AEM 6.3, il est possible de restreindre l’accès en lecture sans ajouter explicitement une exigence d’authentification. Par exemple, si une instance donnée nécessite une authentification complète ou si une arborescence donnée réside déjà dans une sous-arborescence qui nécessite déjà une authentification.
Aussi, une arborescence donnée peut être marquée par une exigence d’authentification sans modifier la configuration de permission effective. Les combinaisons et les résultats sont répertoriés dans la section Combiner des politiques CUG et l’exigence d’authentification.
du commerce électronique overview
Autorisation : limiter l’accès en lecture authorization-restricting-read-access
La fonctionnalité clé d’un CUG est de restreindre l’accès en lecture sur une arborescence donnée dans le référentiel de contenu pour tous à l’exception des principaux sélectionnés. Au lieu de manipuler à la volée le contenu du contrôle d’accès par défaut, la nouvelle mise en œuvre adopte une approche différente en définissant un type dédié de politique de contrôle d’accès qui représente un CUG.
Politique de contrôle d’accès pour les CUG access-control-policy-for-cug
Ce nouveau type de politique présente les caractéristiques suivantes :
- Politique de contrôle d’accès de org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy (définie par l’API Apache Jackrabbit)
- PrincipalSetPolicy accorde des privilèges à un ensemble modifiable d’entités de sécurité
- Les privilèges accordés et le champ d’application de la politique constituent des détails de mise en œuvre.
La mise en œuvre de PrincipalSetPolicy utilisée pour représenter les CUG définit en outre les points suivants :
- les politiques CUG accordent uniquement l’accès en lecture aux éléments JCR standard (par exemple, le contenu du contrôle d’accès est exclu) ;
- la portée est définie par le nœud à accès contrôlé qui détient la politique du CUG ;
- les politiques CUG peuvent être imbriquées, un CUG imbriqué démarre un nouveau CUG sans hériter de l’ensemble principal du CUG « parent » ;
- L’effet de la politique, si l’évaluation est activée, est hérité vers l’ensemble de la sous-arborescence jusqu’au CUG imbriqué suivant.
Ces politiques de CUG sont déployées sur les instances AEM par l’intermédiaire d’un module d’autorisation distinct appelé oak-authorization-cug. Ce module est fourni avec ses propres fonctions d’évaluation des permissions et de gestion du contrôle d’accès. En d’autres termes, la configuration par défaut d’AEM est livrée avec une configuration de référentiel de contenu Oak qui combine plusieurs mécanismes d’autorisation. Pour plus d’informations, consultez cette page sur la documentation Apache Oak.
Dans cette configuration composite, un nouveau CUG ne remplace pas le contenu de contrôle d’accès existant associé au nœud cible. Il s’agit plutôt d’un supplément qui peut également être supprimé ultérieurement sans affecter le contrôle d’accès d’origine qui, dans AEM, serait par défaut une liste de contrôle d’accès.
Contrairement à l’ancienne mise en œuvre, les nouvelles politiques de CUG sont toujours reconnues et traitées comme du contenu de contrôle d’accès. Cela signifie qu’elles sont créées et modifiées à l’aide de l’API de gestion du contrôle d’accès JCR. Pour plus d’informations, consultez Gestion des politiques de CUG.
Évaluation des autorisations des politiques CUG permission-evaluation-of-cug-policies
Outre la gestion de contrôle d’accès dédiée pour les CUG, le nouveau modèle d’autorisation vous permet d’activer de manière conditionnelle l’évaluation des permissions pour ses politiques. Cela vous permet de configurer des politiques de CUG dans un environnement d’évaluation et d’évaluer les permissions en vigueur une fois répliquées dans l’environnement de production.
L’évaluation des permissions pour les politiques de CUG et l’interaction avec le modèle d’autorisation par défaut ou tout modèle supplémentaire suit le modèle conçu pour les mécanismes d’autorisation multiples dans Apache Jackrabbit Oak. En d’autres termes, un ensemble donné d’autorisations est accordé si et uniquement si tous les modèles accordent l’accès. Consultez cette page pour plus de détails.
Les caractéristiques suivantes s’appliquent à l’évaluation des autorisations associée au modèle d’autorisation conçu pour gérer et évaluer les politiques CUG :
- Seules les autorisations de lecture pour les nœuds et propriétés normaux sont gérés, mais pas la lecture du contenu de contrôle d’accès.
- Il ne gère pas les autorisations d’écriture ni aucun type d’autorisation requis pour la modification du contenu JCR protégé (contrôle d’accès, informations sur le type de nœud, contrôle de version, verrouillage ou gestion des utilisateurs, entre autres). Ces autorisations ne sont pas affectées par une politique de CUG et ne seront pas évaluées par le modèle d’autorisation associé. Ces autorisations sont accordées en fonction des autres modèles configurés dans la configuration de sécurité.
L’effet d’une politique de CUG unique sur l’évaluation des permissions peut être résumé comme suit :
- L’accès en lecture est refusé pour tous, à l’exception des sujets contenant des entités de sécurité exclues ou des entités de sécurité répertoriées dans la stratégie.
- La politique prend effet sur le nœud dont l’accès est contrôlé et qui contient la politique et ses propriétés.
- L’effet est également hérité dans la hiérarchie, c’est-à-dire l’arborescence d’éléments définie par le nœud dont l’accès est contrôlé.
- Toutefois, elle n’affecte pas les frères ni les ancêtres du nœud dont l’accès est contrôlé.
- L’héritage d’un CUG donné s’arrête à un CUG imbriqué.
Bonnes pratiques best-practices
Les bonnes pratiques suivantes doivent tenir compte de la définition de l’accès en lecture limité par le biais de CUG :
-
Déterminez si le CUG dont vous avez besoin est destiné à limiter l’accès en lecture ou s’il correspond à une exigence d’authentification. Dans ce dernier cas, ou s’il vous faut les deux, consultez la section sur les bonnes pratiques pour plus d’informations sur l’exigence d’authentification
-
Créez un modèle de menace pour les données ou le contenu qui doivent être protégés afin d’identifier les limites de la menace et d’obtenir une vue claire de la sensibilité des données et des rôles associés à l’accès autorisé
-
Modélisez le contenu du référentiel et les CUG en gardant à l’esprit les aspects généraux liés aux autorisations et les bonnes pratiques :
- N’oubliez pas que l’autorisation de lecture n’est accordée que si un CUG donné et l’évaluation des autres modules déployés dans la configuration accordent à un sujet donné la possibilité de lire un élément de référentiel donné
- Évitez de créer des CUG redondants où l’accès en lecture est déjà restreint par d’autres modules d’autorisation.
- Le besoin excessif de CUG imbriqués peut potentiellement mettre en évidence des problèmes dans la conception du contenu.
- Le besoin excessif de CUG (par exemple, sur chaque page) peut indiquer la nécessité d’un modèle d’autorisation personnalisé potentiellement mieux adapté pour répondre aux besoins spécifiques en matière de sécurité de l’application et du contenu concerné.
-
Limitez les chemins pris en charge pour les politiques de CUG à un petit nombre d’arborescences dans le référentiel afin d’optimiser les performances. Par exemple, autorisez uniquement les CUG sous le nœud /content tel qu’établi par défaut depuis AEM 6.3.
-
Les politiques de CUG sont conçues pour autoriser l’accès en lecture à un petit ensemble d’entités de sécurité. La nécessité d’un grand nombre d’entités peut mettre en évidence des problèmes liés à la conception du contenu ou de l’application et devrait être reconsidérée.
Authentification : définir les exigences d’authentification authentication-defining-the-auth-requirement
Les composants liés à l’authentification de la fonction CUG vous permettent de marquer les arborescences nécessitant une authentification et éventuellement de spécifier une page de connexion dédiée. Par rapport à la version précédente, la nouvelle mise en œuvre vous permet de marquer les arborescences nécessitant une authentification dans le référentiel de contenu. Elle active également de manière conditionnelle la synchronisation avec le Sling org.apache.sling.api.auth.Authenticator
responsable de l’application de l’exigence et de la redirection vers une ressource de connexion.
Ces exigences sont enregistrées auprès de l’authentificateur par un service OSGi qui fournit le sling.auth.requirements
propriété d’enregistrement. Ces propriétés sont ensuite utilisées pour étendre les exigences d’authentification de façon dynamique. Pour plus d’informations, voir la documentation Sling.
Définir les exigences d’authentification avec un type de mixin dédié defining-the-authentication-requirement-with-a-dedicated-mixin-type
Pour des raisons de sécurité, la nouvelle mise en œuvre remplace l’utilisation d’une propriété JCR résiduelle par un type de mixin dédié appelé . granite:AuthenticationRequired
, qui définit une propriété facultative unique de type CHAÎNE pour le chemin de connexion granite:loginPath
. Seules les modifications de contenu liées à ce type de mixin entraînent une mise à jour des exigences enregistrées auprès de l’authentificateur Apache Sling. Les modifications sont suivies lors de la persistance de toute modification provisoire et nécessitent donc un appel javax.jcr.Session.save()
pour prendre effet.
Il en va de même pour la propriété granite:loginPath
. Elle n’est respectée que si elle est définie par le type de mixin lié à l’exigence d’authentification. L’ajout d’une propriété résiduelle portant ce nom précis à un nœud JCR non structuré n’affiche pas l’effet souhaité et la propriété est ignorée par le gestionnaire responsable de la mise à jour de l’enregistrement OSGi.
Enregistrer l’exigence d’authentification et le chemin de connexion avec Sling Authenticator registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator
Comme ce type d’exigence d’authentification doit être limité à certains modes d’exécution et à un petit sous-ensemble d’arborescences dans le référentiel de contenu, le suivi du type de mixin de l’exigence et des propriétés de chemin de connexion est conditionnel. Il est également lié à une configuration correspondante qui définit les chemins pris en charge (voir la section Options de configuration ci-dessous). Par conséquent, seules les modifications dans la portée de ces chemins pris en charge déclenchent une mise à jour de l’enregistrement OSGi. Dans les autres cas, le type de mixin et la propriété sont tous deux ignorés.
Par défaut, AEM utilise désormais cette configuration en permettant de placer le mixin en mode d’exécution de création, mais en ne le faisant prendre effet que lors de la réplication vers l’instance de publication. Consultez cette page pour plus d’informations sur la façon dont Sling impose l’exigence d’authentification.
Ajout de granite:AuthenticationRequired
Le type de mixin dans les chemins pris en charge configurés entraîne la mise à jour de l’enregistrement dans OSGi du gestionnaire responsable avec une nouvelle entrée contenant le sling.auth.requirements
propriété . Si une exigence d’authentification donnée spécifie la variable facultatif granite:loginPath
, la valeur est également enregistrée auprès de l’authentificateur avec un préfixe « - » à exclure de l’exigence d’authentification.
Évaluation et héritage de l’exigence d’authentification evaluation-and-inheritance-of-the-authentication-requirement
Les exigences d’authentification Apache Sling sont héritées dans la hiérarchie de page ou de nœud. Les détails même de l’héritage et l’évaluation des exigences d’authentification telles que l’ordre et la priorité considérés comme des détails d’implémentation et ne seront pas documentés dans cet article.
Évaluer un chemin de connexion evaluation-of-login-path
L’évaluation du chemin de connexion et de la redirection vers la ressource correspondante lors de l’authentification est un détail de mise en œuvre du gestionnaire d’authentification du sélecteur de connexion Granite d’Adobe ( com.day.cq.auth.impl.LoginSelectorHandler
), qui est un gestionnaire d’authentification Apache Sling configuré avec AEM par défaut.
À l'appel AuthenticationHandler.requestCredentials
ce gestionnaire tente de déterminer la page de connexion de mappage vers laquelle l’utilisateur est redirigé. Cela inclut les étapes suivantes :
-
Faites la distinction entre un mot de passe expiré et la nécessité de vous connecter régulièrement comme raison de la redirection ;
-
S’il s’agit d’une connexion régulière, teste si un chemin de connexion peut être obtenu dans l’ordre suivant :
- À partir du LoginPathProvider mis en œuvre par le nouveau
com.adobe.granite.auth.requirement.impl.RequirementService
- À partir de l’ancienne mise en œuvre CUG obsolète
- À partir des mises en correspondance de page de connexion, telles que définies avec
LoginSelectorHandler
- Enfin, le retour vers la page de connexion par défaut, telle qu’elle est définie avec
LoginSelectorHandler
.
- À partir du LoginPathProvider mis en œuvre par le nouveau
-
Lorsqu’un chemin de connexion valide est obtenu par les appels répertoriés ci-dessus, la requête de l’utilisateur est redirigée vers cette page.
Cette documentation traite de l’évaluation du chemin de connexion tel qu’il est exposé par l’interface LoginPathProvider
interne. L’implémentation livrée depuis AEM 6.3 se comporte comme suit :
-
L’enregistrement des chemins de connexion dépend de la distinction entre le mot de passe expiré et la nécessité d’une connexion régulière comme raison de la redirection.
-
En cas de connexion régulière, teste si un chemin de connexion peut être obtenu dans l’ordre suivant :
- À partir du
LoginPathProvider
mis en œuvre par le nouveaucom.adobe.granite.auth.requirement.impl.RequirementService
- À partir de l’ancienne mise en œuvre CUG obsolète
- À partir des mises en correspondance de page de connexion, telles que définies avec
LoginSelectorHandler
- Enfin, le retour vers la page de connexion par défaut, telle qu’elle est définie avec
LoginSelectorHandler
.
- À partir du
-
Lorsqu’un chemin de connexion valide est obtenu par les appels répertoriés ci-dessus, la requête de l’utilisateur est redirigée vers cette page.
Le LoginPathProvider
, tel qu’il est mis en œuvre par la nouvelle prise en charge d’exigence d’authentification dans Granite, expose les chemins de connexion Granite tels que définis par les propriétés granite:loginPath
, qui à leur tour sont définis par le type de mixin comme décrit ci-dessus. Le mappage du chemin de ressource contenant le chemin de connexion et la valeur de propriété elle-même est conservé en mémoire et est évalué afin de trouver un chemin de connexion approprié pour les autres nœuds de la hiérarchie.
Bonnes pratiques best-practices-1
Les bonnes pratiques suivantes doivent être prises en compte lors de la définition des exigences d’authentification :
-
Évitez d’imbriquer les exigences d’authentification : le fait de placer un marqueur d’exigence d’authentification unique au début d’une arborescence doit être suffisant et hérité par l’ensemble de la sous-arborescence définie par le nœud cible. Tout exigence supplémentaire d’authentification dans cette arborescence doit être considérée comme redondante et peut entraîner des problèmes de performances lors de l’évaluation de l’exigence d’authentification dans Apache Sling. En séparant les zones de CUG d’autorisation et d’authentification, il est possible de restreindre l’accès en lecture par CUG ou par d’autres types de politiques tout en appliquant l’authentification à l’ensemble de l’arborescence.
-
Modélisez le contenu de référentiel, de telle façon que les exigences d’authentification s’appliquent à l’arborescence entière sans avoir à exclure à nouveau de l’exigence les sous-arborescences imbriquées.
-
Pour éviter de spécifier puis d’enregistrer des chemins de connexion redondants :
- Utilisez l’héritage et évitez de définir des chemins de connexion imbriqués.
- ne définissez pas le chemin de connexion facultatif sur une valeur correspondant à la valeur par défaut ou à une valeur héritée ;
- Les développeurs d’applications doivent identifier les mises en correspondance de connexion qui doivent être configurées dans les fonctions de chemin de connexion globales (par défaut et mise en correspondance) associées à
LoginSelectorHandler
.
Représentation dans le référentiel representation-in-the-repository
Représentation de la politique CUG dans le référentiel cug-policy-representation-in-the-repository
La documentation Oak couvre la façon dont les nouvelles politiques de CUG sont reflétées dans le contenu du référentiel. Pour plus d’informations, consultez cette page.
Exigences d’authentification dans le référentiel authentication-requirement-in-the-repository
Le besoin d’une exigence d’authentification distincte est reflété dans le contenu du référentiel avec un type de nœud mixin dédié placé au niveau du nœud cible. Le type mixin définit une propriété facultative pour spécifier une page de connexion dédiée pour l’arborescence définie par le nœud cible.
La page associée au chemin de connexion peut être placée à l’intérieur ou à l’extérieur de cette arborescence. Il est exclu de l’exigence d’authentification.
[granite:AuthenticationRequired]
mixin
- granite:loginPath (STRING)
Gérer les politiques CUG et les exigences d’authentification managing-cug-policies-and-authentication-requirement
Gérer les politiques CUG managing-cug-policies
Le nouveau type de politiques de contrôle d’accès destiné à limiter l’accès en lecture pour un CUG est géré à l’aide de l’API de gestion du contrôle d’accès JCR et suit les mécanismes décrits par la Spécification JCR 2.0.
Définir une nouvelle politique CUG set-a-new-cug-policy
Code pour appliquer une nouvelle politique de CUG à un nœud qui n’avait pas de CUG défini auparavant. Veuillez noter que getApplicablePolicies
renvoie uniquement les nouvelles politiques qui n’ont pas encore été définies. À la fin, la politique doit être réécrite et les modifications doivent être conservées.
String path = [...] // needs to be a supported, absolute path
Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]
AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;
AccessControlPolicyIterator it = acMgr.getApplicablePolicies(path);
while (it.hasNext()) {
AccessControlPolicy policy = it.nextAccessControlPolicy();
if (policy instanceof PrincipalSetPolicy) {
cugPolicy = (PrincipalSetPolicy) policy;
break;
}
}
if (cugPolicy == null) {
log.debug("no applicable policy"); // path not supported or no applicable policy (for example,
// the policy was set before)
return;
}
cugPolicy.addPrincipals(toAdd1, toAdd2);
cugPolicy.removePrincipals(toRemove));
acMgr.setPolicy(path, cugPolicy); // as of this step the policy can be edited/removed
session.save();
Modifier une politique CUG existante edit-an-existing-cug-policy
Les étapes suivantes sont nécessaires pour modifier une politique de CUG existante. La politique modifiée doit être réécrite et les modifications doivent être conservées à l’aide de javax.jcr.Session.save()
.
String path = [...] // needs to be a supported, absolute path
Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]
AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;
for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
if (policy instanceof PrincipalSetPolicy) {
cugPolicy = (PrincipalSetPolicy) policy;
break;
}
}
if (cugPolicy == null) {
log.debug("no policy to edit"); // path not supported or policy not set before
return;
}
if (cugPolicy.addPrincipals(toAdd1, toAdd2) || cugPolicy.removePrincipals(toRemove)) {
acMgr.setPolicy(path, cugPolicy);
session.save();
} else {
log.debug("cug policy not modified");
}
Récupérer des politiques CUG efficaces retrieve-effective-cug-policies
La gestion du contrôle d’accès JCR définit une méthode du meilleur effort pour récupérer les politiques qui prennent effet à un chemin donné. Étant donné que l’évaluation des politiques de CUG est conditionnelle et dépend de la configuration correspondante à activer, l’appel de getEffectivePolicies
est un moyen pratique pour vérifier si une politique de CUG donnée prend effet dans une configuration spécifique.
getEffectivePolicies
et l’exemple de code suivant qui remonte la hiérarchie pour déterminer si un chemin donné fait déjà partie d’un CUG existant.String path = [...] // needs to be a supported, absolute path
AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;
// log an debug message of all CUG policies that take effect at the given path
// there could be zero, one or many (creating nested CUGs is possible)
for (AccessControlPolicy policy : acMgr.getEffectivePolicies(path) {
if (policy instanceof PrincipalSetPolicy) {
String policyPath = "-";
if (policy instanceof JackrabbitAccessControlPolicy) {
policyPath = ((JackrabbitAccessControlPolicy) policy).getPath();
}
log.debug("Found effective CUG for path '{}' at '{}', path, policyPath);
}
}
Récupérer les politiques CUG héritées retrieve-inherited-cug-policies
Recherche de tous les CUG imbriqués qui ont été définis à un chemin donné, qu’ils soient ou non effectifs. Pour plus d’informations, consultez la section Options de configuration.
String path = [...]
List<AccessControlPolicy> cugPolicies = new ArrayList<AccessControlPolicy>();
while (isSupportedPath(path)) {
for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
if (policy instanceof PrincipalSetPolicy) {
cugPolicies.add(policy);
}
}
path = (PathUtils.denotesRoot(path)) ? null : PathUtils.getAncestorPath(path, 1);
}
Gérer les politiques CUG par principal managing-cug-policies-by-pincipal
Les extensions définies par JackrabbitAccessControlManager
qui vous permettent de modifier les politiques de contrôle d’accès par entité de sécurité ne sont pas mises en œuvre avec la gestion de contrôle d’accès CUG, comme par définition une politique de CUG affecte toujours toutes les entités de sécurité : celles répertoriées avec la PrincipalSetPolicy
reçoivent un accès en lecture tandis que tous les autres principaux ne peuvent pas lire le contenu dans l’arborescence définie par le nœud cible.
Les méthodes correspondantes renvoient toujours un tableau de politiques vide mais n’entraîneront pas d’exceptions.
Gérer les exigences d’authentification managing-the-authentication-requirement
La création, la modification ou la suppression de nouvelles exigences d’authentification s’effectuent en modifiant le type de nœud effectif du nœud cible. La propriété de chemin de connexion facultatif peut ensuite être écrite à l’aide de l’API JCR.
RequirementHandler
a été configuré et que la cible figure dans les arborescences définies par les chemins pris en charge (voir la section Options de configuration).Ajouter une nouvelle exigence d’authentification adding-a-new-auth-requirement
Les étapes de création d’une exigence d’authentification sont détaillées ci-dessous. L’exigence n’est enregistrée auprès de l’authentificateur Apache Sling que si RequirementHandler
a été configuré pour l’arborescence contenant le nœud cible.
Node targetNode = [...]
targetNode.addMixin("granite:AuthenticationRequired");
session.save();
Ajouter une nouvelle exigence d’authentification avec un chemin de connexion add-a-new-auth-requirement-with-login-path
Procédure à suivre pour créer une exigence d’authentification incluant un chemin de connexion. L’exigence et l’exclusion du chemin de connexion ne sont enregistrées auprès de l’authentificateur Apache Sling que si la variable RequirementHandler
a été configuré pour l’arborescence contenant le nœud cible.
Node targetNode = [...]
String loginPath = [...] // STRING property
Node targetNode = session.getNode(path);
targetNode.addMixin("granite:AuthenticationRequired");
targetNode.setProperty("granite:loginPath", loginPath);
session.save();
Modifier un chemin de connexion existant modify-an-existing-login-path
Les étapes à suivre pour modifier un chemin de connexion existant sont détaillées ci-dessous. La modification n’est enregistrée auprès de l’authentificateur Apache Sling que si RequirementHandler
a été configuré pour l’arborescence contenant le nœud cible. La valeur précédente du chemin de connexion est supprimée de l’enregistrement. L’exigence d’authentification associée au nœud cible n’est pas affectée par cette modification.
Node targetNode = [...]
String newLoginPath = [...] // STRING property
if (targetNode.isNodeType("granite:AuthenticationRequired")) {
targetNode.setProperty("granite:loginPath", newLoginPath);
session.save();
} else {
log.debug("cannot modify login path property; mixin type missing");
}
Supprimer un chemin de connexion existant remove-an-existing-login-path
Procédure pour supprimer un chemin de connexion existant. L’annulation de l’enregistrement de l’entrée de chemin de connexion auprès de l’authentificateur Apache Sling n’est effective que si RequirementHandler
a été configuré pour l’arborescence contenant le nœud cible. L’exigence d’authentification associée au nœud cible n’est pas affectée.
Node targetNode = [...]
if (targetNode.hasProperty("granite:loginPath") &&
targetNode.isNodeType("granite:AuthenticationRequired")) {
targetNode.setProperty("granite:loginPath", null);
session.save();
} else {
log.debug("cannot remove login path property; mixin type missing");
}
Vous pouvez également utiliser la méthode ci-dessous pour atteindre le même objectif :
String path = [...] // absolute path to target node
String propertyPath = PathUtils.concat(path, "granite:loginPath");
if (session.propertyExists(propertyPath)) {
session.getProperty(propertyPath).remove();
// or: session.removeItem(propertyPath);
session.save();
}
Supprimer une exigence d’authentification remove-an-auth-requirement
Procédure pour supprimer une exigence d’authentification existante. L’annulation de l’enregistrement de l’exigence auprès de l’authentificateur Apache Sling n’est effective que si RequirementHandler
a été configuré pour l’arborescence contenant le nœud cible.
Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");
session.save();
Récupération des exigences d’authentification effectives retrieve-effective-auth-requirements
Il n’existe aucune API publique dédiée pour lire toutes les exigences d’authentification effectives enregistrées auprès de l’authentificateur Apache Sling. Toutefois, la liste est exposée dans la console système à l’adresse https://<serveraddress>:<serverport>/system/console/slingauth
dans la section « Configuration des exigences d’authentification ».
L’image suivante illustre les exigences d’authentification d’une instance de publication AEM avec du contenu de démonstration. Le chemin en surbrillance de la page de communauté illustre comment une exigence ajoutée par l’implémentation décrite dans ce document est reflétée dans l’authentificateur Apache Sling.
Récupération du chemin de connexion effectif retrieve-the-effective-login-path
Il n’existe actuellement aucune API publique pour récupérer le chemin de connexion qui prend effet lors d’un accès anonyme à une ressource nécessitant une authentification. Consultez la section Évaluation du chemin de connexion pour plus de détails d’implémentation sur la récupération du chemin de connexion.
Notez cependant qu’outre les chemins de connexion définis avec cette fonctionnalité, il existe d’autres moyens de spécifier la redirection vers la connexion, qui doivent être pris en compte lors de la conception du modèle de contenu et des exigences d’authentification d’une installation AEM donnée.
Récupérer l’exigence d’authentification héritée retrieve-the-inherited-auth-requirement
Comme pour le chemin de connexion, il n’existe aucune API publique pour récupérer les exigences d’authentification héritées définies dans le contenu. L’exemple suivant illustre comment répertorier toutes les exigences d’authentification qui ont été définies avec une hiérarchie donnée, qu’elles prennent ou non effet. Pour plus d’informations, consultez Options de configuration.
String path = [...]
Node node = session.getNode(path);
Map<String, String> authRequirements = new ArrayList<String, String>();
while (isSupported(node)) {
if (node.isNodeType("granite:AuthenticationRequired")) {
String loginPath = (node.hasProperty("granite:loginPath") ?
node.getProperty("granite:loginPath").getString() :
"";
authRequirements.put(node.getPath(), loginPath);
node = node.getParent();
}
}
Combinaison des politiques CUG et de l’exigence d’authentification combining-cug-policies-and-the-authentication-requirement
Le tableau suivant répertorie les combinaisons valides de politiques CUG et les exigences d’authentification d’une instance AEM dont les deux modules sont activés via la configuration.
Composants et configuration OSGi osgi-components-and-configuration
Cette section donne une vue d’ensemble des composants OSGi et de chaque option de configuration introduite avec la nouvelle mise en œuvre de CUG.
Consultez également la documentation relative à la mise en correspondance de CUG pour une mise en correspondance complète des options de configuration entre l’ancienne et la nouvelle mise en œuvre.
Autorisation : installation et configuration authorization-setup-and-configuration
Les nouveaux composants liés à l’autorisation figurent dans le lot Oak CUG Authorization (org.apache.jackrabbit.oak-authorization-cug
), qui fait partie de l’installation par défaut d’AEM. Le lot définit un modèle d’autorisation séparé destiné à être déployé comme un autre moyen de gérer l’accès en lecture.
Configuration de l’autorisation de CUG setting-up-cug-authorization
L’installation de l’autorisation de CUG est décrite en détail dans la documentation Apache appropriée. Par défaut, l’autorisation de CUG est déployée dans tous les modes d’exécution d’AEM. Les instructions étape par étape peuvent également être suivies pour désactiver l’autorisation de CUG dans les installations qui nécessitent une configuration d’autorisation différente.
Configuration du filtre de référent configuring-the-referrer-filter
Vous devez également configurer le Filtre Référent Sling avec tous les noms d’hôtes pouvant être utilisés pour accéder à AEM ; par exemple, par l’intermédiaire du réseau CDN, de la répartition de charge et de n’importe quel autre.
Si le filtre de référent n’est pas configuré, des erreurs, similaires à celles-ci, s’affichent lorsqu’un utilisateur ou une utilisatrice tente de se connecter à un site CUG :
31.01.2017 13:49:42.321 *INFO* [qtp1263731568-346] org.apache.sling.security.impl.ReferrerFilter Rejected referrer header for POST request to /libs/granite/core/content/login.html/j_security_check : https://hostname/libs/granite/core/content/login.html?resource=%2Fcontent%2Fgeometrixx%2Fen%2Ftest-site%2Ftest-page.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown
Caractéristiques des composants OSGi characteristics-of-osgi-components
Les deux composants OSGi suivants ont été introduits pour définir les exigences d’authentification et spécifier des chemins de connexion dédiés :
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
Options de configuration configuration-options
Les principales options de configuration sont :
cugSupportedPaths
: spécifiez les sous-arborescences pouvant contenir des CUG. Aucune valeur n’est définie par défaut.cugEnabled
: option de configuration pour activer l’évaluation des permissions pour les politiques de CUG actuelles.
Les options de configuration disponibles associées au module d’autorisation CUG sont répertoriées et décrites plus en détail dans la documentation Apache Oak.
Exclusion des principaux de l’évaluation CUG excluding-principals-from-cug-evaluation
L’exemption de principaux de l’évaluation de CUG a été adoptée à partir de l’ancienne mise en œuvre. La nouvelle autorisation de CUG couvre cette fonction avec une interface dédiée nommée CugExclude. Apache Jackrabbit Oak 1.4 est fourni avec une implémentation par défaut qui exclut un ensemble fixe d’entités de sécurité et une implémentation étendue qui vous permet de configurer des noms d’entités de sécurité individuels. Ce dernier est configuré dans les instances de publication AEM.
La valeur par défaut depuis AEM 6.3 empêche les principaux suivants d’être affectés par les politiques CUG :
- principaux administratifs (utilisateur administrateur ou utilisatrice administratrice, groupe d’administrateurs ou d’administratrices) ;
- principaux utilisateurs du service
- principal du système interne du référentiel
Pour plus d’informations, consultez le tableau dans la section Configuration par défaut depuis AEM 6.3 ci-dessous.
L’exclusion du groupe d’administrateurs peut être modifiée ou augmentée dans la console système dans la section de configuration de Liste d’exclusion de CUG Apache Jackrabbit Oak.
Sinon, il est possible de fournir et de déployer une mise en œuvre personnalisée de l’interface CugExclude pour ajuster l’ensemble des principaux exclus en cas de besoins spécifiques. Consultez la documentation relative à l’aspect enfichable des CUG pour plus d’informations et pour obtenir un exemple de mise en œuvre.
Authentification : installation et configuration authentication-setup-and-configuration
Les nouveaux composants liés à l’authentification figurent dans le lot Gestionnaire d’authentification Adobe Granite (com.adobe.granite.auth.authhandler
version 5.6.48). Ce lot fait partie de l’installation par défaut d’AEM.
Pour installer l’exigence d’authentification de remplacement pour la prise en charge de CUG obsolète, certains composants OSGi doivent être présents et actifs dans une configuration d’AEM donnée. Pour plus d’informations, voir Caractéristiques des composants OSGi ci-dessous.
Caractéristiques des composants OSGi
Les deux composants OSGi suivants ont été introduits pour définir les exigences d’authentification et spécifier des chemins de connexion dédiés :
com.adobe.granite.auth.requirement.impl.RequirementService
com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
com.adobe.granite.auth.requirement.impl.RequirementService
com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
RequirementHandler
qui met à jour les exigences d’authentification Apache Sling et l’exclusion correspondante pour les chemins de connexion associés.supportedPaths
ConfigurationPolicy.REQUIRE
Options de configuration configuration-options-1
Les parties liées à l’authentification de la réécriture de CUG ne sont accompagnées que d’une seule option de configuration associée au gestionnaire d’exigence d’authentification et de chemin de connexion Adobe Granite :
« Gestionnaire d’exigence d’authentification et de chemin de connexion »
Configuration par défaut depuis AEM 6.3 default-configuration-since-aem
Les nouvelles installations d’AEM utilisent par défaut les nouvelles mises en œuvre à la fois pour les composants liés à l’autorisation et à l’authentification de la fonction CUG. L’ancienne implémentation « Prise en charge des groupes d’utilisateurs fermés (CUG) par Adobe Granite » a été abandonnée et sera désactivée dans toutes les installations d’AEM. Les nouvelles mises en œuvre seront plutôt activées comme suit :
Instances de création author-instances
/content
Instances de publication publish-instances
/content
Session.save()
./content
granite:AuthenticationRequired
le type de mixin prend effet ci-dessous /content
dès le Session.save()
. L’authentificateur Sling est mis à jour. L’ajout du type de mixin en dehors des chemins pris en charge est ignoré.Désactivation de l’autorisation du CUG et de l’exigence d’authentification disabling-cug-authorization-and-authentication-requirement
La nouvelle implémentation peut être complètement désactivée dans le cas où une installation donnée n’utilise pas de CUG ou utilise d’autres moyens d’authentification et d’autorisation.
Désactiver l’autorisation du CUG disable-cug-authorization
Consultez la documentation Possibilité de branchement CUG pour plus de détails sur la suppression du modèle d’autorisation du CUG de la configuration d’autorisation composite.
Désactiver l’exigence d’authentification disable-the-authentication-requirement
Pour désactiver la prise en charge de l’exigence d’authentification fournie par le granite.auth.authhandler
, il suffit de supprimer la configuration associée à Gestionnaire d’exigence d’authentification et de chemin de connexion Adobe Granite.
Interactions avec d’autres modules interaction-with-other-modules
API Apache Jackrabbit apache-jackrabbit-api
Afin de refléter le nouveau type de politique de contrôle d’accès utilisé par le modèle d’autorisation des CUG, l’API définie par Apache Jackrabbit a été étendue. Ainsi, la version 2.11.0 du module jackrabbit-api
définit une nouvelle interface appelée org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy
, qui s’étend à partir de javax.jcr.security.AccessControlPolicy
.
Apache Jackrabbit FileVault apache-jackrabbit-filevault
Le mécanisme d’importation d’Apache Jackrabbit FileVault a été adapté pour traiter les politiques de contrôle d’accès de type PrincipalSetPolicy
.
Distribution de contenu Apache Sling apache-sling-content-distribution
Voir ci-dessus la section Apache Jackrabbit FileVault.
Réplication Adobe Granite adobe-granite-replication
Le module de réplication a été légèrement ajusté pour pouvoir répliquer les politiques CUG entre différentes instances AEM :
-
DurboImportConfiguration.isImportAcl()
est interprété littéralement et affecte uniquement les politiques de contrôle d’accès mettant en œuvrejavax.jcr.security.AccessControlList
. -
DurboImportTransformer
respecte uniquement cette configuration pour les vraies listes de contrôle d’accès. -
D’autres politiques telles que les instances de
org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy
créées par le modèle d’autorisation des CUG sont toujours répliquées, et l’option de configurationDurboImportConfiguration.isImportAcl
() est ignorée.
Il existe une limite de réplication des politiques de CUG. Si une politique de CUG donnée est supprimée sans supprimer le type de nœud de mixin rep:CugMixin,
correspondant, la suppression n’est pas répercutée lors de la réplication. Ce problème a été corrigé en supprimant toujours le mixin lors de la suppression d’une politique. La limitation peut néanmoins apparaître si le type de mixin est ajouté manuellement.
Gestionnaire d’authentification Adobe Granite adobe-granite-authentication-handler
Le gestionnaire d’authentification Adobe Granite HTTP Header Authentication Handler fourni avec le lot com.adobe.granite.auth.authhandler
contient une référence à l’interface CugSupport
définie par le même module. Il est utilisé pour calculer le domaine dans certains cas, en se repliant sur le domaine configuré avec le gestionnaire.
Cela a été réglé de façon à rendre la référence à CugSupport
facultative pour assurer une compatibilité ascendante maximale si une configuration donnée décide de réactiver cette mise en œuvre obsolète. Pour les installations recourant à cette mise en œuvre, le domaine n’est pas extrait à partir de la mise en œuvre CUG, mais s’affiche toujours tel que défini auprès du gestionnaire d’authentification Adobe Granite HTTP Header Authentication Handler.
auth.http.nologin
) activée.AEM LiveCopy aem-livecopy
La configuration des CUG avec LiveCopy est représentée dans le référentiel par l’ajout d’un nœud et d’une propriété supplémentaires comme suit :
/content/we-retail/us/en/blueprint/rep:cugPolicy
/content/we-retail/us/en/LiveCopy@granite:loginPath
Ces deux éléments sont créés sous cq:Page
. Avec la conception actuelle, le MSM ne gère que les nœuds et les propriétés sous le nœud cq:PageContent
(jcr:content
).
Par conséquent, les groupes CUG ne peuvent pas être déployés sur des Live Copies à partir de plans directeurs. Tenez-en compte lors de la configuration de la Live Copy.
Modifications de la nouvelle mise en œuvre du CUG changes-with-the-new-cug-implementation
Cette section est destinée à présenter les modifications apportées à la fonction CUG et à comparer l’ancienne et la nouvelle mise en œuvre. Il répertorie les modifications affectant la façon dont la prise en charge des CUG est configurée et décrit comment et par qui les CUG sont gérés dans le contenu du référentiel.
Différences dans l’installation et la configuration des CUG differences-in-cug-setup-and-configuration
Le composant OSGi obsolète Prise en charge des groupes d’utilisateurs fermés (CUG) Adobe Granite (com.day.cq.auth.impl.cug.CugSupportImpl
) a été remplacé par de nouveaux composants de façon à gérer séparément les composants liés à l’autorisation et à l’authentification de la fonctionnalité de CUG précédente.
Différences dans la gestion des CUG au sein du référentiel de contenu differences-in-managing-cugs-in-the-repository-content
Les sections suivantes décrivent les différences entre l’ancienne et la nouvelle mise en œuvre du point de vue de l’implémentation et de la sécurité. Bien que la nouvelle mise en œuvre vise à fournir les mêmes fonctionnalités, il y a des changements subtils qu’il est important de connaître avec le nouveau CUG.
Différences quant à l’autorisation differences-with-regards-to-authorization
Les principales différences du point de vue des autorisations sont résumées dans la liste ci-dessous :
Contenu de contrôle d’accès dédié aux CUG
Dans l’ancienne mise en œuvre, le modèle d’autorisation par défaut était utilisé pour manipuler les politiques de liste de contrôle d’accès sur l’instance de publication, remplaçant tous les ACE existants par la configuration requise par le CUG. Cela a été déclenché par l’écriture de propriétés JCR résiduelles régulières qui ont été interprétées lors de la publication.
Avec la nouvelle mise en œuvre, l’installation du contrôle d’accès du modèle d’autorisation par défaut n’est pas affectée par tout CUG qui est créé, modifié ou supprimé. À la place, un nouveau type de politique nommé PrincipalSetPolicy
est appliqué en tant que contenu de contrôle d’accès supplémentaire sur le nœud cible. Cette politique supplémentaire est située en tant qu’enfant du nœud cible et doit être une sœur du nœud de politique par défaut, le cas échéant.
Modifier les politiques CUG dans la gestion du contrôle d’accès
Cette transition des propriétés JCR résiduelles vers une politique de contrôle d’accès dédiée a un impact sur les permissions requises pour créer ou modifier le composant d’autorisation de la fonction CUG. Dans la mesure où cette opération est considérée comme une modification du contenu de contrôle d’accès, elle requiert que les privilèges jcr:readAccessControl
et jcr:modifyAccessControl
soient écrits dans le référentiel. Par conséquent, seuls les auteurs et autrices de contenu autorisés à modifier le contenu de contrôle d’accès d’une page peuvent installer ou modifier ce contenu. Cela contraste avec l’ancienne mise en œuvre où la possibilité d’écrire des propriétés JCR standard suffisait, entraînant la réaffectation des privilèges.
Nœud cible défini par la politique
Les politiques CUG sont créées au niveau du nœud JCR définissant la sous-arborescence dont l’accès en lecture est limitée. Il s’agit probablement d’une page AEM au cas où le CUG devrait affecter l’arborescence entière.
Le placement de la politique de CUG uniquement au niveau du nœud jcr:content situé sous une page donnée limite l’accès au contenu s.str d’une page donnée, mais n’a aucun effet sur les pages enfants ou frères. Il peut s’agir d’un cas d’utilisation valide, réalisable avec un éditeur de référentiel qui vous permet d’appliquer un accès de granularité fine au contenu. Toutefois, cela contraste avec l’ancienne mise en œuvre où le placement d’une propriété cq:cugEnabled sur le nœud jcr:content était remappé en interne sur le nœud de page. Ce mappage n’est plus effectué.
Évaluation des autorisations avec les politiques CUG
Le passage de l’ancienne prise en charge des CUG à un modèle d’autorisation supplémentaire, modifie la façon dont les permissions de lecture en vigueur sont évaluées. Comme décrit dans le Documentation Jackrabbit, un principal de sécurité donné autorisé à afficher le CUGcontent
ne se verra accorder l’accès en lecture que si l’évaluation des permissions de tous les modèles configurés dans le référentiel Oak lui accorde l’accès en lecture.
En d’autres termes, pour l’évaluation des autorisations effectives, les deux variables suivantes sont disponibles : CUGPolicy
et les entrées de contrôle d’accès par défaut sont prises en compte, et l’accès en lecture sur le contenu CUG n’est autorisé que s’il est accordé par les deux types de politiques. Dans une installation de publication AEM par défaut où l’accès en lecture à la /content
L’arborescence est accordée à tout le monde. L’effet des politiques de CUG est le même que celui de l’ancienne mise en œuvre.
Évaluation à la demande
Le modèle d’autorisation des CUG permet d’activer individuellement la gestion du contrôle d’accès et l’évaluation des permissions :
- La gestion du contrôle d’accès est activée si le module dispose d’un ou plusieurs chemins pris en charge où les CUG peuvent être créés.
- l’évaluation des autorisations n’est activée que si l’option Évaluation de CUG activée est également vérifié.
Dans l’évaluation des politiques de CUG de la nouvelle configuration par défaut AEM, elle est uniquement activée avec le mode d’exécution de publication. Consultez les informations relatives à la configuration par défaut depuis AEM 6.3 pour en savoir plus. Cela peut être vérifié en comparant les politiques en vigueur pour un chemin donné vers les politiques stockées dans le contenu. Les politiques en vigueur sont affichées uniquement dans le cas où l’évaluation des permissions est activée pour les CUG.
Comme expliqué plus haut, les politiques de contrôle d’accès de CUG sont désormais toujours stockées dans le contenu, mais l’évaluation des permissions en vigueur découlant de ces politiques ne sera imposée que si l’évaluation des CUG activée est sélectionnée dans la console système au niveau de la configuration des CUG Apache Jackrabbit Oak . Par défaut, elle est uniquement activée avec le mode d’exécution de publication.
Différences en matière d’authentification differences-with-regards-to-authentication
Les différences concernant l’authentification sont décrites ci-dessous.
Type de mixin dédié pour les exigences d’authentification dedicated-mixin-type-for-authentication-requirement
Dans l’ancienne mise en œuvre, les aspects d’autorisation et d’authentification d’un CUG étaient tous deux déclenchés par une seule propriété JCR (cq:cugEnabled
). En ce qui concerne l’authentification, il en résultait une liste mise à jour des exigences d’authentification telles que stockées avec la mise en œuvre de l’authentificateur Apache Sling. Avec la nouvelle mise en œuvre, le même résultat est obtenu en marquant le nœud cible avec un type de mixin dédié ( granite:AuthenticationRequired
).
Propriété d’exclusion d’un chemin de connexion property-for-excluding-login-path
Le type de mixin définit une propriété unique et facultative appelée granite:loginPath
, qui correspond essentiellement à la propriété cq:cugLoginPage
. Contrairement à la mise en œuvre précédente, la propriété de chemin de connexion n’est respectée que si son type de nœud d’instruction est le mixin mentionné. L’ajout d’une propriété portant ce nom sans définir le type de mixin n’a aucun effet et ni une nouvelle exigence ni une exclusion pour le chemin de connexion n’est signalée à l’authentificateur.
Privilège pour l’exigence d’authentification privilege-for-authentication-requirement
L’ajout ou la suppression d’un type de mixin requiert l’attribution du privilège jcr:nodeTypeManagement
. Dans la mise en œuvre précédente, le privilège jcr:modifyProperties
était utilisé pour modifier la propriété résiduelle.
En ce qui concerne granite:loginPath
, le même privilège est requis pour ajouter, modifier ou supprimer la propriété.
Nœud cible défini par type de mixin target-node-defined-by-mixin-type
Créez des exigences d’authentification au niveau du nœud JCR définissant la sous-arborescence qui doit être soumise à une connexion forcée. Il s’agit probablement d’une page AEM au cas où le CUG devrait affecter l’arborescence entière et l’interface utilisateur de la nouvelle mise en œuvre ajoute donc le type de mixin exigence d’authentification au nœud de la page.
Le placement de la politique de CUG uniquement au niveau du nœud jcr:content situé sous une page donnée limite uniquement l’accès au contenu. Toutefois, elle ne prend pas effet sur le nœud de page lui-même ni sur les pages enfants.
Il peut s’agir d’un scénario valide et possible avec un éditeur de référentiel qui vous permet de placer le mixin au niveau de n’importe quel nœud. Toutefois, le comportement contraste avec l’ancienne mise en œuvre où le placement d’une propriété cq:cugEnabled ou cq:cugLoginPage sur le nœud jcr:content était remis en correspondance en interne sur le nœud de page. Ce mappage n’est plus effectué.
Chemins pris en charge configurés configured-supported-paths
Le type de mixin granite:AuthenticationRequired
et la propriété granite:loginPath sont respectés uniquement dans la portée définie par le jeu de l’option de configuration Chemins pris en charge présent avec le Gestionnaire d’exigence d’authentification et de chemin de connexion Adobe Granite. Si aucun chemin n’est spécifié, la fonction d’exigence d’authentification est complètement désactivée. Dans ce cas, ni le type de mixin ni la propriété ne prennent effet lorsqu’ils sont ajoutés ou définis sur un nœud JCR donné.
Mappage de contenu JCR, de services OSGi et de configurations mapping-of-jcr-content-osgi-services-and-configurations
Le document ci-dessous fournit un mappage complet des services OSGi, des configurations et du contenu de référentiel entre l’ancienne et la nouvelle mise en œuvre.
Mise en correspondance de CUG depuis AEM 6.3
Mettre à niveau le CUG upgrade-cug
Installations existantes utilisant le CUG obsolète existing-installations-using-the-deprecated-cug
L’ancienne mise en œuvre de prise en charge des CUG a été abandonnée et sera supprimée dans les futures versions. Il est recommandé de passer aux nouvelles implémentations lors de la mise à niveau à partir de versions antérieures à AEM 6.3.
Pour les installations AEM mises à niveau, il est important de s’assurer qu’une seule mise en œuvre CUG est activée. La combinaison de la nouvelle et de l’ancienne prise en charge des CUG obsolètes n’est pas testée et est susceptible de provoquer un comportement indésirable :
- collisions dans l’authentificateur Sling concernant les exigences d’authentification
- L’accès en lecture refusé lorsque la configuration de l’ACL associée à l’ancien CUG entre en collision avec une nouvelle politique CUG.
Migration d’un contenu de CGU existant migrating-existing-cug-content
Adobe fournit un outil pour migrer vers la nouvelle mise en œuvre de CUG. Pour l’utiliser, procédez comme suit :
- Accédez à
https://<serveraddress>:<serverport>/system/console/cug-migration
pour accéder à l’outil. - Saisissez le chemin racine pour lequel vous souhaitez vérifier les CUG et appuyez sur la touche Exécution de l’essai Bouton. Cette opération recherche les CUG pouvant être convertis à l’emplacement sélectionné.
- Une fois que vous avez consulté les résultats, appuyez sur le bouton Effectuer la migration pour migrer vers la nouvelle mise en œuvre.
com.day.cq.auth.impl.cug
pour obtenir la sortie de l’outil de migration. Consultez la rubrique Connexion pour en savoir plus sur la procédure à suivre.