Demostración de la integración entre AEM y SAML

AEM proporciona soporte para la solicitud de autenticación SAML 2.0 y actúa como proveedor de servicios SAML. Este artículo proporciona una muestra para instalar y configurar sus pruebas locales para lograr el registro individual web a través o dentro de los límites de la organización.

Ver también la documentación del producto en línea para el gestor de autenticación SAML.

Software utilizado para la configuración

Los binarios utilizados se mencionan a continuación. Puede utilizar el mismo o un equivalente.

Instalación y configuración

Instalación y configuración de LDAP de OpenDS

Siga las instrucciones de instalación de OpenDS. Durante la instalación, elija cargar los datos de prueba para evitar la creación de usuarios. No olvide la contraseña de administrador proporcionada durante la instalación. La siguiente imagen muestra la opción seleccionada durante la instalación.

Instalar IDP Shibboleth

Descomprima el binario descargado (shibboleth-identityprovider-2.4.0-bin.zip) y ejecute el archivo install.bat. La instalación crea el ID de entidad del IdP, los metadatos iniciales, un conjunto básico de archivos de configuración del IdP y un par de claves de certificado autofirmado que se utiliza para firmar/encriptar.

Instalar y configurar Tomcat

1. Descomprima apache-tomcat-6.0.37-windows-x64.zip en cualquier directorio (por ejemplo, C:\demo\appserver\apache-tomcat-6.0.37-windows-x64).

2. Cree un certificado SSL autofirmado.

3. Aplique el certificado a tomcat <TOMCAT_HOME>/conf/server.xml.

4.  Copiar "idp.war" de <SAML_IDP_HOME>/war/idp.war a <TOMCAT_HOME>/webapps

5.  Cree el directorio <TOMCAT_HOME>/endorsed y copie los archivos .jar incluidos en el directorio de origen del IdP en el directorio recién creado.

6.  Prueba rápida: el acceso a https://localhost:8443/idp/profile/Status es correcto.

Configuración de IDP de Shibboleth

1. Modifique <SAML_IDP_HOME>/conf/idp-metadata.xml para asegurarse de que todos los atributos de ubicación apuntan a la aplicación idp en tomcat 8443

2.  Modificar <SAML_IDP_HOME>/conf/attribute-resolver.xml para añadir definición de atributo y cadena de conexión LDAP

3.  Modifique <SAML_IDP_HOME>/conf/handler.xml para eliminar todas las entradas de autenticación, excepto UsernamePassword y PreviousSession.

4.  Modifique <SAML_IDP_HOME>/conf/logging.xml para un rastreo detallado de errores.

5.  Modificar <SAML_IDP_HOME>/conf/login.config.

6.  Modificar <SAML_IDP_HOME>/conf/relying-party.xml

7.  Modifique /conf/attribute-filter.xml para liberar el atributo UID y el grupo.  

8.  Añada el siguiente archivo de metadatos en <SAML_IDP_HOME>/metadata/adobecq.xml.

Configurar AEM

1.  Instale AEM siguiendo http://dev.day.com/docs/en/cq/current/deploying/installing_cq.html.

2.  En /etc/key en el repositorio, cree un nodo llamado saml. Dentro de este nodo, añada una nueva propiedad binaria llamada idp_cert para el certificado público del IdP.  Es decir, suba el archivo desde <SAML_IDP_HOME>/credentials/idp.crt.

3.  Configurar el Gestor de autenticación.

4.  Configurar ReferrerFilter.

Verificación

1.  Haciendo una solicitud a AEM en http://<host>:<port>/ redirige a la página de inicio de sesión de IDP.

2.  Inicie sesión como usuario.2 con una contraseña como "contraseña" que llevará a la página principal de AEM. Vea la instantánea de la respuesta del rastreador saml y la creación automática de usuarios crx a continuación:

Mejora con AEM 6+

Con AEM 6 Sp1 en adelante, se agregó soporte para

• Capacidad de flujo de cierre único (cierre de sesión)
• Sincronizar atributos
• Grupo predeterminado configurable

La siguiente sección proporciona la actualización requerida en la demostración de configuración anterior para probar localmente la salida y sincronización del atributo de correo.

Actualizaciones de configuración en IDP Shibboleth

1.  Modificar <SAML_IDP_HOME>/conf/attribute-filter.xml y <SAML_IDP_HOME>/conf/attribute-resolver.xml para liberar el correo de atributo

2.  Modifique el archivo de metadatos en <SAML_IDP_HOME>/metadata/adobecq.xml para incluir SingleSignoutService

Actualizaciones de configuración en AEM

1.  Bajo /etc/key/saml en el repositorio agregue una nueva propiedad binaria llamada "private" que contiene la clave para el certificado público del archivo de metadatos (adobecq.xml).  Es decir, suba el archivo demoprivatekey.pem desde el paquete de descarga de la demo.

2.  Actualizar el gestor de autenticación con la dirección de cierre de sesión y sincronizar el atributo.

Verificación

1.  Inicie sesión en AEM en http://<port>:<port>/ utilizando user.0 y, a continuación, cierre la sesión para redirigir a la página de inicio de sesión de IDP.  

2.  La propiedad Mail está sincronizada.

Limitaciones   

El usuario debe existir en AEM
Los usuarios que inician sesión a través del gestor deben existir, o si faltan, deben crearse en AEM ("Autocreate CRX Users" debe ser verificado). Esto se debe a que el marco de autenticación de Sling, del que forma parte SamlAuthenticationHandler, extrae las credenciales de usuario de SAMLResponse e inicia sesión en el repositorio JCR utilizando dichas credenciales.

Acceso anónimo en todo el sitio con autenticación opcional
El gestor de autenticación se basa en la protección del contenido contra el acceso anónimo a través de la configuración de la ruta. Si todas las páginas del sitio de AEM necesitan ser accesibles de forma anónima, pero la autenticación también necesita ser una opción, el valor de configuración de la ruta se puede establecer en una ruta inexistente. Esto permitirá la autenticación SAML, pero también permitirá el acceso anónimo a todas las páginas del sitio. Si se utiliza esta estrategia, asegúrese de que SAMLReponse se publica en la ruta saml_login correcta (ver el siguiente punto).

La configuración de la ruta y saml_login
La SAMLResponse del IdP se debe publicar en la página "saml_login". Sin embargo, la página 'saml_login' debe estar dentro de la ruta que protege el gestor de autenticación (es decir, la configuración de la ruta). Por ejemplo, si la configuración de la ruta es '/', el IdP puede publicar en http://localhost:4502/saml_login. Si la ruta es /content/geometrixx, el IdP puede publicar en http://localhost:4502/content/geometrixx/saml_login o http://localhost:4502/content/geometrixx/does-not-exist/saml_login, pero http://localhost:4502/content/saml_login no funcionará.

Acceso iniciado de IdP y RelayState
En SP1, asegurarse de que el usuario vuelva a la página en la que se encontraba antes de iniciar sesión se realiza con la cookie saml_request_path, y no con el parámetro típico de RelayState que se encuentra en la mayoría de las implementaciones de SSO. Por lo tanto, aunque la autenticación iniciada por IdP terminará con éxito, el usuario final no será enviado a la página especificada por RelayState. Por consiguiente, si se implementa un enlace de inicio de sesión personalizado en una página de AEM (inicio de sesión de SP), asegúrese de configurar la cookie saml_request_path antes de enviar el navegador al IdP.

Error de "No se encontró ningún recurso"
Lo más probable es que esto se deba a que el usuario que ha iniciado sesión no tiene los permisos adecuados para ver la página. Para resolver este problema, asegúrese de que el usuario de SSO tiene permisos de lectura para carpetas como /content. Esto se logra configurando el gestor de autenticación para agregar usuarios de SSO a un grupo de usuarios que tenga todos los permisos necesarios.

Descargar

Las credenciales de acceso de IdP, las credenciales de cifrado, los archivos de configuración y los metadatos utilizados en este script de demostración se pueden descargar aquí.