Inscription, connexion et Profil utilisateur

Présentation

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 :

  • Enregistrement
  • Connexion
  • Stockage des données de profil utilisateur
  • Appartenance au groupe
  • Synchronisation des données
IMPORTANT

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.

Enregistrement

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.

aem géré

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 :

  1. Affichage d’un composant d’AEM personnalisé qui collecte les informations d’enregistrement
  2. Lors de l’envoi, un utilisateur de service correctement configuré est utilisé pour
    1. Vérifiez qu’un utilisateur existant n’existe pas déjà, en utilisant l’une des méthodes findAuthorizables() de l’API UserManager.
    2. Créez un enregistrement d'utilisateur à l'aide de l'une des méthodes createUser() de l'API UserManager.
    3. Persister toutes les données de profil capturées à l'aide des méthodes setProperty() de l'interface autorisée
  3. Flux facultatifs, comme l’obligation pour l’utilisateur de valider son courrier électronique.

Externe

Dans 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.

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.

Mise en œuvre

La connexion peut être mise en oeuvre selon les deux approches suivantes :

aem géré

Les clients peuvent écrire leurs propres composants personnalisés. Pour en savoir plus, pensez à vous familiariser avec :

Intégration à un fournisseur d'identité

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.

REMARQUE

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.

Sessions réactives et jetons encapsulés

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.

Profil utilisateur

Il existe différentes approches pour conserver les données, selon la nature de ces données.

Référentiel AEM

Les informations du profil utilisateur peuvent être écrites et lues de deux manières :

  • Utilisation côté serveur avec l'interface 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.
  • côté client à l’aide de ContextHub, comme décrit par la documentation.

Stockages de données tiers

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.

Autorisations (groupes d’utilisateurs fermés)

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.

  • Si les utilisateurs se connectent en s'authentifiant auprès d'un fournisseur d'identité (IdP) à l'aide de SAML, le gestionnaire d'authentification identifie les appartenances de groupe de l'utilisateur (qui doivent correspondre aux CUG sur la couche de publication) et maintient l'association entre l'utilisateur et le groupe via un enregistrement de référentiel.
  • Si la connexion est établie sans intégration IdP, le code personnalisé peut appliquer les mêmes relations de structure de référentiel.

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.

Synchronisation des données

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.

REMARQUE

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.

Considérations sur le cache

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 :

  • Mise en cache sensible des autorisations du répartiteur AEM
  • Inclure dynamique Sling
  • aem ContextHub

Sur cette page