Autenticación SAML 2.0

Aprenda a configurar y autenticar usuarios finales (no AEM autores) en un IDP compatible con SAML 2.0 de su elección.

¿Qué SAML para AEM as a Cloud Service?

La integración de SAML 2.0 con AEM Publish (o Preview) permite a los usuarios finales de una experiencia web basada en AEM autenticarse en un IDP que no sea de Adobe (Proveedor de identidad) y acceder a AEM como usuario autorizado con nombre.

Introducción a la configuración

Este vídeo explica cómo configurar la integración de SAML 2.0 con AEM servicio de publicación as a Cloud Service y cómo usar Okta como IDP.

Requisitos previos

A la hora de configurar la autenticación SAML 2.0, es necesario lo siguiente:

• Acceso del administrador de implementación a Cloud Manager
• AEM acceso del administrador a AEM entorno as a Cloud Service
• Acceso del administrador al IDP
• Opcionalmente, puede acceder a un par de claves pública y privada que se utiliza para cifrar cargas de SAML

SAML 2.0 solo es compatible para autenticar usuarios en AEM Publish o Preview. Para administrar la autenticación de AEM Author mediante y IDP, integrar el IDP con Adobe IMS.

Instalar el certificado público IDP en AEM

El certificado público del IDP se agrega a AEM Global Trust Store, y se usa para validar la afirmación SAML enviada por el IDP es válida.

1. Obtenga la variable certificado público del IDP. Este certificado permite AEM validar la afirmación de SAML proporcionada a AEM por el IDP.

   El certificado está en formato PEM y debe parecerse a:

   -----BEGIN CERTIFICATE-----
   MIIC4jCBAcoCCQC33wnybT5QZDANBgkqhkiG9w0BAQsFADAyMQswCQYDVQQGEwJV
   ...
   m0eo2USlSRTVl7QHRTuiuSThHpLKQQ==
   -----END CERTIFICATE-----
   

2. Inicie sesión en AEM Author como administrador AEM.

3. Vaya a Herramientas > Seguridad > Almacén de confianza.

4. Cree o abra el almacén de confianza global. Si crea un almacén de confianza global, almacene la contraseña en algún lugar seguro.

5. Expandir Añadir certificado del archivo CER.

6. Select Seleccionar archivo de certificado y cargue el archivo de certificado proporcionado por el IDP.

7. Leave Asignar certificado al usuario en blanco.

8. Seleccione Enviar.

9. El certificado recién agregado aparece encima de la variable Añadir certificado del archivo CRT para obtener más información.

10. Tenga en cuenta que alias, ya que este valor se utiliza en la variable Configuración OSGi del gestor de autenticación SAML 2.0.

11. Select Guardar y cerrar.

El almacén de confianza global está configurado con el certificado público del IDP en AEM Author, pero como SAML solo se utiliza en AEM Publish, el almacén de confianza global debe duplicarse en AEM Publish para que el certificado público IDP sea accesible allí.

1. Vaya a Herramientas > Implementación > Paquetes.
2. Creación de un paquete
   • Nombre del paquete: Global Trust Store
   • Versión: 1.0.0
   • Grupo: com.your.company
3. Edite el nuevo Almacén de confianza global paquete.
4. Seleccione el Filtros y agregue un filtro para la ruta raíz /etc/truststore.
5. Select Listo y luego Guardar.
6. Seleccione el Generar para la variable Almacén de confianza global paquete.
7. Una vez creado, seleccione Más > Replicar para activar el nodo Almacén de confianza global (/etc/truststore) a AEM Publish.

Instalar AEM par de claves pública y privada

La instalación del par de claves pública y privada AEM es opcional

AEM Publish puede configurarse para firmar AuthnRequests (en IDP) y cifrar aserciones SAML (en AEM). Esto se logra proporcionando una clave privada a AEM Publish y es una clave pública coincidente con el IDP.

Tanto la firma de AuthnRequest como el cifrado de aserción SAML son opcionales, aunque ambos están habilitados, usando la variable Controlador de autenticación SAML 2.0, propiedad de configuración OSGi useEncryption, lo que significa que se pueden utilizar ambos o ninguno de ellos.

1. Obtenga la clave pública, la clave privada (PKCS#8 en formato DER) y el archivo de cadena de certificado (puede ser la clave pública) utilizados para firmar AuthnRequest y cifrar la aserción SAML. Normalmente, las claves las proporciona el equipo de seguridad de la organización de TI.

   • Se puede generar un par de claves con firma personal mediante openssl:

   $ openssl req -x509 -sha256 -days 365 -newkey rsa:4096 -keyout aem-private.key -out aem-public.crt
   
   # Provide a password (keep in safe place), and other requested certificate information
   
   # Convert the keys to AEM's required format
   $ openssl rsa -in aem-private.key -outform der -out aem-private.der
   $ openssl pkcs8 -topk8 -inform der -nocrypt -in aem-private.der -outform der -out aem-private-pkcs8.der
   

2. Cargue la clave pública al IDP.

   • Al usar la variable openssl método anterior, la clave pública es la variable aem-public.crt archivo.

3. Inicie sesión en AEM Author como administrador AEM para cargar la clave privada.

4. Vaya a Herramientas > Seguridad > Almacén de confianza y seleccione authentication-service y seleccione Propiedades en la barra de acciones superior.

5. Vaya a Herramientas > Seguridad > Usuarios y seleccione authentication-service y seleccione Propiedades en la barra de acciones superior.

6. Seleccione el Almacén de claves pestaña .

7. Cree o abra el almacén de claves. Si crea un almacén de claves, mantenga la contraseña segura.

8. Select Añadir clave privada del archivo DER y añada la clave privada y el archivo de cadena a AEM:

   • Alias: Proporcione un nombre significativo, a menudo el nombre del IDP.
   • Archivo de clave privada: Cargue el archivo de clave privada (PKCS#8 en formato DER).
     • Al usar la variable openssl método anterior: aem-private-pkcs8.der file
   • Seleccionar archivo de cadena de certificado: Cargue el archivo de cadena que lo acompaña (puede ser la clave pública).
     • Al usar la variable openssl método anterior: aem-public.crt file
   • Seleccione Enviar

9. El certificado recién agregado aparece encima de la variable Añadir certificado del archivo CRT para obtener más información.

   • Tenga en cuenta que alias ya que se utiliza en la variable Controlador de autenticación SAML 2.0 Configuración OSGi

10. Select Guardar y cerrar.

11. Select authentication-service y seleccione Activar en la barra de acciones superior.

Configuración del controlador de autenticación SAML 2.0

AEM configuración de SAML se realiza mediante la variable Controlador de autenticación de Adobe Granite SAML 2.0 Configuración de OSGi.
La configuración es una configuración de fábrica de OSGi, lo que significa que un único servicio de publicación as a Cloud Service AEM puede tener varias configuraciones de SAML que cubren árboles de recursos discretos del repositorio; esto resulta útil para implementaciones de AEM en varios sitios.

1. Cree un archivo de configuración OSGi en su proyecto en /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json y abra en su IDE.

   • Cambiar /wknd-examples/ a su /<project name>/
   • El identificador después de la variable ~ en el nombre de archivo debe identificar de forma exclusiva esta configuración, por lo que puede ser el nombre del IDP, como ...~okta.cfg.json. El valor debe ser alfanumérico con guiones.

2. Pegue el siguiente JSON en el com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json y actualice la variable wknd hace referencia a según sea necesario.

   {
       "path": [ "/content/wknd", "/content/dam/wknd" ],
       "idpCertAlias": "$[env:SAML_IDP_CERT_ALIAS;default=certalias___1652125559800]",
       "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/exk4z55r44Jz9C6am5d7]",
       "idpUrl": "$[env:SAML_IDP_URL;default=https://dev-5511372.okta.com/app/dev-5511372_aemasacloudservice_1/exk4z55r44Jz9C6am5d7/sso/saml]",
       "serviceProviderEntityId": "$[env:SAML_AEM_ID;default=https://publish-p123-e456.adobeaemcloud.com]",
       "useEncryption": false,
       "createUser": true,
       "userIntermediatePath": "wknd/idp",
       "synchronizeAttributes":[
           "firstName=profile/givenName"
       ],
       "addGroupMemberships": true,
       "defaultGroups": [
           "wknd-users"
       ]
   }
   

3. Actualice los valores según sea necesario en el proyecto. Consulte la Glosario de configuración OSGi del gestor de autenticación SAML 2.0 arriba para descripciones de propiedades de configuración

4. Se recomienda, pero no es obligatorio, utilizar las variables de entorno OSGi y los secretos, cuando los valores pueden cambiar fuera de sincronización con el ciclo de lanzamiento o cuando los valores difieren entre tipos de entorno/niveles de servicio similares. Los valores predeterminados se pueden configurar utilizando la variable $[env:..;default=the-default-value]" como se muestra arriba.

Configuraciones de OSGi por entorno (config.publish.dev, config.publish.stagey config.publish.prod) se puede definir con atributos específicos si la configuración de SAML varía según el entorno.

Usar cifrado

When cifrado de la afirmación AuthnRequest y SAML, se requieren las siguientes propiedades: useEncryption, spPrivateKeyAliasy keyStorePassword. La variable keyStorePassword contiene una contraseña, por lo que el valor no debe almacenarse en el archivo de configuración OSGi, sino insertarse mediante valores de configuración secreta

Configurar el filtro Referente

Durante el proceso de autenticación SAML, el IDP inicia un POST HTTP del lado del cliente en AEM Publish .../saml_login punto final. Si el IDP y AEM Publish existen en un origen diferente, AEM Publish Filtro de referente se configura mediante la configuración OSGi para permitir HTTP POSTs desde el origen del IDP.

1. Cree (o edite) un archivo de configuración OSGi en su proyecto en /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/org.apache.sling.security.impl.ReferrerFilter.cfg.json.

   • Cambiar /wknd-examples/ a su /<project name>/

2. Asegúrese de que la variable allow.empty el valor se establece en true, el allow.hosts (o si lo prefiere, allow.hosts.regexp) contiene el origen del IDP, y filter.methods incluye POST. La configuración OSGi debe ser similar a:

   {
       "allow.empty": true,
       "allow.hosts.regexp": [ ],
       "allow.hosts": [
           "$[env:SAML_IDP_REFERRER;default=dev-123567890.okta.com]"
       ],
       "filter.methods": [
           "POST",
       ],
       "exclude.agents.regexp": [ ]
   }
   

AEM Publish admite una configuración de filtro de referente única, por lo que combine los requisitos de configuración de SAML con cualquier configuración existente.

Configuraciones de OSGi por entorno (config.publish.dev, config.publish.stagey config.publish.prod) se puede definir con atributos específicos si la variable allow.hosts (o allow.hosts.regex) varían entre entornos.

Configurar el intercambio de recursos de origen cruzado (CORS)

Durante el proceso de autenticación SAML, el IDP inicia un POST HTTP del lado del cliente en AEM Publish .../saml_login punto final. Si el IDP y AEM Publish existen en diferentes hosts o dominios, AEM Publish CRoss-Origin Resource Sharing (CORS) debe configurarse para permitir HTTP POST del host/dominio del IDP.

La solicitud de este POST HTTP Origin generalmente, el encabezado tiene un valor diferente al host de AEM Publish, lo que requiere la configuración de CORS.

Al probar la autenticación SAML en el SDK AEM local (localhost:4503), el IDP puede configurar el Origin Encabezado a null. Si es así, agregue "null" a alloworigin lista.

1. Cree un archivo de configuración OSGi en su proyecto en /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.cors.impl.CORSPolicyImpl~saml.cfg.json
   • Cambiar /wknd-examples/ al nombre del proyecto
   • El identificador después de la variable ~ en el nombre de archivo debe identificar de forma exclusiva esta configuración, por lo que puede ser el nombre del IDP, como ...CORSPolicyImpl~okta.cfg.json. El valor debe ser alfanumérico con guiones.
2. Pegue el siguiente JSON en el com.adobe.granite.cors.impl.CORSPolicyImpl~...cfg.json archivo.

{
    "alloworigin": [
        "$[env:SAML_IDP_ORIGIN;default=https://dev-1234567890.okta.com]",
        "null"
    ],
    "allowedpaths": [
        ".*/saml_login"
    ],
    "supportedmethods": [
        "POST"
    ]
}

Configuraciones de OSGi por entorno (config.publish.dev, config.publish.stagey config.publish.prod) se puede definir con atributos específicos si la variable alloworigin y allowedpaths varía según el entorno.

Configure AEM Dispatcher para permitir POST HTTP SAML

Después de la autenticación correcta para el IDP, el IDP orquestará un POST HTTP de vuelta a AEM registrado /saml_login punto final (configurado en el IDP). Este POST HTTP a /saml_login está bloqueado de forma predeterminada en Dispatcher, por lo que se debe permitir explícitamente mediante la siguiente regla de Dispatcher:

1. Apertura dispatcher/src/conf.dispatcher.d/filters/filters.any en su IDE.
2. Agregue a la parte inferior del archivo una regla de permiso para HTTP POST a las direcciones URL que terminen con /saml_login.

...

# Allow SAML HTTP POST to ../saml_login end points
/0190 { /type "allow" /method "POST" /url "*/saml_login" }

Si la reescritura de URL en el servidor web Apache está configurada (dispatcher/src/conf.d/rewrites/rewrite.rules), asegúrese de que las solicitudes a la variable .../saml_login los puntos finales no se manipulan accidentalmente.

Habilitar la sincronización de datos y encapsular tokens

Una vez que el flujo de autenticación SAML crea un usuario en AEM Publish, el nodo de usuario AEM se puede autenticar en el nivel de servicio de AEM Publish.
Esto requiere sincronización de datos y tokens encapsulados para que la compatibilidad con Adobe la habilite en el servicio AEM Publish.

Envíe una solicitud al servicio de asistencia al cliente de Adobe (a través de Consola de administración > Asistencia) solicitando:

La sincronización de datos y los tokens encapsulados están activados en el servicio AEM Publish para el Programa X y el Entorno Y.

Implementación de la configuración de SAML

Las configuraciones de OSGi deben comprometerse con Git e implementarse en AEM as a Cloud Service mediante Cloud Manager.

$ git remote -v
adobe   https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (fetch)
adobe   https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (push)
$ git add .
$ git commit -m "SAML 2.0 configurations"
$ git push adobe saml-auth:develop

Implemente la rama Git de Cloud Manager de Target (en este ejemplo, develop), utilizando una canalización de implementación de pila completa.

Recursos de Business.Adobe.com