Compatibilidad con tokens encapsulados encapsulated-token-support
Introducción introduction
De forma predeterminada, AEM utiliza el controlador de autenticación de tokens para autenticar cada solicitud. Sin embargo, para servir solicitudes de autenticación, el gestor de autenticación de tokens 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 de particular importancia para la escalabilidad horizontal. En una configuración de varias instancias como la granja de servidores de publicación que se muestra a continuación, el equilibrio de carga no se puede lograr de una manera óptima. Con la autenticación mediante 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 posterior va a publicar la instancia dos, esa instancia no tiene ese estado de autenticación persistente, porque ese estado se persistió en el repositorio de publicación uno y la publicación dos tiene su propio repositorio.
La solución para esto es configurar las conexiones duraderas en el nivel de equilibrador de carga. Con conexiones duraderas, un usuario siempre sería dirigido 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 stateless-authentication-with-the-encapsulated-token
La solución para la escalabilidad horizontal es la autenticación sin estado con el uso del nuevo soporte de Token Encapsulado en AEM.
El Token encapsulado es un trozo de criptografía que permite AEM crear y validar de forma segura la información de autenticación sin conexión, sin acceder al repositorio. De este modo, puede producirse una solicitud de autenticación en todas las instancias de publicación y sin necesidad de conexiones duraderas. 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:
Configuración del token encapsulado configuring-the-encapsulated-token
-
Las sesiones adhesivas están habilitadas o
-
Los usuarios ya se han creado en AEM al iniciarse la sincronización. Esto significa que los tokens encapsulados no se admitirán en situaciones en las que los controladores crear usuarios durante el proceso de sincronización.
Hay algunas cosas que debe tener en cuenta al configurar el token encapsulado:
- 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 destino a las que desee replicar las claves. Vea más información en "Replicando la clave HMAC" a continuación.
- El token encapsulado debe estar habilitado. Esto se puede hacer a través de la Consola Web.
Duplicación de la clave HMAC replicating-the-hmac-key
La clave HMAC está presente como una propiedad binaria de /etc/key en el repositorio. Puede descargarlo por separado presionando la ver vínculo junto a él:
Para poder replicar la clave entre instancias, debe:
-
Acceda a la instancia de AEM, normalmente una instancia de autor, que contiene el material clave que se va a copiar;
-
Busque la variable
com.adobe.granite.crypto.filepaquete en el sistema de archivos local. Por ejemplo, en esta ruta:- <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21
La variable
bundle.infodentro de cada carpeta identificará el nombre del paquete. -
Vaya a la carpeta de datos. Por ejemplo:
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Copie los archivos HMAC y maestro.
-
A continuación, vaya a la instancia de destino a la que desee duplicar la clave HMAC y vaya a la carpeta de datos. Por ejemplo:
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Pegue los dos archivos que ha copiado anteriormente.
-
Actualizar el paquete criptográfico si la instancia de destino ya se está ejecutando.
-
Repita los pasos anteriores para todas las instancias en las que desee replicar la clave.
Activación del token encapsulado enabling-the-encapsulated-token
Una vez replicada la clave HMAC, puede habilitar el token encapsulado a través de la consola web:
- Especifique el explorador para
https://serveraddress:port/system/console/configMgr - Busque una entrada llamada Controlador de autenticación de tokens CRX de día y haga clic en ella.
- En la siguiente ventana, marque la casilla Habilitar compatibilidad con token encapsulado cuadro y pulse Guardar.