Registro, inicio de sesión y perfil de usuario

Introducción

Las aplicaciones web a menudo proporcionan funciones de administración de cuentas para que los usuarios finales se registren en un sitio web, lo que persiste en su información de datos de usuario, lo que les permite iniciar sesión en el futuro y disfrutar de una experiencia coherente. En este artículo se describen los siguientes conceptos para AEM como Cloud Service:

  • Registro
  • Inicio de sesión
  • Almacenamiento de datos de perfil de usuario
  • Pertenencia a grupos
  • Sincronización de datos
IMPORTANTE

Para que funcione la funcionalidad descrita en este artículo, debe habilitarse la función Sincronización de datos de usuario , que en este momento requiere una solicitud al servicio de atención al cliente indicando el programa y los entornos adecuados. Si no está habilitada, la información del usuario se mantendrá durante un breve periodo (de 1 a 24 horas) antes de desaparecer.

Registro

Cuando un usuario final se registra para una cuenta en una aplicación AEM, se crea una cuenta de usuario en el servicio AEM Publish, como se refleja en un recurso de usuario en /home/users en el repositorio JCR.

A continuación se describen dos métodos para la aplicación del registro.

AEM administrado

Se puede escribir un código de registro personalizado que tome, como mínimo, el nombre de usuario y la contraseña del usuario final y que cree un registro de usuario en AEM que se pueda utilizar para autenticarse durante el inicio de sesión. Los siguientes pasos suelen utilizarse para construir este mecanismo de registro:

  1. Mostrar un componente de AEM personalizado que recopila información de registro
  2. Tras el envío, se utiliza un usuario de servicio aprovisionado correctamente para
    1. Compruebe que un usuario existente no existe todavía, utilizando uno de los métodos findAuthorizables() de la API de UserManager
    2. Cree un registro de usuario utilizando uno de los métodos createUser() de la API UserManager
    3. Conservar cualquier dato de perfil capturado mediante los métodos setProperty() de la interfaz Autorizable
  3. Flujos opcionales, como exigir al usuario que valide su correo electrónico.

Externo

En algunos casos, el registro o la creación de usuarios se han producido anteriormente en infraestructura fuera de AEM. En ese escenario, el registro de usuario se crea en AEM durante el inicio de sesión.

Inicio de sesión

Una vez que un usuario final está registrado en el servicio AEM Publish, estos usuarios pueden iniciar sesión para tener acceso autenticado (mediante mecanismos de autorización de AEM) y datos persistentes y específicos del usuario, como datos de perfil.

Implementación

El inicio de sesión se puede implementar con los dos enfoques siguientes:

AEM administrado

Los clientes pueden escribir sus propios componentes personalizados. Para obtener más información, considere la posibilidad de familiarizarse con:

Integración con un proveedor de identidad

Los clientes pueden integrarse con un IdP (proveedor de identidad), que autentica al usuario. Las tecnologías de integración incluyen SAML y OAuth/SSO, como se describe a continuación.

BASADO EN SAML

Los clientes pueden utilizar la autenticación basada en SAML a través de su SAML IdP preferido. Cuando se utiliza un IdP con AEM, el IdP es responsable de autenticar las credenciales del usuario final e intermediar la autenticación del usuario con AEM, crear el registro de usuario en AEM según sea necesario y administrar la pertenencia al grupo del usuario en AEM, como se describe en la afirmación de SAML.

NOTA

Solo el IdP autentica la autenticación inicial de las credenciales del usuario y las solicitudes posteriores a AEM se realizan mediante una cookie de token de inicio de sesión AEM, siempre que la cookie esté disponible.

Consulte la documentación para obtener más información sobre el gestor de autenticación SAML 2.0.

OAuth/SSO

Consulte la documentación Inicio de sesión único (SSO) para obtener información sobre el uso AEM servicio del gestor de autenticación SSO.

La interfaz com.adobe.granite.auth.oauth.provider se puede implementar con el proveedor de OAuth de su elección.

Sesiones adhesivas y tokens encapsulados

AEM como Cloud Service tiene habilitadas las sesiones adhesivas basadas en cookies, lo que garantiza que un usuario final se enrute al mismo nodo de publicación en cada solicitud. Para aumentar el rendimiento, la función de token encapsulado está habilitada de forma predeterminada, por lo que no es necesario hacer referencia al registro de usuario en el repositorio en cada solicitud. Si se reemplaza el nodo de publicación al que un usuario final tiene afinidad, su registro de id de usuario estará disponible en el nuevo nodo de publicación, tal como se describe en la sección de sincronización de datos a continuación.

Perfil de usuario

Existen diversos enfoques para la persistencia de los datos, según la naturaleza de esos datos.

Repositorio de AEM

La información del perfil del usuario se puede escribir y leer de dos maneras:

  • Uso del lado del servidor con la interfaz com.adobe.granite.security.user UserPropertiesManager, que colocará los datos bajo el nodo del usuario en /home/users. Asegúrese de que las páginas que son únicas por usuario no se almacenen en caché.
  • Lado del cliente mediante ContextHub, tal como se describe en la documentación.

Almacenes de datos de terceros

Los datos del usuario final se pueden enviar a proveedores de terceros, como CRM, y recuperar mediante API al iniciar sesión el usuario para AEM y conservarlos (o actualizarlos) en el nodo de perfil del usuario de AEM, y los puede utilizar AEM según sea necesario.

El acceso en tiempo real a servicios de terceros para recuperar atributos de perfil es posible, pero es importante asegurarse de que esto no afecte sustancialmente al procesamiento de solicitudes en AEM.

Permisos (grupos de usuarios cerrados)

Las políticas de acceso del nivel de publicación, también denominadas Grupos de usuarios cerrados (CUG), se definen en el autor de AEM como se describen aquí. Para restringir ciertas secciones o páginas de un sitio web de algunos usuarios, aplique los CUG según sea necesario utilizando el autor de AEM, como se describe aquí, y duplique en el nivel de publicación.

  • Si los usuarios inician sesión al autenticarse con un proveedor de identidad (IdP) mediante SAML, el controlador de autenticación identificará las pertenencias de grupo del usuario (que deben coincidir con los CUG en el nivel de publicación) y persistirá la asociación entre el usuario y el grupo a través de un registro de repositorio
  • Si el inicio de sesión se realiza sin integración con IdP, el código personalizado puede aplicar las mismas relaciones de estructura de repositorios.

Independientemente del inicio de sesión, el código personalizado también puede mantener y administrar las pertenencias de grupo de un usuario según los requisitos únicos de la organización.

Sincronización de datos

Los usuarios finales de sitios web esperan una experiencia coherente en cada solicitud de página web o incluso cuando inician sesión con un explorador diferente, aunque no sepan, se los lleva a diferentes nodos de servidor de la infraestructura del nivel de publicación. AEM como Cloud Service lo consigue sincronizando rápidamente la jerarquía de carpetas /home (información de perfil de usuario, pertenencia a grupos, etc.) en todos los nodos del nivel de publicación.

A diferencia de otras soluciones AEM, la sincronización de la pertenencia de usuarios y grupos en AEM como Cloud Service no utiliza un enfoque de mensajería punto a punto, sino que implementa un enfoque de suscripción de publicación que no requiere configuración del cliente.

NOTA

De forma predeterminada, la sincronización de perfiles de usuario y pertenencia a grupos no está habilitada y, por lo tanto, los datos no se sincronizarán con el nivel de publicación, ni siquiera se mantendrán de forma permanente. Para habilitar la función, envíe una solicitud al Servicio de atención al cliente indicando el programa y los entornos adecuados.

Consideraciones de caché

Las solicitudes HTTP autenticadas pueden ser difíciles de almacenar en caché tanto en la CDN como en Dispatcher, ya que pueden transferir el estado específico del usuario como parte de la respuesta de la solicitud. Almacenar en caché de forma involuntaria solicitudes autenticadas y enviarlas a otros navegadores solicitantes puede dar como resultado experiencias incorrectas, o incluso perder datos de usuarios o protegidos.

Los métodos para mantener una alta capacidad de caché de las solicitudes mientras se admiten respuestas específicas del usuario incluyen:

  • AEM caché confidencial de permisos de Dispatcher
  • Sling Dynamic Include
  • AEM ContextHub

En esta página