Autenticación SAML 2.0

Última actualización: 2024-01-25
  • Creado para:
  • Intermediate
    Developer

AEM Obtenga información sobre cómo configurar y autenticar usuarios finales (no autores de) en un IDP compatible con SAML 2.0 de su elección.

AEM ¿Qué SAML es as a Cloud Service para la?

AEM AEM La integración de SAML 2.0 con la publicación (o previsualización) de la, permite a los usuarios finales de una experiencia web basada en la autenticación autenticarse en un IDP (proveedor de identidad) que no es de Adobe AEM y acceder a la misma como un usuario autorizado y con nombre.

AEM Author AEM Publish
Compatibilidad con SAML 2.0
 AEM Comprender el flujo de SAML 2.0 con la ayuda de la aplicación de

AEM El flujo típico de una integración SAML de publicación de es el siguiente:

  1. AEM El usuario realiza una solicitud para publicar el mensaje que indica que se requiere autenticación.
    • El usuario solicita un recurso protegido por CUG/ACL.
    • El usuario solicita un recurso que está sujeto a un requisito de autenticación.
    • AEM El usuario sigue un vínculo a un punto final de inicio de sesión de la (por ejemplo, /system/sling/login) que solicita explícitamente la acción de inicio de sesión.
  2. AEM Hace una petición AuthnRequest al IDP, solicitando al IDP que inicie el proceso de autenticación.
  3. El usuario se autentica en IDP.
    • El IDP solicita credenciales al usuario.
    • El usuario ya se ha autenticado con el IDP y no tiene que proporcionar más credenciales.
  4. IDP genera una afirmación de SAML que contiene los datos del usuario y la firma utilizando el certificado privado del IDP.
  5. IDP envía la afirmación de SAML a través del POST AEM HTTP, a través del explorador web del usuario, a Publicación de.
  6. AEM Publicación recibe la afirmación de SAML y valida la integridad y autenticidad de la afirmación de SAML usando el certificado público IDP.
  7. AEM AEM Publicación de datos administra el registro de usuario de en función de la configuración OSGi de SAML 2.0 y el contenido de la afirmación de SAML.
    • Crea un usuario
    • Sincroniza atributos de usuario
    • AEM Actualizaciones de miembros del grupo de usuarios
  8. AEM AEM La publicación de datos establece el login-token AEM en la respuesta HTTP, que se utiliza para autenticar solicitudes posteriores a la publicación de la.
  9. AEM AEM Publicación de datos redirige al usuario a la dirección URL en la que se publica el documento según lo especificado por el usuario. saml_request_path cookie.

Introducción a la configuración

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

Requisitos previos

Se requiere lo siguiente al configurar la autenticación SAML 2.0:

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

AEM SAML 2.0 solo se admite para autenticar usuarios para la publicación o la vista previa de la. AEM Para administrar la autenticación de Autor de la mediante y IDP, integración del IDP con Adobe IMS.

AEM Instalación del certificado público IDP en el

AEM El certificado público del IDP se añade al Almacén de confianza global y se utiliza para validar que la afirmación de SAML enviada por el IDP es válida.

 Flujo de firma de aserción SAML

SAML 2.0: firma de aserción SAML IDP

  1. El usuario se autentica en IDP.
  2. IDP genera una afirmación de SAML que contiene los datos del usuario.
  3. IDP firma la afirmación de SAML usando el certificado privado de IDP.
  4. IDP inicia un POST AEM HTTP del lado del cliente para publicar el extremo SAML de (.../saml_login) que incluye la afirmación de SAML firmada.
  5. AEM Publish recibe el POST HTTP que contiene la afirmación de SAML firmada, puede validar la firma mediante el certificado público IDP.

Añadir el certificado público IDP al repositorio de confianza global

  1. Obtenga la certificado público del IDP. AEM AEM Este certificado le permite a los validar la afirmación de SAML proporcionada a los usuarios desplazados internos.

    El certificado está en formato PEM y debe tener un aspecto similar al siguiente:

    -----BEGIN CERTIFICATE-----
    MIIC4jCBAcoCCQC33wnybT5QZDANBgkqhkiG9w0BAQsFADAyMQswCQYDVQQGEwJV
    ...
    m0eo2USlSRTVl7QHRTuiuSThHpLKQQ==
    -----END CERTIFICATE-----
    
  2. AEM AEM Inicie sesión en el autor de la como administrador de la aplicación.

  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, guarde la contraseña en un lugar seguro.

  5. Expandir Añadir certificado del archivo CER.

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

  7. Salir Asignar certificado al usuario en blanco.

  8. Seleccione Enviar.

  9. El certificado recién agregado aparece encima de Agregar certificado del archivo CRT sección.

  10. Tome nota de la alias, ya que este valor se utiliza en Configuración OSGi del controlador de autenticación SAML 2.0.

  11. Seleccione Guardar y cerrar.

AEM AEM AEM El repositorio de confianza global está configurado con el certificado público del IDP de Autor de la publicación, pero dado que SAML solo se utiliza en la publicación de la publicación, el repositorio de confianza global debe replicarse para la publicación, de modo que el certificado público de IDP pueda acceder a él desde allí.

AEM Replicar el almacén de confianza global para publicar en el servicio de publicación de

  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. Editar el nuevo Almacén de confianza global paquete.
  4. Seleccione el Filtros y agregue un filtro para la ruta raíz /etc/truststore.
  5. Seleccionar Listo y luego Guardar.
  6. Seleccione el Generar para el Almacén de confianza global paquete.
  7. Una vez creada, seleccione Más > Replicar para activar el nodo Almacén de confianza global (/etc/truststoreAEM ) para publicar en el sitio web.

Crear almacén de claves del servicio de autenticación

Es necesario crear un repositorio de claves para el servicio de autenticación cuando el Propiedad de configuración OSGi del controlador de autenticación SAML 2.0 handleLogout se establece en true o cuando Cifrado de firma AuthnRequest/aserción SAML es obligatorio

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

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

  3. Seleccione el Keystore pestaña.

  4. Cree o abra el repositorio de claves. Si crea un almacén de claves, mantenga la contraseña a salvo.

  5. Seleccione Guardar y cerrar.

  6. Cree un paquete que contenga el authentication-service usuario.

    Utilice la siguiente solución temporal mediante paquetes:

    1. Vaya a Herramientas > Implementación > Paquetes.
    2. Creación de un paquete
      • Nombre del paquete: Authentication Service
      • Versión: 1.0.0
      • Grupo: com.your.company
    3. Editar el nuevo Almacén de claves del servicio de autenticación paquete.
    4. Seleccione el Filtros y agregue un filtro para la ruta raíz /home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore.
      • El <AUTHENTICATION SERVICE UUID> se puede encontrar navegando hasta Herramientas > Seguridad > Usuarios y seleccionando authentication-service usuario. El UUID es la última parte de la dirección URL.
    5. Seleccionar Listo y luego Guardar.
    6. Seleccione el Generar para el Almacén de claves del servicio de autenticación paquete.
    7. Una vez creada, seleccione Más > Replicar AEM para activar el almacén de claves del servicio de autenticación para publicar la.

AEM Instalar par de claves pública y privada de la

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

AEM AEM Se puede configurar la publicación para firmar solicitudes de autenticación (a IDP) y cifrar aserciones de SAML (a). AEM Esto se logra proporcionando una clave privada para la publicación de la publicación de datos, y es una clave pública que coincide con el IDP.

 Comprender el flujo de firma de AuthnRequest (opcional)

AEM AEM AuthnRequest (la solicitud al IDP desde Publicación de datos que inicia el proceso de inicio de sesión) se puede firmar mediante Publicación de datos (Publish) de la. AEM Para ello, el servicio de publicación de firma AuthnRequest con la clave privada, de modo que el IDP valide la firma con la clave pública. AEM Esto garantiza al IDP que AuthnRequest se inició y fue solicitado por Publicación de la publicación de la aplicación, y no por un tercero malintencionado.

SAML 2.0: firma de AuthnRequest de SP

  1. AEM El usuario realiza una petición HTTP para publicar el contenido que da lugar a una petición de autenticación SAML para el IDP.
  2. AEM Publicación de datos genera la solicitud de SAML que se va a enviar al IDP.
  3. AEM AEM La publicación firma la solicitud de SAML con una clave privada de la.
  4. AEM La publicación inicia la petición AuthnRequest, un redireccionamiento del lado del cliente HTTP al IDP que contiene la solicitud SAML firmada.
  5. AEM AEM IDP recibe la Solicitud AuthnRequest y valida la firma con clave pública, lo que garantiza que la Publicación haya iniciado la Solicitud AuthnRequest.
  6. AEM A continuación, Publicación valida la integridad y autenticidad de la afirmación de SAML descifrada utilizando el certificado público IDP.
 Comprender el flujo de cifrado de afirmación de SAML (opcional)

AEM Toda la comunicación HTTP entre IDP y Publicación de la debe ser a través de HTTPS y, por lo tanto, segura de forma predeterminada. Sin embargo, según sea necesario, las afirmaciones de SAML pueden cifrarse en el caso de que se requiera confidencialidad adicional además de la proporcionada por HTTPS. AEM Para ello, el IDP cifra los datos de aserción de SAML utilizando la clave privada y, a la vez, Publicación de datos descifra la aserción de SAML utilizando la clave privada.

SAML 2.0: cifrado de aserción SP SAML

  1. El usuario se autentica en IDP.
  2. IDP genera una afirmación de SAML que contiene los datos del usuario y la firma utilizando el certificado privado del IDP.
  3. AEM AEM IDP cifra la afirmación de SAML con clave pública, lo que requiere que se descifre la clave privada de la.
  4. AEM La afirmación de SAML cifrada se envía mediante el explorador web del usuario a Publicación de la.
  5. AEM AEM Publicación recibe la afirmación de SAML y la descifra utilizando una clave privada
  6. IDP solicita al usuario que se autentique.

Tanto la firma de AuthnRequest como el cifrado de aserción SAML son opcionales; sin embargo, ambos están habilitados, utilizando Propiedad de configuración OSGi del controlador de autenticación SAML 2.0 useEncryption, lo que significa que se pueden usar ambos o ninguno.

AEM Almacén de claves de servicio de autenticación de

  1. Obtenga la clave pública, la clave privada (PKCS#8 en formato DER) y el archivo de cadena de certificados (puede ser la clave pública) utilizados para firmar AuthnRequest y cifre la afirmación de SAML. Las claves las suele proporcionar el equipo de seguridad de la organización de TI.

    • Se puede generar un par de claves autofirmado 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.

    • Uso del openssl método anterior, la clave pública es aem-public.crt archivo.
  3. AEM AEM Inicie sesión en Author como administrador de para cargar la clave privada.

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

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

  6. Seleccione el Keystore pestaña.

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

  8. Seleccionar Añadir clave privada del archivo DER AEM y agregue la clave privada y el archivo de cadena a la lista de archivos que se van a:

    • 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).
      • Uso del openssl método anterior, este es el aem-private-pkcs8.der archivo
    • Seleccionar archivo de cadena de certificados: cargue el archivo de cadena adjunto (puede ser la clave pública).
      • Uso del openssl método anterior, este es el aem-public.crt archivo
    • Seleccionar Enviar
  9. El certificado recién agregado aparece encima de Agregar certificado del archivo CRT sección.

  10. Seleccione Guardar y cerrar.

  11. Cree un paquete que contenga el authentication-service usuario.

    Utilice la siguiente solución temporal mediante paquetes:

    1. Vaya a Herramientas > Implementación > Paquetes.
    2. Creación de un paquete
      • Nombre del paquete: Authentication Service
      • Versión: 1.0.0
      • Grupo: com.your.company
    3. Editar el nuevo Almacén de claves del servicio de autenticación paquete.
    4. Seleccione el Filtros y agregue un filtro para la ruta raíz /home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore.
      • El <AUTHENTICATION SERVICE UUID> se puede encontrar navegando hasta Herramientas > Seguridad > Usuarios y seleccionando authentication-service usuario. El UUID es la última parte de la dirección URL.
    5. Seleccionar Listo y luego Guardar.
    6. Seleccione el Generar para el Almacén de claves del servicio de autenticación paquete.
    7. Una vez creada, seleccione Más > Replicar AEM para activar el almacén de claves del servicio de autenticación para publicar la.

Configurar el controlador de autenticación SAML 2.0

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

 Glosario de configuración OSGi del Controlador de autenticación SAML 2.0

Configuración OSGi del Controlador de autenticación SAML 2.0 de Adobe Granite

Propiedad OSGi Requerido Formato de valor Valor predeterminado Descripción
Rutas path Matriz de cadenas / AEM rutas de acceso de la autenticación para las que se utiliza este controlador.
URL de IDP idpUrl Cadena Dirección URL de IDP a la que se envía la solicitud de autenticación SAML.
Alias de certificado IDP idpCertAlias Cadena AEM Alias del certificado IDP encontrado en el repositorio de confianza global de la organización de seguridad de la red (CLR) de
Redirección HTTP de IDP idpHttpRedirect Booleano false Indica si hay un redireccionamiento HTTP a la URL de IDP en lugar de enviar una AuthnRequest. Configure como. true para la autenticación iniciada por IDP.
Identificador de IDP idpIdentifier Cadena AEM ID de IDP único para garantizar la exclusividad de usuario y grupo de la. Si está vacío, la variable serviceProviderEntityId se utiliza en su lugar.
URL de servicio de consumidor de afirmación assertionConsumerServiceURL Cadena El AssertionConsumerServiceURL Atributo URL en AuthnRequest que especifica dónde <Response> AEM el mensaje debe enviarse a la.
ID de entidad de SP serviceProviderEntityId Cadena AEM AEM Identifica de forma exclusiva a los desplazados internos, por lo general el nombre de host de la.
Cifrado SP useEncryption Booleano true Indica si el IDP cifra las afirmaciones de SAML. Requiere spPrivateKeyAlias y keyStorePassword que se va a establecer.
Alias de clave privada SP spPrivateKeyAlias Cadena El alias de la clave privada en el authentication-service almacén de claves del usuario. Obligatorio si useEncryption se establece en true.
Contraseña del almacén de claves SP keyStorePassword Cadena La contraseña del almacén de claves del usuario del servicio de autenticación. Obligatorio si useEncryption se establece en true.
Redirección predeterminada defaultRedirectUrl Cadena / La URL de redireccionamiento predeterminada después de la autenticación correcta. AEM Puede ser relativo al host de la (por ejemplo, /content/wknd/us/en/html).
Atributo de ID de usuario userIDAttribute Cadena uid AEM Nombre del atributo de aserción de SAML que contiene el ID de usuario del usuario de la. Dejar vacío para utilizar el Subject:NameId.
AEM Crear usuarios de forma automática createUser Booleano true AEM Indica si los usuarios de la se crean con una autenticación correcta.
AEM Ruta intermedia del usuario userIntermediatePath Cadena AEM Al crear usuarios de, este valor se utiliza como ruta intermedia (por ejemplo, /home/users/<userIntermediatePath>/jane@wknd.com). Requiere createUser que se establecerá en true.
AEM Atributos de usuario de synchronizeAttributes Matriz de cadenas AEM Lista de asignaciones de atributos SAML que se almacenarán en el usuario de la, con el formato [ "saml-attribute-name=path/relative/to/user/node" ] (por ejemplo, [ "firstName=profile/givenName" ]). Consulte la AEM lista completa de atributos nativos de la.
AEM Añadir usuario a grupos de addGroupMemberships Booleano true AEM AEM Indica si se agrega automáticamente un usuario de a los grupos de usuarios después de una autenticación correcta.
AEM atributo de pertenencia a grupo groupMembershipAttribute Cadena groupMembership AEM Nombre del atributo de aserción SAML que contiene una lista de grupos de usuarios a los que se debe agregar el usuario. Requiere addGroupMemberships que se establecerá en true.
AEM Grupos predeterminados defaultGroups Matriz de cadenas AEM Siempre se agrega una lista de grupos de usuarios autenticados de la a (por ejemplo, [ "wknd-user" ]). Requiere addGroupMemberships que se establecerá en true.
Formato de directiva de IDP de nombre nameIdFormat Cadena urn:oasis:names:tc:SAML:2.0:nameid-format:transient Valor del parámetro de formato NameIDPolicy que se enviará en el mensaje AuthnRequest.
Almacenar respuesta de SAML storeSAMLResponse Booleano false Indica si la variable samlResponse AEM El valor se almacena en la cq:User nodo.
Controlar cierre de sesión handleLogout Booleano false Indica si este controlador de autenticación SAML administra la solicitud de cierre de sesión. Requiere logoutUrl que se va a establecer.
URL de desconexión logoutUrl Cadena URL de IDP a la que se envía la solicitud de cierre de sesión de SAML. Obligatorio si handleLogout se establece en true.
Tolerancia del reloj clockTolerance Entero 60 AEM La tolerancia de sesgo de reloj de IDP y de (SP) al validar aserciones de SAML.
Método de resumen digestMethod Cadena http://www.w3.org/2001/04/xmlenc#sha256 Algoritmo de resumen que utiliza el IDP al firmar un mensaje SAML.
Método de firma signatureMethod Cadena http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 Algoritmo de firma que utiliza el IDP al firmar un mensaje SAML.
Tipo de sincronización de identidad identitySyncType default o idp default No cambiar from AEM Valor predeterminado para la as a Cloud Service.
Clasificación del servicio service.ranking Entero 5002 Para lo mismo, se prefieren configuraciones de clasificación más altas path.

AEM Atributos de usuario de

AEM utiliza los siguientes atributos de usuario, que se pueden rellenar mediante el synchronizeAttributes en la configuración OSGi del Controlador de autenticación SAML 2.0 de Granite de Adobe. AEM AEM AEM Cualquier atributo de IDP se puede sincronizar con cualquier propiedad de usuario de, pero la asignación a propiedades de atributo de uso de la aplicación de datos (enumeradas a continuación) permite a los usuarios de la aplicación utilizarlas de forma natural.

Atributo de usuario Ruta de propiedad relativa desde rep:User nodo
Título (por ejemplo, Mrs) profile/title
Nombre dado (es decir, nombre) profile/givenName
Apellido (es decir, apellido) profile/familyName
Título de trabajo profile/jobTitle
Dirección de correo electrónico profile/email
Dirección profile/street
Ciudad profile/city
Código postal profile/postalCode
País profile/country
Número de teléfono profile/phoneNumber
Acerca de mí profile/aboutMe
  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 ~ 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 y contener guiones.
  2. Pegue el siguiente JSON en com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json y actualice el archivo wknd referencias 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 Controlador de autenticación SAML 2.0 más arriba para las descripciones de propiedades de configuración

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

Configuraciones de OSGi por entorno (config.publish.dev, config.publish.stage, y config.publish.prod) se puede definir con atributos específicos si la configuración de SAML varía entre entornos.

Usar cifrado

Cuándo cifrar la aserción AuthnRequest y SAML, se requieren las siguientes propiedades: useEncryption, spPrivateKeyAlias, y keyStorePassword. El keyStorePassword contiene una contraseña; por lo tanto, el valor no debe almacenarse en el archivo de configuración OSGi, sino insertarse mediante valores de configuración secretos

 Opcionalmente, actualice la configuración de OSGi para utilizar el cifrado
  1. Abrir /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json en su IDE.

  2. Añadir las tres propiedades useEncryption, spPrivateKeyAlias, y keyStorePassword como se muestra a continuación.

    {
    "path": [ "/content/wknd", "/content/dam/wknd" ],
    "idpCertAlias": "$[env:SAML_IDP_CERT_ALIAS;default=certalias___1234567890]",
    "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/abcdef1235678]",
    "idpUrl": "$[env:SAML_IDP_URL;default=https://dev-5511372.okta.com/app/dev-123567890_aemasacloudservice_1/abcdef1235678/sso/saml]",
    "serviceProviderEntityId": "$[env:SAML_AEM_ID;default=https://publish-p123-e456.adobeaemcloud.com]",
    "useEncryption": true,
    "spPrivateKeyAlias": "$[env:SAML_AEM_KEYSTORE_ALIAS;default=aem-saml-encryption]",
    "keyStorePassword": "$[secret:SAML_AEM_KEYSTORE_PASSWORD]",
    "createUser": true,
    "userIntermediatePath": "wknd/idp"
    "synchronizeAttributes":[
        "firstName=profile/givenName"
    ],
    "addGroupMemberships": true,
    "defaultGroups": [
        "wknd-users"
    ]
    }
    
  3. Las tres propiedades de configuración OSGi necesarias para el cifrado son:

  • useEncryption establezca en true
  • spPrivateKeyAlias contiene el alias de la entrada del almacén de claves para la clave privada utilizada por la integración de SAML.
  • keyStorePassword contiene un Variable de configuración secreta OSGi que contiene el authentication-service contraseña del almacén de claves de usuario.

Configurar el filtro de referente

Durante el proceso de autenticación de SAML, el IDP inicia un POST AEM HTTP del lado del cliente para publicar el de la aplicación de la manera de .../saml_login punto final. AEM AEM Si el IDP y la Publicación de la existen en un origen diferente, se puede publicar el de Filtro de referente se configura mediante la configuración de OSGi para permitir HTTP POST 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 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 de 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 La publicación admite una sola configuración de filtro de referente, por lo que debe combinar los requisitos de configuración de SAML con cualquier configuración existente.

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

Configuración del intercambio de recursos de origen cruzado (CORS)

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

Esta solicitud del POST HTTP Origin AEM El encabezado de suele tener un valor diferente al del host de publicación de, por lo que requiere la configuración de CORS.

AEM Al probar la autenticación SAML en el SDK local de la (localhost:4503), el IDP puede establecer el Origin encabezado a null. Si es así, agregue. "null" a la 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 de su proyecto
    • El identificador después de ~ 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 y contener guiones.
  2. Pegue el siguiente JSON en 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.stage, y config.publish.prod) se puede definir con atributos específicos si alloworigin y allowedpaths varía según el entorno.

AEM Configuración de Dispatcher para permitir POST HTTP de SAML

Después de autenticarse correctamente en el IDP, este organizará un POST AEM HTTP para que vuelva a estar registrado en el registro de la dirección de correo electrónico (HTTPs). /saml_login punto final (configurado en el IDP). Este POST HTTP a /saml_login está bloqueado de forma predeterminada en Dispatcher, por lo que debe permitirse explícitamente el uso de la siguiente regla de Dispatcher:

  1. Abrir dispatcher/src/conf.dispatcher.d/filters/filters.any en su IDE.
  2. Agregue a la parte inferior del archivo una regla de permiso para POST HTTP a 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 .../saml_login los puntos finales no se estropean accidentalmente.

Habilitar la sincronización de datos y encapsular tokens

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

Envíe una solicitud a Asistencia al cliente de Adobe (a través de AdminConsole > Soporte) solicitando:

AEM La sincronización de datos y los tokens encapsulados están habilitados en el servicio de publicación de datos para el programa X y el entorno Y.

Implementación de la configuración SAML

AEM Las configuraciones de OSGi deben enviarse a Git e implementarse para que se puedan usar de forma 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 destino (en este ejemplo, develop), mediante una canalización de implementación de pila completa.

En esta página