Compatibilidad con tokens encapsulados

Introducción

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.

chlimage_1-33

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

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:

chlimage_1-34

NOTA

Tenga en cuenta que el token encapsulado se refiere a 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 puedan acceder a la información almacenada debajo de ese usuario.

Por ejemplo, si se crea un nuevo usuario en la instancia de publicación número uno, debido al modo en que funciona el 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 seguirá sin tener éxito.

Configuración del token encapsulado

NOTA

Todos los controladores de autenticación que sincronizan usuarios y dependen de la autenticación de tokens (como SAML y OAuth) solo funcionarán con tokens encapsulados si:

  • 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:

  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 destino a las que desee replicar las claves. Vea más información en "Replicando la clave HMAC" a continuación.
  2. El token encapsulado debe estar habilitado. Esto se puede hacer a través de la Consola Web.

Duplicación de la clave HMAC

Para poder replicar la clave entre instancias, debe:

  1. Acceda a la instancia de AEM, normalmente una instancia de autor, que contiene el material clave que se va a copiar;

  2. Busque la variable 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

    La variable bundle.info 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 HMAC y maestro.

  5. 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
  6. Pegue los dos archivos que ha copiado anteriormente.

  7. Actualizar el paquete criptográfico si la instancia de destino 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 a través de la consola web:

  1. Especifique el explorador para https://serveraddress:port/system/console/configMgr
  2. Busque una entrada llamada Controlador de autenticación de token de Granite de Adobe y haga clic en ella.
  3. En la siguiente ventana, marque la casilla Habilitar compatibilidad con token encapsulado cuadro y pulse Guardar.

En esta página