Prise en charge des jetons encapsulés encapsulated-token-support
Présentation introduction
Par défaut, AEM utilise le gestionnaire d’authentification des jetons pour authentifier chaque demande. Cependant, pour traiter des demandes d’authentification, le gestionnaire d’authentification des jetons doit avoir accès au référentiel pour chaque demande. Cela est dû au fait que des cookies sont utilisés pour maintenir l’état d’authentification. Logiquement, l’état doit perdurer dans le référentiel afin de valider les demandes ultérieures. Dans les faits, cela signifie que le mécanisme d’authentification est avec état.
Cela est particulièrement important pour l’évolutivité horizontale. Dans une configuration comportant plusieurs instances, comme la batterie de publication représentée ci-dessous, la répartition de charge ne peut pas être exécutée de façon optimale. Avec l’authentification avec état, l’état d’authentification persistant n’est disponible que sur l’instance où la personne est authentifiée pour la première fois.
Prenons comme exemple le scénario suivant :
Un personne peut être authentifiée sur l’instance de publication 1, mais si une requête ultérieure est envoyée à l’instance de publication 2, cette instance ne dispose pas de cet état d’authentification persistant, car cet état a été conservé dans le référentiel de publication 1 et la publication 2 possède son propre référentiel.
La solution consiste à configurer des connexions persistantes au niveau de l’équilibreur de charge. Avec des connexions persistantes, un utilisateur serait toujours dirigé vers la même instance de publication. Par conséquent, un équilibrage de charge réellement optimal n’est pas possible.
Si une instance de publication devient inaccessible, tous les utilisateurs authentifiés sur cette instance perdent leur session, Cela est dû au fait que l’accès au référentiel est nécessaire pour valider le cookie d’authentification.
Authentification sans état avec jeton encapsulé stateless-authentication-with-the-encapsulated-token
Pour permettre une évolutivité horizontale, la solution consiste à recourir à une authentification sans état, grâce à la nouvelle prise en charge des jetons encapsulés dans AEM.
Le jeton encapsulé est un élément de chiffrement qui permet à AEM de créer et de valider de façon sécurisée des informations d’authentification hors ligne, sans accéder au référentiel. Ainsi, une demande d’authentification peut être effectuée sur toutes les instances de publication, sans nécessiter de connexions persistantes. Cela présente également l’avantage d’améliorer les performances d’authentification, car il n’est pas nécessaire d’accéder au référentiel pour chaque demande d’authentification.
Vous pouvez découvrir comment cela fonctionne dans un déploiement distribué géographiquement avec les instances de création MongoMK et de publication TarMK ci-dessous :
Configuration du jeton encapsulé configuring-the-encapsulated-token
-
les sessions persistantes sont activées, ou
-
les utilisateurs sont déjà créés dans AEM au démarrage de la synchronisation. Cela signifie que les jetons encapsulés ne seront pas pris en charge dans les cas où les gestionnaires créent des utilisateurs au cours du processus de synchronisation.
Lors de la configuration du jeton encapsulé, vous devez prendre en compte quelques points :
- Compte tenu du chiffrement impliqué, toutes les instances doivent posséder la même clé HMAC. À compter d’AEM 6.3, le matériel de la clé n’est plus stocké dans le référentiel, mais sur le système de fichiers réel. Ainsi, la meilleure façon de répliquer les clés consiste à les copier du système de fichiers de l’instance source vers celle des instances cibles sur lesquelles vous souhaitez répliquer les clés. Pour plus d’informations, consultez « Réplication de la clé HMAC » ci-dessous.
- Le jeton encapsulé doit être activé. Vous pouvez l’activer avec la console web.
Réplication de la clé HMAC replicating-the-hmac-key
Pour répliquer la clé sur plusieurs instances, procédez comme suit :
-
Accédez à l’instance AEM, généralement une instance de création, et qui contient le matériel des clés à copier.
-
Localisez le lot
com.adobe.granite.crypto.filedans le système de fichiers local. Par exemple, sous ce chemin d’accès :<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle25
Le fichier
bundle.infoà l’intérieur de chaque dossier identifie le nom du lot. -
Accédez au dossier des données. Par exemple :
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle25/data
-
Copier les fichiers HMAC et maîtres.
-
Ensuite, accédez à l’instance cible sur laquelle vous souhaitez dupliquer la clé HMAC, puis accédez au dossier des données. Par exemple :
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle25/data
-
Collez les deux fichiers copiés précédemment.
-
Actualisez le lot de chiffrement si l’instance cible est déjà en cours d’exécution.
-
Répétez les étapes ci-dessus pour toutes les instances sur lesquelles vous souhaitez répliquer la clé.
Activation du jeton encapsulé enabling-the-encapsulated-token
Une fois la clé HMAC répliquée, vous pouvez activer le jeton encapsulé à l’aide de la console Web :
- Pointez votre navigateur sur
https://serveraddress:port/system/console/configMgr. - Recherchez une entrée nommée Gestionnaire d’authentification des jetons Adobe Granite et cliquez dessus.
- Dans la fenêtre suivante, cochez la case Activer la prise en charge des jetons encapsulés et cliquez sur Enregistrer.