Autenticação SAML 2.0 saml-2-0-authentication

Saiba como configurar e autenticar usuários finais (não autores de AEM) em um IDP compatível com SAML 2.0 de sua escolha.

Qual SAML para AEM as a Cloud Service?

A integração do SAML 2.0 com o AEM Publish (ou Pré-visualização) permite que os usuários finais de uma experiência da Web baseada em AEM se autentiquem em um IDP (Provedor de identidade) não Adobe AEM e acessem o como um usuário nomeado e autorizado.

Autor do AEM
Publicação no AEM
Suporte ao SAML 2.0
Entender o fluxo do SAML 2.0 com AEM

O fluxo típico de uma integração AEM Publish SAML é o seguinte:

  1. O usuário faz uma solicitação ao AEM Publish indicando que a autenticação é necessária.

    • O usuário solicita um recurso protegido CUGs/ACL.
    • O usuário solicita um recurso que está sujeito a um Requisito de autenticação.
    • O usuário segue um link para o ponto de extremidade de logon do AEM (ou seja, /system/sling/login) que solicita explicitamente a ação de logon.
  2. O AEM faz uma AuthnRequest ao IDP, solicitando que o IDP inicie o processo de autenticação.

  3. O usuário é autenticado no IDP.

    • O IDP solicita as credenciais ao usuário.
    • O usuário já está autenticado com o IDP e não precisa fornecer mais credenciais.
  4. O IDP gera uma asserção SAML contendo os dados do usuário e a assina usando o certificado privado do IDP.

  5. O IDP envia a asserção SAML via HTTP POST, por meio do navegador da Web do usuário, para o AEM Publish.

  6. O AEM Publish recebe a declaração SAML e valida a integridade e autenticidade da declaração SAML usando o certificado público IDP.

  7. O AEM Publish gerencia o registro de usuário do AEM com base na configuração OSGi do SAML 2.0 e no conteúdo da Asserção SAML.

    • Cria usuário
    • Sincroniza os atributos do usuário
    • Atualiza a associação do grupo de usuários AEM
  8. O AEM Publish define o cookie AEM AEM login-token na resposta HTTP, que é usada para autenticar solicitações subsequentes ao Publish.

  9. O AEM Publish redireciona o usuário para URL no AEM Publish conforme especificado pelo cookie saml_request_path.

Passo a passo da configuração

Este vídeo aborda a configuração da integração do SAML 2.0 com o serviço AEM as a Cloud Service Publish e o uso do Okta como o IDP.

Pré-requisitos

Os seguintes itens são necessários ao configurar a autenticação SAML 2.0:

  • Acesso do gerente de implantação ao Cloud Manager
  • Acesso do administrador do AEM ao ambiente do AEM as a Cloud Service
  • Acesso de administrador ao IDP
  • Opcionalmente, acesso a um par de chaves público/privado usado para criptografar cargas SAML

O SAML 2.0 é compatível apenas com a autenticação de usuários para AEM Publish ou Pré-visualização. Para gerenciar a autenticação do AEM Author usando e o IDP, integre o IDP ao Adobe IMS.

Instalar certificado público do IDP no AEM

O certificado público do IDP é adicionado ao AEM Global Trust Store e usado para validar se a declaração SAML enviada pelo IDP é válida.

Fluxo de assinatura de asserção SAML

SAML 2.0 - Assinatura de Asserção SAML IDP

  1. O usuário é autenticado no IDP.
  2. O IDP gera uma asserção SAML contendo os dados do usuário.
  3. O IDP assina a asserção SAML usando o certificado privado do IDP.
  4. O IDP inicia um POST HTTP do lado do cliente para o ponto de extremidade SAML (.../saml_login) do AEM Publish que inclui a declaração SAML assinada.
  5. O AEM Publish recebe o POST HTTP contendo a asserção SAML assinada, que pode validar a assinatura usando o certificado público IDP.

Adicionar o certificado público IDP ao Repositório Global de Confiança

  1. Obtenha o arquivo de certificado público do IDP. Esse certificado permite que o AEM valide a asserção SAML fornecida ao AEM pelo IDP.

    O certificado está no formato PEM e deve se parecer com:

    code language-none
    -----BEGIN CERTIFICATE-----
    MIIC4jCBAcoCCQC33wnybT5QZDANBgkqhkiG9w0BAQsFADAyMQswCQYDVQQGEwJV
    ...
    m0eo2USlSRTVl7QHRTuiuSThHpLKQQ==
    -----END CERTIFICATE-----
    
  2. Faça logon no AEM Author como um Administrador do AEM.

  3. Navegue até Ferramentas > Segurança > Armazenamento confiável.

  4. Crie ou abra o Armazenamento global de confiança. Se estiver criando um armazenamento global de confiança, armazene a senha em algum lugar seguro.

  5. Expanda Adicionar certificado do arquivo CER.

  6. Selecione Selecionar arquivo de certificado e carregue o arquivo de certificado fornecido pelo IDP.

  7. Deixe Mapear certificado para o usuário em branco.

  8. Selecione Enviar.

  9. O certificado adicionado recentemente aparece acima da seção Adicionar certificado do arquivo CRT.

  10. Anote o alias, pois esse valor é usado na configuração OSGi do Manipulador de Autenticação do SAML 2.0.

  11. Selecione Salvar e fechar.

O armazenamento global de confiança está configurado com o certificado público do IDP no AEM Author, mas como o SAML é usado apenas no AEM Publish AEM, o armazenamento global de confiança deve ser replicado para o Publish para que o certificado público do IDP esteja acessível lá.

Replicar o Repositório de Confiança Global para AEM Publish

  1. Navegue até Ferramentas > Implantação > Pacotes.

  2. Criar um pacote

    • Nome do pacote: Global Trust Store
    • Versão: 1.0.0
    • Grupo: com.your.company
  3. Edite o novo pacote Armazenamento Global de Confiança.

  4. Selecione a guia Filtros e adicione um filtro para o caminho raiz /etc/truststore.

  5. Selecione Concluído e depois Salvar.

  6. Selecione o botão Build para o pacote Armazenamento global de confiança.

  7. Depois de criado, selecione Mais > Replicar para ativar o nó de Repositório de Confiança Global (/etc/truststore) para AEM Publish.

Criar armazenamento de chaves do serviço de autenticação authentication-service-keystore

A criação de um keystore para o serviço de autenticação é necessária quando a propriedade de configuração OSGi do manipulador de autenticação SAML 2.0 handleLogout está definida como true ou quando a criptografia de assinatura AuthnRequest/asserção SAML é necessária

  1. Faça logon no AEM Author como um Administrador AEM para fazer upload da chave privada.

  2. Navegue até Ferramentas > Segurança > Usuários, selecione o usuário serviço de autenticação e selecione Propriedades na barra de ações superior.

  3. Selecione a guia Armazenamento de chaves.

  4. Crie ou abra o armazenamento de chaves. Se estiver criando um armazenamento de chaves, mantenha a senha segura.

  5. Selecione Salvar e fechar.

  6. Crie um pacote contendo o usuário authentication-service atualizado.

    Use a seguinte solução temporária usando pacotes:

    1. Navegue até Ferramentas > Implantação > Pacotes.

    2. Criar um pacote

      • Nome do pacote: Authentication Service
      • Versão: 1.0.0
      • Grupo: com.your.company
    3. Edite o novo pacote Authentication Service Key Store.

    4. Selecione a guia Filtros e adicione um filtro para o caminho raiz /home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore.

      • O <AUTHENTICATION SERVICE UUID> pode ser encontrado navegando até Ferramentas > Segurança > Usuários e selecionando o usuário serviço-autenticação. A UUID é a última parte do URL.
    5. Selecione Concluído e depois Salvar.

    6. Selecione o botão Build para o pacote Authentication Service Key Store.

    7. Depois de criado, selecione Mais > Replicar para ativar o armazenamento de chaves do Serviço de Autenticação para o AEM Publish.

Instalar par de chave pública/privada do AEM install-aem-public-private-key-pair

A instalação do par de chaves públicas/privadas do AEM é opcional

O AEM Publish pode ser configurado para assinar AuthnRequests (para IDP) e criptografar asserções SAML (para AEM). Isso é feito fornecendo uma chave privada para o AEM Publish, e sua chave pública é compatível com o IDP.

Entender o fluxo de assinatura AuthnRequest (opcional)

A AuthnRequest (a solicitação ao IDP do AEM Publish que inicia o processo de logon) pode ser assinada pelo AEM Publish. Para fazer isso, o AEM Publish assina a AuthnRequest usando a chave privada, e garante que o IDP valida a assinatura usando a chave pública. Isso garante ao IDP que o AuthnRequest foi iniciado e solicitado pelo AEM Publish, e não por terceiros mal-intencionados.

SAML 2.0 - Assinatura AuthnRequest do SP

  1. O usuário faz uma solicitação HTTP ao AEM Publish que resulta em uma solicitação de autenticação SAML para o IDP.
  2. O AEM Publish gera a solicitação SAML para enviar ao IDP.
  3. O AEM Publish assina a solicitação SAML usando a chave privada do AEM.
  4. O AEM Publish inicia o AuthnRequest, um redirecionamento HTTP do lado do cliente para o IDP que contém a solicitação SAML assinada.
  5. O IDP recebe a AuthnRequest e valida a assinatura usando a chave pública do AEM, garantindo que o AEM Publish tenha iniciado a AuthnRequest.
  6. O AEM Publish valida a integridade e a autenticidade da asserção SAML descriptografada usando o certificado público IDP.
Compreender o fluxo de criptografia de asserção SAML (opcional)

Toda a comunicação HTTP entre o IDP e o AEM Publish deve ser por HTTPS e, portanto, segura por padrão. No entanto, conforme necessário, as afirmações SAML podem ser criptografadas caso seja necessário confidencialidade extra além da fornecida por HTTPS. Para fazer isso, o IDP criptografa os dados da SAML Assertion usando a chave privada e o AEM Publish descriptografa a asserção SAML usando a chave privada.

SAML 2.0 - Criptografia de Asserção SAML do SP

  1. O usuário é autenticado no IDP.
  2. O IDP gera uma asserção SAML contendo os dados do usuário e a assina usando o certificado privado do IDP.
  3. O IDP criptografa a asserção SAML com a chave pública do AEM, que requer a descriptografia da chave privada AEM.
  4. A asserção SAML criptografada é enviada por meio do navegador web do usuário para o AEM Publish.
  5. O AEM Publish recebe a asserção SAML e a decodifica usando a chave privada do AEM.
  6. O IDP solicita a autenticação do usuário.

A assinatura AuthnRequest e a criptografia de asserção SAML são opcionais, no entanto, ambas estão habilitadas, usando a propriedade de configuração OSGi do manipulador de autenticação SAML 2.0 useEncryption, o que significa que ambas ou nenhuma das duas podem ser usadas.

repositório de chaves de serviço de autenticação do AEM

  1. Obtenha a chave pública, a chave privada (PKCS#8 no formato DER) e o arquivo da cadeia de certificados (pode ser a chave pública) usados para assinar o AuthnRequest e criptografar a asserção SAML. Normalmente, as chaves são fornecidas pela equipe de segurança da organização de TI.

    • Um par de chaves autoassinado pode ser gerado usando openssl:
    code language-none
    $ 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. Faça upload da chave pública para o IDP.

    • Usando o método openssl acima, a chave pública é o arquivo aem-public.crt.
  3. Faça logon no AEM Author como um Administrador AEM para fazer upload da chave privada.

  4. Navegue até Ferramentas > Segurança > Armazenamento de confiança, selecione o usuário serviço de autenticação e selecione Propriedades na barra de ação superior.

  5. Navegue até Ferramentas > Segurança > Usuários, selecione o usuário serviço de autenticação e selecione Propriedades na barra de ações superior.

  6. Selecione a guia Armazenamento de chaves.

  7. Crie ou abra o armazenamento de chaves. Se estiver criando um armazenamento de chaves, mantenha a senha segura.

  8. Selecione Adicionar chave privada do arquivo DER e adicione a chave privada e o arquivo de cadeia ao AEM:

    • Alias: forneça um nome significativo, geralmente o nome do IDP.
    • Arquivo de chave privada: carrega o arquivo de chave privada (PKCS#8 no formato DER).
      • Usando o método openssl acima, este é o arquivo aem-private-pkcs8.der
    • Selecionar arquivo da cadeia de certificados: carregue o arquivo da cadeia que o acompanha (essa pode ser a chave pública).
      • Usando o método openssl acima, este é o arquivo aem-public.crt
    • Selecionar Enviar
  9. O certificado adicionado recentemente aparece acima da seção Adicionar certificado do arquivo CRT.

  10. Selecione Salvar e fechar.

  11. Crie um pacote contendo o usuário authentication-service atualizado.

    Use a seguinte solução temporária usando pacotes:

    1. Navegue até Ferramentas > Implantação > Pacotes.

    2. Criar um pacote

      • Nome do pacote: Authentication Service
      • Versão: 1.0.0
      • Grupo: com.your.company
    3. Edite o novo pacote Authentication Service Key Store.

    4. Selecione a guia Filtros e adicione um filtro para o caminho raiz /home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore.

      • O <AUTHENTICATION SERVICE UUID> pode ser encontrado navegando até Ferramentas > Segurança > Usuários e selecionando o usuário serviço-autenticação. A UUID é a última parte do URL.
    5. Selecione Concluído e depois Salvar.

    6. Selecione o botão Build para o pacote Authentication Service Key Store.

    7. Depois de criado, selecione Mais > Replicar para ativar o armazenamento de chaves do Serviço de Autenticação para o AEM Publish.

Configurar o manipulador de autenticação SAML 2.0 configure-saml-2-0-authentication-handler

A configuração SAML do AEM é executada por meio do Manipulador de autenticação Adobe Granite SAML 2.0 da configuração OSGi.
A configuração é uma configuração de fábrica OSGi, o que significa que um único serviço AEM as a Cloud Service Publish pode ter várias configurações SAML cobrindo árvores de recursos discretas do repositório; isso é útil para implantações do AEM em vários locais.

Glossário de configuração OSGi do Manipulador de autenticação SAML 2.0

Configuração OSGi do Manipulador de autenticação SAML 2.0 do Adobe Granite configure-saml-2-0-authentication-handler-osgi-configuration

table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 14-row-6 15-row-6 16-row-6 17-row-6 18-row-6 19-row-6 20-row-6 21-row-6 22-row-6 23-row-6 24-row-6 25-row-6 26-row-6 27-row-6 3-align-center 4-align-center 10-align-center 11-align-center 17-align-center 18-align-center 24-align-center 25-align-center 31-align-center 32-align-center 38-align-center 39-align-center 45-align-center 46-align-center 52-align-center 53-align-center 59-align-center 60-align-center 66-align-center 67-align-center 73-align-center 74-align-center 80-align-center 81-align-center 87-align-center 88-align-center 94-align-center 95-align-center 101-align-center 102-align-center 108-align-center 109-align-center 115-align-center 116-align-center 122-align-center 123-align-center 129-align-center 130-align-center 136-align-center 137-align-center 143-align-center 144-align-center 150-align-center 151-align-center 157-align-center 158-align-center 164-align-center 165-align-center 171-align-center 172-align-center 178-align-center 179-align-center 185-align-center 186-align-center 192-align-center 193-align-center
Propriedade OSGi Obrigatório Formato do valor Valor padrão Descrição
Caminhos path Matriz de string / Caminhos de AEM para os quais esse manipulador de autenticação é usado.
URL DO IDP idpUrl String URL do IDP para o qual a solicitação de autenticação SAML é enviada.
Alias do certificado IDP idpCertAlias String Alias do certificado IDP encontrado no armazenamento global de confiança do AEM
Redirecionamento HTTP IDP idpHttpRedirect Booleano false Indica se há um Redirecionamento HTTP para o URL do IDP em vez de enviar uma AuthnRequest. Defina como true para autenticação iniciada por IDP.
Identificador do IDP idpIdentifier String ID exclusiva do IDP para garantir a exclusividade do usuário e do grupo do AEM. Se estiver vazio, o serviceProviderEntityId será usado.
URL do serviço do consumidor de asserção assertionConsumerServiceURL String O atributo de URL AssertionConsumerServiceURL na AuthnRequest especificando para onde a mensagem <Response> deve ser enviada para AEM.
Id de entidade da controladora serviceProviderEntityId String Identifica exclusivamente o AEM para o IDP; geralmente, o nome do host AEM.
Criptografia da controladora useEncryption Booleano true Indica se o IDP criptografa asserções SAML. Exige que spPrivateKeyAlias e keyStorePassword sejam definidos.
Alias da chave privada da controladora spPrivateKeyAlias String O alias da chave privada no armazenamento de chaves do usuário authentication-service. Necessário se useEncryption estiver definido como true.
Senha do armazenamento de chave da controladora keyStorePassword String A senha do armazenamento de chaves do usuário 'serviço de autenticação'. Necessário se useEncryption estiver definido como true.
Redirecionamento padrão defaultRedirectUrl String / O URL de redirecionamento padrão após a autenticação bem-sucedida. Pode ser relativo ao host AEM (por exemplo, /content/wknd/us/en/html).
Atributo de ID de usuário userIDAttribute String uid O nome do atributo de asserção SAML que contém a ID do usuário AEM. Deixe vazio para usar o Subject:NameId.
Criar usuários do AEM automaticamente createUser Booleano true Indica se os usuários do AEM são criados na autenticação bem-sucedida.
Caminho intermediário do usuário do AEM userIntermediatePath String Ao criar usuários de AEM, esse valor é usado como o caminho intermediário (por exemplo, /home/users/<userIntermediatePath>/jane@wknd.com). Exige que createUser seja definido como true.
Atributos de usuário do AEM synchronizeAttributes Matriz de string Lista de mapeamentos de atributos SAML para armazenar no usuário AEM, no formato [ "saml-attribute-name=path/relative/to/user/node" ] (por exemplo, [ "firstName=profile/givenName" ]). Consulte a lista completa de atributos nativos do AEM.
Adicionar usuário a grupos de AEM addGroupMemberships Booleano true Indica se um usuário AEM é adicionado automaticamente a grupos de usuários AEM após a autenticação bem-sucedida.
Atributo de associação de grupo AEM groupMembershipAttribute String groupMembership O nome do atributo de asserção SAML contendo uma lista de grupos de usuários AEM aos quais o usuário deve ser adicionado. Exige que addGroupMemberships seja definido como true.
Grupos AEM padrão defaultGroups Matriz de string Uma lista de grupos de usuários AEM autenticados é sempre adicionada ao (por exemplo, [ "wknd-user" ]). Exige que addGroupMemberships seja definido como true.
Formato de NameIDPolicy nameIdFormat String urn:oasis:names:tc:SAML:2.0:nameid-format:transient O valor do parâmetro de formato NameIDPolicy a ser enviado na mensagem AuthnRequest.
Armazenar resposta SAML storeSAMLResponse Booleano false Indica se o valor samlResponse está armazenado no nó cq:User do AEM.
Manipular logout handleLogout Booleano false Indica se a solicitação de logout é tratada por esse manipulador de autenticação SAML. Exige que logoutUrl seja definido.
URL de saída logoutUrl String URL do IDP para o qual a solicitação de logout do SAML é enviada. Necessário se handleLogout estiver definido como true.
Tolerância do relógio clockTolerance Número inteiro 60 Tolerância de desvio do relógio IDP e AEM (SP) ao validar asserções SAML.
Método Digest digestMethod String http://www.w3.org/2001/04/xmlenc#sha256 O algoritmo de compilação que o IDP usa ao assinar uma mensagem SAML.
Método de assinatura signatureMethod String http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 O algoritmo de assinatura que o IDP usa ao assinar uma mensagem SAML.
Tipo de sincronização de identidade identitySyncType default ou idp default Não alterar o padrão from do AEM as a Cloud Service.
Classificação de serviço service.ranking Número inteiro 5002 As configurações de classificação mais altas são preferidas para o mesmo path.

Atributos de usuário do AEM aem-user-attributes

O AEM usa os seguintes atributos de usuário, que podem ser preenchidos por meio da propriedade synchronizeAttributes na configuração OSGi do Manipulador de autenticação SAML 2.0 do Adobe Granite. Qualquer atributo do IDP pode ser sincronizado com qualquer propriedade de usuário do AEM. No entanto, o mapeamento para o AEM usa propriedades de atributo (listadas abaixo) permite que o AEM as use naturalmente.

table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 7-row-2 8-row-2 9-row-2 10-row-2 11-row-2
Atributo de usuário Caminho da propriedade relativa do nó rep:User
Título (por exemplo, Mrs) profile/title
Nome (ou seja, nome) profile/givenName
Nome da família (ou seja, sobrenome) profile/familyName
Cargo profile/jobTitle
Endereço de e-mail profile/email
Endereço profile/street
Cidade profile/city
Código postal profile/postalCode
País profile/country
Número de telefone profile/phoneNumber
Sobre mim profile/aboutMe
  1. Crie um arquivo de configuração OSGi em seu projeto em /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json e abra-o no IDE.

    • Altere /wknd-examples/ para /<project name>/
    • O identificador depois de ~ no nome do arquivo deve identificar exclusivamente essa configuração, portanto, pode ser o nome do IDP, como ...~okta.cfg.json. O valor deve ser alfanumérico com hifens.
  2. Cole o seguinte JSON no arquivo com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json e atualize as referências wknd conforme necessário.

    code language-json
    {
        "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. Atualize os valores conforme exigido pelo projeto. Consulte o glossário de configuração OSGi do Manipulador de Autenticação SAML 2.0 acima para obter as descrições das propriedades de configuração

  4. É recomendável, mas não obrigatório, usar variáveis de ambiente OSGi e segredos, quando os valores puderem mudar fora de sincronia com o ciclo de lançamento ou quando os valores forem diferentes entre tipos de ambiente/camadas de serviço semelhantes. Valores padrão podem ser definidos usando a sintaxe $[env:..;default=the-default-value]", como mostrado acima.

As configurações de OSGi por ambiente (config.publish.dev, config.publish.stage e config.publish.prod) poderão ser definidas com atributos específicos se a configuração de SAML variar entre ambientes.

Usar criptografia

Ao criptografar a solicitação AuthnRequest e a instrução SAML, as seguintes propriedades são necessárias: useEncryption, spPrivateKeyAlias e keyStorePassword. O keyStorePassword contém uma senha, portanto, o valor não deve ser armazenado no arquivo de configuração OSGi, mas inserido usando valores de configuração secreta

Opcionalmente, atualize a configuração do OSGi para usar criptografia
  1. Abra /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json no IDE.

  2. Adicione as três propriedades useEncryption, spPrivateKeyAlias e keyStorePassword conforme mostrado abaixo.

    code language-json
    {
    "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. As três propriedades de configuração do OSGi necessárias para criptografia são:

  • useEncryption definido como true
  • spPrivateKeyAlias contém o alias de entrada do keystore para a chave privada usada pela integração SAML.
  • keyStorePassword contém uma variável de configuração de segredo OSGi contendo a senha do armazenamento de chaves do usuário authentication-service.

Configurar filtro Referenciador

Durante o processo de autenticação SAML, o IDP inicia um POST HTTP do lado do cliente para o ponto final AEM Publish .../saml_login. Se o IDP e o AEM Publish existem em origens diferentes, o AEM Filtro de referenciador do Publish é configurado por meio da configuração OSGi para permitir HTTP POSTs da origem do IDP.

  1. Crie (ou edite) um arquivo de configuração OSGi em seu projeto em /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/org.apache.sling.security.impl.ReferrerFilter.cfg.json.

    • Altere /wknd-examples/ para /<project name>/
  2. Verifique se o valor allow.empty está definido como true, se allow.hosts (ou, se preferir, allow.hosts.regexp) contém a origem do IDP e filter.methods inclui POST. A configuração do OSGi deve ser semelhante a:

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

O AEM Publish é compatível com uma única configuração de filtro Referenciador, portanto, mescle os requisitos de configuração do SAML com qualquer configuração existente.

As configurações de OSGi por ambiente (config.publish.dev, config.publish.stage e config.publish.prod) poderão ser definidas com atributos específicos se o allow.hosts (ou allow.hosts.regex) variar entre ambientes.

Configurar o CORS (Cross-Origin Resource Sharing, Compartilhamento de recursos entre origens)

Durante o processo de autenticação SAML, o IDP inicia um POST HTTP do lado do cliente para o ponto final AEM Publish .../saml_login. Se o IDP e o AEM Publish existirem em hosts/domínios diferentes, o Publish CORS (CRoss-Origin Resource Sharing) do AEM deve ser configurado para permitir POSTs HTTP do host/domínio do IDP.

O cabeçalho Origin dessa solicitação POST HTTP geralmente tem um valor diferente do host AEM Publish, exigindo a configuração do CORS.

Ao testar a autenticação SAML no SDK AEM local (localhost:4503), o IDP pode definir o cabeçalho Origin como null. Em caso afirmativo, adicione "null" à lista alloworigin.

  1. Crie um arquivo de configuração OSGi em seu projeto em /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.cors.impl.CORSPolicyImpl~saml.cfg.json

    • Altere /wknd-examples/ para o nome do seu projeto
    • O identificador depois de ~ no nome do arquivo deve identificar exclusivamente essa configuração, portanto, pode ser o nome do IDP, como ...CORSPolicyImpl~okta.cfg.json. O valor deve ser alfanumérico com hifens.
  2. Cole o seguinte JSON no arquivo com.adobe.granite.cors.impl.CORSPolicyImpl~...cfg.json.

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

As configurações de OSGi por ambiente (config.publish.dev, config.publish.stage e config.publish.prod) poderão ser definidas com atributos específicos se o alloworigin e o allowedpaths variarem entre ambientes.

Configurar o AEM Dispatcher para permitir POSTs HTTP SAML

Após a autenticação bem-sucedida para o IDP, o IDP orquestrará um POST HTTP de volta para o ponto final /saml_login registrado pelo AEM (configurado no IDP). Esse POST HTTP para /saml_login está bloqueado por padrão no Dispatcher, portanto, deve ser permitido explicitamente usando a seguinte regra do Dispatcher:

  1. Abra dispatcher/src/conf.dispatcher.d/filters/filters.any no IDE.
  2. Adicione à parte inferior do arquivo uma regra de permissão para POSTs HTTP a URLs que terminam com /saml_login.
...

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

Se a regravação de URL no servidor Web Apache estiver configurada (dispatcher/src/conf.d/rewrites/rewrite.rules), verifique se as solicitações para os pontos de extremidade .../saml_login não foram acidentalmente danificadas.

Implantando configuração SAML

As configurações do OSGi devem ser confirmadas no Git e implantadas no AEM as a Cloud Service usando o 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

Implante a ramificação Git do Cloud Manager de destino (neste exemplo, develop), usando um pipeline de implantação de Empilhamento completo.

Chamar a autenticação SAML

O fluxo de autenticação SAML pode ser chamado de uma página da Web do site AEM, criando links especialmente criados ou um botão. Os parâmetros descritos abaixo podem ser definidos de forma programática conforme necessário, portanto, por exemplo, um botão de logon pode definir o saml_request_path, que é o local em que o usuário é levado após a autenticação SAML bem-sucedida, para páginas AEM diferentes, com base no contexto do botão.

solicitação GET

A autenticação SAML pode ser chamada ao criar uma solicitação HTTP GET no formato:

HTTP GET /system/sling/login

e fornecem parâmetros de consulta:

Nome do parâmetro de consulta
Consultar valor de parâmetro
resource
Qualquer caminho JCR, ou subcaminho, que seja o manipulador de autenticação SAML escuta em, como definido na propriedade path 🔗 da configuração OSGi do Manipulador de autenticação SAML 2.0 do Adobe Granite.
saml_request_path
O caminho do URL ao qual o usuário deve ser direcionado após a autenticação SAML bem-sucedida.

Por exemplo, esse link de HTML acionará o fluxo de logon do SAML e, se bem-sucedido, levará o usuário para /content/wknd/us/en/protected/page.html. Esses parâmetros de consulta podem ser definidos de forma programática, conforme necessário.

<a href="/system/sling/login?resource=/content/wknd&saml_request_path=/content/wknd/us/en/protected/page.html">
    Log in using SAML
</a>

solicitação POST

A autenticação SAML pode ser invocada ao criar uma solicitação HTTP POST no formato:

HTTP POST /system/sling/login

e fornecendo os dados do formulário:

Nome dos dados do formulário
Valor dos dados de formulário
resource
Qualquer caminho JCR, ou subcaminho, que seja o manipulador de autenticação SAML escuta em, como definido na propriedade path 🔗 da configuração OSGi do Manipulador de autenticação SAML 2.0 do Adobe Granite.
saml_request_path
O caminho do URL ao qual o usuário deve ser direcionado após a autenticação SAML bem-sucedida.

Por exemplo, esse botão HTML usará um POST HTTP para acionar o fluxo de logon SAML e, caso seja bem-sucedido, levará o usuário para /content/wknd/us/en/protected/page.html. Esses parâmetros de dados de formulário podem ser definidos de forma programática, conforme necessário.

<form action="/system/sling/login" method="POST">
    <input type="hidden" name="resource" value="/content/wknd">
    <input type="hidden" name="saml_request_path" value="/content/wknd/us/en/protected/page.html">
    <input type="submit" value="Log in using SAML">
</form>

Configuração do Dispatcher

Os métodos HTTP GET e POST exigem acesso do cliente aos endpoints do AEM AEM /system/sling/login e, portanto, devem ser permitidos por meio do Dispatcher.

Permitir os padrões de URL necessários com base em se GET ou POST é usado

# Allow GET-based SAML authentication invocation
/0191 { /type "allow" /method "GET" /url "/system/sling/login" /query="*" }

# Allow POST-based SAML authentication invocation
/0192 { /type "allow" /method "POST" /url "/system/sling/login" }
recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69