Show Menu
TEMAS×

Compatibilidad con token encapsulado

Introducción

De forma predeterminada, AEM utiliza el controlador de autentificación de testigos para autenticar cada solicitud. Sin embargo, para poder enviar solicitudes de autenticación, el Controlador de autentificación de autentificador requiere acceso al repositorio para cada solicitud. Esto sucede porque las cookies se utilizan para mantener el estado de autenticación. Lógicamente, el estado debe persistir en el repositorio para validar las solicitudes posteriores. De hecho, esto significa que el mecanismo de autenticación tiene estado.
Esto es especialmente importante para la escalabilidad horizontal. En una configuración de varias instancias como la granja de publicaciones que se muestra a continuación, el equilibrio de carga no se puede lograr de forma óptima. Con la autenticación con estado, el estado de autenticación persistente solo estará disponible en la instancia en la que el usuario se autentique por primera vez.
Veamos el siguiente escenario como ejemplo:
Un usuario puede autenticarse en la instancia de publicación uno, pero si una solicitud subsiguiente va a la instancia de publicación dos, esa instancia no tiene ese estado de autenticación persistente, porque ese estado se mantuvo en el repositorio de la publicación uno y la publicación dos tiene su propio repositorio.
La solución para esto es configurar las conexiones adhesivas en el nivel de equilibrador de carga. Con las conexiones adhesivas, un usuario siempre se dirigiría a la misma instancia de publicación. Como consecuencia, no es posible un equilibrio de carga realmente óptimo.
Si una instancia de publicación deja de estar disponible, todos los usuarios autenticados en esa instancia perderán su sesión. Esto se debe a que se necesita acceso al repositorio para validar la cookie de autenticación.

Autenticación sin estado con el token encapsulado

La solución para la escalabilidad horizontal es la autenticación sin estado con el uso de la nueva compatibilidad con Token encapsulado en AEM.
El autentificador encapsulado es un fragmento de criptografía que permite a AEM crear y validar de forma segura la información de autenticación sin conexión, sin tener acceso al repositorio. De este modo, puede producirse una solicitud de autenticación en todas las instancias de publicación y sin necesidad de conexiones adhesivas. También tiene la ventaja de mejorar el rendimiento de la autenticación, ya que no es necesario acceder al repositorio para cada solicitud de autenticación.
Puede ver cómo funciona esto en una implementación distribuida geográficamente con los autores de MongoMK y las instancias de publicación de TarMK a continuación:
Tenga en cuenta que el autentificador encapsulado trata de la autenticación. Garantiza que la cookie se pueda validar sin tener que acceder al repositorio. Sin embargo, sigue siendo necesario que el usuario exista en todas las instancias y que todas las instancias tengan acceso a la información almacenada en ese usuario.
Por ejemplo, si se crea un nuevo usuario en la instancia de publicación número uno, debido al funcionamiento del token encapsulado, se autenticará correctamente en la publicación número dos. Si el usuario no existe en la segunda instancia de publicación, la solicitud no se realizará correctamente.

Configuración del token encapsulado

Todos los controladores de autenticación que sincronizan usuarios y dependen de la autenticación por token (como SAML y OAuth) solo funcionarán con tokens encapsulados si:
  • Las sesiones adhesivas están activadas o
  • Los usuarios ya se crean en AEM cuando inicio la sincronización. Esto significa que los tokens encapsulados no se admitirán en situaciones en las que los controladores creen usuarios durante el proceso de sincronización.
Hay algunas cosas que debe tener en cuenta al configurar el token encapsulado:
  1. Debido a la criptografía involucrada, todas las instancias necesitan tener la misma clave HMAC. Desde AEM 6.3, el material clave ya no se almacena en el repositorio, sino en el sistema de archivos real. Con esto en mente, la mejor manera de replicar las claves es copiarlas del sistema de archivos de la instancia de origen a la de las instancias de destinatario a las que desee replicar las claves. Ver más información debajo de "Replicando la clave HMAC".
  2. El token encapsulado debe estar habilitado. Esto se puede realizar a través de la consola web.

Replicar la clave HMAC

La clave HMAC está presente como una propiedad binaria de /etc/key en el repositorio. Puede descargarlo por separado pulsando el vínculo de vista que hay junto a él:
Para replicar la clave entre instancias, debe:
  1. Acceda a la instancia de AEM, que suele ser una instancia de autor, que contiene el material clave que copiar;
  2. Busque el com.adobe.granite.crypto.file paquete en el sistema de archivos local. Por ejemplo, en esta ruta:
    • <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21
    El bundle.info archivo dentro de cada carpeta identificará el nombre del paquete.
  3. Vaya a la carpeta de datos. Por ejemplo:
    • <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
  4. Copie los archivos principales y HMAC.
  5. A continuación, vaya a la instancia de destinatario a la que desee realizar el duplicado de la clave HMAC y navegue hasta la carpeta de datos. Por ejemplo:
    • <publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
  6. Pegue los dos archivos que copió anteriormente.
  7. Actualice el paquete de cifrado si la instancia de destinatario ya se está ejecutando.
  8. Repita los pasos anteriores para todas las instancias en las que desee replicar la clave.

Activación del token encapsulado

Una vez replicada la clave HMAC, puede habilitar el token encapsulado mediante la consola web:
  1. Elija el explorador para https://serveraddress:port/system/console/configMgr
  2. Busque una entrada denominada Controlador de autentificación de autentificador CRX de día y haga clic en ella.
  3. En la siguiente ventana, marque la casilla Activar compatibilidad con token encapsulado y pulse Guardar .