Les Applications web offrent souvent des fonctions de gestion de compte permettant aux utilisateurs finaux de s’enregistrer sur un site Web, ce qui permet de conserver leurs informations de profil d’utilisateur, leur permettant de se connecter ultérieurement et de bénéficier d’une expérience cohérente. Cet article décrit :
Pour que la fonctionnalité décrite dans cet article fonctionne, la fonction de synchronisation des données utilisateur doit être activée, ce qui nécessite pour le moment une demande au service clientèle indiquant le programme et les environnements appropriés. Si elles ne sont pas activées, les informations des utilisateurs seront conservées pendant une courte période (1 à 24 heures) avant de disparaître.
Lorsqu’un utilisateur final s’enregistre pour un compte sur une application AEM, un compte d’utilisateur est créé sur le service de publication AEM, tel qu’il est reflété sur une ressource d’utilisateur sous /home/users
dans le référentiel JCR.
La mise en oeuvre de l'enregistrement repose sur deux approches, décrites ci-dessous.
Il est possible d’écrire un code d’enregistrement personnalisé qui prend, au minimum, le nom d’utilisateur et le mot de passe de l’utilisateur final et crée un enregistrement d’utilisateur dans AEM qui peut ensuite être utilisé pour s’authentifier lors de la connexion. Les étapes suivantes sont généralement utilisées pour construire ce mécanisme d’enregistrement :
findAuthorizables()
de l’API UserManager.createUser()
de l'API UserManager.setProperty()
de l'interface autoriséeDans certains cas, l'enregistrement ou la création d'utilisateurs s'est déjà produit dans des infrastructures en dehors de l'AEM. Dans ce scénario, l’enregistrement utilisateur est créé dans AEM lors de la connexion.
Une fois qu’un utilisateur final est enregistré sur le service de publication AEM, ces utilisateurs peuvent se connecter pour disposer d’un accès authentifié (à l’aide de mécanismes d’autorisation AEM) et de données spécifiques persistantes à l’utilisateur, telles que les données de profil.
La connexion peut être mise en oeuvre selon les deux approches suivantes :
Les clients peuvent écrire leurs propres composants personnalisés. Pour en savoir plus, pensez à vous familiariser avec :
Les clients peuvent intégrer un IdP (fournisseur d'identité), qui authentifie l'utilisateur. Les technologies d’intégration incluent SAML et OAuth/SSO, comme décrit ci-dessous.
BASÉ SUR SAML
Les clients peuvent utiliser l’authentification SAML via leur IdP SAML préféré. Lors de l’utilisation d’un IdP avec AEM, l’IdP est chargé d’authentifier les informations d’identification de l’utilisateur final et de négocier l’authentification de l’utilisateur avec AEM, de créer l’enregistrement de l’utilisateur dans l’AEM, le cas échéant, et de gérer l’appartenance de groupe de l’utilisateur dans les , comme décrit par l’assertion SAML.
Seule l’authentification initiale des informations d’identification de l’utilisateur est authentifiée par l’IdP et les demandes d’AEM ultérieures sont exécutées à l’aide d’un cookie de jeton de connexion AEM, à condition que le cookie soit disponible.
Voir la documentation pour plus d’informations sur le gestionnaire d’authentification SAML 2.0.
OAuth/SSO
Pour plus d’informations sur l’utilisation du service de gestionnaire d’authentification unique AEM, consultez la documentation relative à la connexion unique (SSO).
L'interface com.adobe.granite.auth.oauth.provider
peut être implémentée avec le fournisseur OAuth de votre choix.
aem en tant que Cloud Service, les sessions d’affinité basées sur les cookies sont activées, ce qui garantit qu’un utilisateur final est dirigé vers le même noeud de publication pour chaque requête. Afin d’améliorer les performances, la fonction de jeton encapsulé est activée par défaut, de sorte que l’enregistrement utilisateur dans le référentiel n’ait pas besoin d’être référencé pour chaque requête. Si le noeud de publication auquel l’utilisateur final a une affinité est remplacé, son enregistrement d’ID utilisateur est disponible sur le nouveau noeud de publication, comme décrit dans la section de synchronisation des données ci-dessous.
Il existe différentes approches pour conserver les données, selon la nature de ces données.
Les informations du profil utilisateur peuvent être écrites et lues de deux manières :
com.adobe.granite.security.user
UserPropertiesManager, qui place les données sous le noeud de l'utilisateur dans /home/users
. Assurez-vous que les pages uniques par utilisateur ne sont pas mises en cache.Les données de l’utilisateur final peuvent être envoyées à des fournisseurs tiers, tels que des systèmes de gestion de la relation client, et récupérées par le biais d’API lors de la connexion de l’utilisateur à l’AEM et conservées (ou actualisées) sur le noeud de profil de l’utilisateur AEM, et utilisées par l’utilisateur le cas échéant par l’AEM.
Il est possible d’accéder en temps réel à des services tiers pour récupérer des attributs de profil. Toutefois, il est important de s’assurer que cela n’a pas d’impact significatif sur le traitement des demandes dans AEM.
Les stratégies d’accès de la publication, également appelées CUG (Closed User Groups), sont définies dans l’auteur de l’AEM comme décrites ici. Afin de limiter certains sections ou pages d’un site Web à certains utilisateurs, appliquez les CUG selon les besoins à l’aide de l’auteur de l’AEM, comme décrit ici, et dupliquez-les au niveau de publication.
Indépendamment de la connexion, le code personnalisé peut également persister et gérer les appartenances d’un groupe d’utilisateurs en fonction des besoins uniques de l’entreprise.
Les utilisateurs finaux du site Web attendent une expérience cohérente pour chaque requête de page Web ou même lorsqu’ils se connectent à l’aide d’un navigateur différent, même s’ils ne le savent pas, ils sont amenés à différents noeuds de serveur de l’infrastructure de la couche Publication. aem en tant que Cloud Service effectue cette opération en synchronisant rapidement la hiérarchie de dossiers /home
(informations de profil d'utilisateur, appartenance à un groupe, etc.) sur tous les noeuds de la couche de publication.
Contrairement à d’autres solutions AEM, la synchronisation des membres d’utilisateurs et de groupes dans AEM en tant que Cloud Service n’utilise pas une approche de messagerie point à point, mais met en oeuvre une approche de publication-abonnement qui ne nécessite pas de configuration client.
Par défaut, la synchronisation des profils d’utilisateurs et des membres de groupes n’est pas activée et les données ne seront donc pas synchronisées ni même conservées de manière permanente sur la couche de publication. Pour activer la fonction, envoyez une demande au service d’assistance clientèle pour lui indiquer le programme et les environnements appropriés.
Les requêtes HTTP authentifiées peuvent être difficiles à mettre en cache à la fois sur le CDN et sur le Répartiteur, car elles comportent la possibilité de transférer un état spécifique à l’utilisateur dans le cadre de la réponse de la requête. La mise en cache accidentelle de requêtes authentifiées et leur diffusion sur d’autres navigateurs demandeurs peuvent entraîner des expériences incorrectes, voire la fuite de données protégées ou d’utilisateurs.
Voici quelques-unes des méthodes permettant de conserver une capacité élevée de mémoire cache des requêtes tout en prenant en charge les réponses spécifiques à l’utilisateur :