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

Aprenda a configurar e autenticar usuários finais (não AEM autores) para uma IDP compatível com SAML 2.0 da sua escolha.

Que SAML para AEM como Cloud Service?

A integração do SAML 2.0 com a AEM Publish (ou Visualização) permite que os usuários finais de uma experiência da Web com base em AEM autenticassem para um IDP não Adobe Systems (Provedor de identidade) e acessem AEM como um usuário nomeado e autorizado.

Apresentação da configuração

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

Pré-requisitos

As seguintes condições são necessárias ao configurar a autenticação SAML 2.0:

O SAML 2.0 é compatível somente para autenticar usos em AEM Publish ou Visualização. Para gerenciar a autenticação do AEM Author usando e o IDP, integre o IDP ao Adobe IMS.

Instalar o certificado público IDP no AEM

O certificado público do IDP é adicionado ao armazenamento global de confiança da AEM e usado para validar que a asserção SAML enviada pelo IDP é válida.

O Global Trust Store é configurado com o certificado público do IDP em AEM Autor, mas como o SAML só é usado em AEM Publish, o Global Trust Store deve ser replicado para AEM Publish para que o certificado público de IDP seja acessível lá.

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

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

Instalar AEM par de chaves públicas/privadas install-aem-public-private-key-pair

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

AEM Publish pode ser configurada para assinar AuthnRequests (para IDP) e criptografar afirmações SAML (para AEM). Isso é feito fornecendo uma chave privada para AEM Publish, e está correspondendo a chave pública com o IDP.

Tanto a assinatura de AuthnRequest quanto a criptografia de asserção saml são opcionais, no entanto, ambas estão ativadas, usando o manipulador de autenticação SAML 2.0 OSGi propriedade useEncryption, o que significa que ambos ou nem podem ser usados.

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

A configuração SAML da AEM é executada por meio da configuração OSGi Adobe Systems Granite SAML 2.0 Authentication Handler .
A configuração é uma configuração de fábrica do OSGi, ou seja, uma única AEM como Cloud Service Publish serviço pode ter várias configurações da SAML cobrindo árvores de recursos discretas do repositório; isso é útil para implantações de AEM em vários sites.

As configurações osGi por ambiente (config.publish.dev config.publish.stagee config.publish.prod) podem ser definidas com atributos específicos se a configuração saml varia entre ambientes.

Usar criptografia

Ao criptografar a asserção AuthnRequest e SAML, as seguintes propriedades são necessárias: useEncryption, spPrivateKeyAliase keyStorePassword. Isso keyStorePassword contém um senha portanto, o valor não deve ser armazenado no arquivo de configuração OSGi, mas sim injetado usando valores de configuração secretos

Configurar filtro referenciador

Durante o processo de autenticação SAML, o IDP inicia uma lado do cliente HTTP POST para AEM o ponto final de .../saml_login Publish. Se o IDP e o AEM Publish existirem em diferentes origem, a Filtrar do Referenciador da Publish AEM é configurada por meio da configuração OSGi para permitir POSTs HTTP da origem do IDP.

AEM Publish suporta uma única configuração de filtro do Referenciador, portanto, mescle os requisitos de configuração do SAML com quaisquer configurações existentes.

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 de extremidade .../saml_login do AEM Publish. Se o IDP e o AEM Publish existirem em hosts/domínios diferentes, o CORS (CRoss-Origin Resource Sharing) do AEM Publish deve ser configurado para permitir POSTs HTTP do host/domínio do IDP.

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

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

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

As configurações osGi por ambiente (config.publish.dev config.publish.stagee config.publish.prod) podem ser definidas com atributos específicos se elas alloworigin variam e allowedpaths variam entre ambientes.

Configurar AEM Dispatcher para permitir POSTs HTTP SAML

Após a autenticação bem-sucedida no IDP, o IDP orquestrará uma POST HTTP de volta ao ponto final registrado /saml_login de AEM (configurado no IDP). Esta POST HTTP a /saml_login ser bloqueada por padrão em Dispatcher, por isso deve ser explicitamente permitida usando as seguintes Dispatcher regra:

...

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

Se URL regravação no servidor Web Apache estiver configurado (dispatcher/src/conf.d/rewrites/rewrite.rules), certifique-se de que as solicitações para os .../saml_login pontos finais não sejam acidentalmente mutiladas.

Associação de grupo dinâmico

A Associação de Grupo Dinâmica é um recurso no Apache Jackrabbit Oak que aumenta o desempenho da avaliação e do provisionamento de grupos. Esta seção descreve como usuários e grupos são armazenados quando este recurso é ativado e como modificar a configuração do Manipulador de autenticação SAML para ativá-lo em ambientes novos ou existentes.

Como ativar a associação de grupo dinâmico para usuários de SAML em novos ambientes

Para melhorar significativamente grupo desempenho da avaliação em novos AEM como ambientes Cloud Service, o ativação do recurso Associação de Grupo Dinâmico é recomendado em novos ambientes.
Essa também é uma etapa necessária quando a sincronização de dados é ativada. Mais detalhes aqui .
Para fazer isso, adicione a seguinte propriedade ao arquivo de configuração OSGI:

/apps/example/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~example.cfg.json

Com essa configuração, usuários e grupos são criados como Usuários Externos do Oak. No AEM, os usuários e grupos externos têm um rep:principalName padrão composto por [user name];[idp] ou [group name];[idp].
Observe que as Listas de controle de acesso (ACL) estão associadas ao PrincipalName de usuários ou grupos.
Ao implantar esta configuração em uma implantação existente na qual anteriormente identitySyncType não foi especificado ou definido como default, novos usuários e grupos serão criados e a ACL deve ser aplicada a esses novos usuários e grupos. Observe que os grupos externos não podem conter usuários locais. Repoinit pode ser usado para criar uma ACL para grupos externos SAML, mesmo que eles só sejam criados quando o usuário realizar um logon.
Para evitar essa refatoração na ACL, um recurso de migração padrão foi implementado.

Como as associações são armazenadas em grupos locais e externos com associação de grupo dinâmica

Em grupos locais, os membros do grupo são armazenados no atributo oak: rep:members. O atributo contém a lista de uid de cada membro do grupo. Detalhes adicionais podem ser encontrados aqui.
Exemplo:

{
  "jcr:primaryType": "rep:Group",
  "rep:principalName": "operators",
  "rep:managedByIdp": "SAML",
  "rep:members": [
    "635afa1c-beeb-3262-83c4-38ea31e5549e",
    "5e496093-feb6-37e9-a2a1-7c87b1cec4b0",
    ...
  ],
   ...
}

Grupos externos com associação de grupo dinâmicos não armazenamento nenhum membro na entrada de grupo.
A associação de grupo é armazenada nas entradas dos usuários. A documentação adicional pode ser encontrada aqui. Por exemplo, esta é a nó OAK para o grupo:

{
  "jcr:primaryType": "rep:Group",
  "jcr:mixinTypes": [
    "rep:AccessControllable"
  ],
  "jcr:createdBy": "",
  "jcr:created": "Tue Jul 16 2024 08:58:47 GMT+0000",
  "rep:principalName": "GROUP_1;aem-saml-idp-1",
  "rep:lastSynced": "Tue Jul 16 2024 08:58:47 GMT+0000",
  "jcr:uuid": "d9c6af8a-35c0-3064-899a-59af55455cd0",
  "rep:externalId": "GROUP_1;aem-saml-idp-1",
  "rep:authorizableId": "GROUP_1;aem-saml-idp-1"
}

Este é o nó de um membro usuário desse grupo:

{
  "jcr:primaryType": "rep:User",
  "jcr:mixinTypes": [
    "rep:AccessControllable"
  ],
  "surname": "Test",
  "rep:principalName": "testUser",
  "rep:externalId": "test;aem-saml-idp-1",
  "rep:authorizableId": "test",
  "rep:externalPrincipalNames": [
    "projects-users;aem-saml-idp-1",
    "GROUP_2;aem-saml-idp-1",
    "GROUP_1;aem-saml-idp-1",
    "operators;aem-saml-idp-1"
  ],
  ...
}

Como ativar a associação de grupo dinâmico para usuários de SAML em ambientes existentes

Como explicado na seção anterior, o formato de usuários e grupos externos é um pouco diferente daquele usado para usuários e grupos locais. É possível definir uma nova ACL para grupos externos e provisionar novos usuários externos ou usar a migração ferramenta conforme descrito abaixo.

Ativação de associação de grupo dinâmicos para ambientes existentes com usuários externos

O manipulador Authentication SAML cria usuários externos quando a seguinte propriedade é especificada: "identitySyncType": "idp". Nesse caso, é possível ativar associação de grupo dinâmicos modificando essa propriedade para: "identitySyncType": "idp_dynamic". Nenhuma migração é necessária.

Migração automática para associação de grupo dinâmicos em ambientes existentes com usuários locais

O manipulador Authentication SAML cria usuários locais quando a seguinte propriedade é especificada: "identitySyncType": "default". Esse também é o valor padrão quando o propriedade não é especificado. Nesta seção, descrevemos as etapas executadas pelo procedimento de migração automática.

Quando essa migração é habilitada, ela é realizada durante usuário autenticação e consiste nas seguintes etapas:

Para instância, se antes da migração user1 for um usuário local e for membro de grupo group1local, após a migração ocorrerão as seguintes alterações:
user1 torna-se um usuário externo. O atributo rep:externalId é adicionado ao perfil dele.
user1torna-se membro de grupo externos: group1;idpnão é mais membro direto de grupo locais: user1 group1 é um membro do grupo local: group1;idp.group1

user1 é, então, um membro do grupo local: group1 embora a herança

A associação de grupo para grupos externos é armazenada na usuário perfil no propriedade rep:externalPrincipalNames

Configurar a migração automática para o associação de grupo dinâmico

{
  "idpIdentifier": "<value of IDP Identifier (idpIdentifier)" property from the "com.adobe.granite.auth.saml.SamlAuthenticationHandler" configuration to be migrated>"
}

Para migrar várias configurações SAML, várias configurações de fábrica OSGi para com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration devem ser criadas, cada uma especificando um idpIdentifier para migrar.

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 AEM web página, criando links especialmente elaborados 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.

Armazenamento em cache seguro ao usar SAML

Na instância de publicação do AEM, a maioria das páginas normalmente é armazenada em cache. No entanto, para caminhos protegidos por SAML, o armazenamento em cache deve ser desativado ou o armazenamento em cache seguro ativado usando a configuração auth_checker. Para obter mais informações, consulte os detalhes fornecidos aqui

Observe que, se você armazenar em cache caminhos protegidos sem ativar o auth_checker, poderá enfrentar um comportamento imprevisível.

solicitação GET

A autenticação SAML pode ser invocada criando uma solicitação GET do HTTP no formato:

HTTP GET /system/sling/login

e fornecendo parâmetros query:

Por exemplo, este link HTML acionará o fluxo de login saml e, após o sucesso, leve a usuário para /content/wknd/us/en/protected/page.html. Esses query parâmetros 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 criando uma solicitação HTTP POST no formato:

HTTP POST /system/sling/login

e fornecendo os dados do formulário:

Por exemplo, esse botão do 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 pontos de extremidade /system/sling/login da AEM e, portanto, devem ser permitidos por meio do AEM Dispatcher.

Permitir os padrões de URL necessários com base em se o GET ou POST foi 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" }