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. Ceci 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. En effet, cela signifie que le mécanisme d’authentification est à l’état.

Cela est particulièrement important pour l’évolutivité horizontale. Dans une configuration comportant plusieurs instances, comme la ferme de serveurs de publication représentée ci-dessous, l’équilibrage de charge ne peut pas être exécuté de façon optimale. Avec l’authentification avec état, l’état d’authentification persistante n’est disponible que sur l’instance où l’utilisateur est authentifié pour la première fois.

Prenons comme exemple le scénario suivant :

Un utilisateur peut être authentifié 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. Elle 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

Lors de la configuration du jeton encapsulé, vous devez prendre en compte quelques points :

Réplication de la clé HMAC replicating-the-hmac-key

La clé HMAC est présente sous forme de propriété binaire /etc/key dans le référentiel. Vous pouvez la télécharger séparément en cliquant sur le lien afficher en face de lui :

Pour répliquer la clé sur plusieurs instances, procédez comme suit :

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 :