Suporte ao Open ID Connect para AEM as a Cloud Service no nível de publicação open-id-connect-support-for-aem-as-a-cloud-service-on-publish-tier

Introdução introduction

À medida que as organizações modernizam suas experiências digitais, o gerenciamento de identidades seguro e escalável se torna um requisito fundamental. O Adobe Experience Manager (AEM) Cloud Service agora é compatível com o OpenID Connect (OIDC) no nível de publicação, permitindo integração contínua e baseada em padrões com os principais Provedores de identidade (IdPs), como Entra ID (Azure AD), Google, Okta, Auth0, Identidade de ping, ForgeRock e IDC compatíveis com os IDPs.

O OIDC é uma camada de identidade sobre o protocolo OAuth 2.0 que permite uma autenticação de usuário robusta, mantendo a simplicidade para os desenvolvedores. Ele é amplamente adotado para cenários B2C (B2C), intranet e portais de parceiros, em que são necessários logon seguro de usuários e federações de identidade.

Até agora, os clientes do AEM eram responsáveis por implementar sua própria lógica de logon personalizada no nível de publicação, o que aumentou o tempo de desenvolvimento e introduziu desafios de manutenção e segurança de longo prazo. Com suporte nativo para o OIDC, o AEM Cloud Service remove essa carga fornecendo um mecanismo de autenticação seguro, extensível e com suporte da Adobe para usuários finais que acessam ambientes de publicação.

Esteja você fornecendo um site personalizado do consumidor ou um portal interno autenticado, o OIDC on Publish simplifica a federação de identidades e reduz os riscos por meio de um controle de identidades centralizado. Também ajuda as organizações a atender aos padrões modernos de conformidade e segurança sem sacrificar a agilidade.

Configurar o AEM para autenticação OIDC configure-aem-oidc-authentication

Pré-requisitos prerequisits

Presumimos que as seguintes informações estão disponíveis ou definidas:

Informações da configuração do IdP:

Visão geral dos arquivos de configuração overview-of-the-configuration-files

Encontre abaixo uma lista de arquivos que precisam ser configurados:

O diagrama a seguir mostra como os elementos de configuração mencionados são vinculados. Observe que, como esses são ServiceFactory componentes, ~uniqueid pode ser qualquer sequência de caracteres exclusiva e aleatória:

Configurar a conexão OIDC configure-the-oidc-connection

Primeiro, precisamos configurar a conexão OIDC. É possível configurar várias conexões OIDC, e cada uma precisa ter um nome diferente.

Em alguns ambientes, o provedor de identidade (IdP) pode não expor um ponto de extremidade .well-known válido.
Quando isso ocorre, os endpoints necessários podem ser definidos manualmente especificando as seguintes propriedades no arquivo de configuração.
Neste modo de configuração, a propriedade baseUrl não deve ser definida.

"authorizationEndpoint": "https://idp-url/oauth2/v1/authorize",
"tokenEndpoint": "https://idp-url/oauth2/v1/token",
"jwkSetURL":"https://idp-url/oauth2/v1/keys",
"issuer": "https://idp-url"

Configurar o manipulador de autenticação OIDC configure-oidc-authentication-handler

Agora, configure o manipulador de autenticação OIDC. Várias conexões OIDC podem ser configuradas. Cada um tem de ter um nome diferente. Se eles compartilharem o mesmo Provedor de Identidade Externo do OAK, eles poderão compartilhar usuários.

Configurar SlingUserInfoProcessor configure-slinguserinfoprocessor

Configurar o Manipulador de sincronização configure-the-synchronization-handler

Pelo menos um Manipulador de sincronização deve ser configurado para sincronizar os usuários autenticados no oak. Para obter mais detalhes, consulte esta página.

Crie um arquivo chamado org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncHandler~azure.cfg.json. O sufixo azure deve ser um identificador exclusivo. Para obter mais informações sobre como configurar suas propriedades, consulte a documentação sobre Sincronização de Usuários e Grupos do Oak. Encontre um exemplo de configuração abaixo:

{
  "user.expirationTime":"1h",
  "user.membershipExpTime":"1h",
  "group.expirationTime": "1d"
  "user.propertyMapping":[
    "profile/givenName=profile/given_name",
    "profile/familyName=profile/family_name",
    "rep:fullname=profile/name",
    "profile/email=profile/email",
    "access_token=access_token",
    "refresh_token=refresh_token"
  ],
  "user.pathPrefix":"azure",
  "handler.name":"azure"
}

Durante o desenvolvimento, os tempos de expiração podem ser reduzidos a um valor mais baixo (por exemplo: 1s) para acelerar os testes de sincronização de usuários e grupos no oak.
Abaixo alguns dos atributos mais relevantes a serem configurados em DefaultSyncHandler. Observe que a Associação de grupo dinâmico deve estar sempre habilitada nos Serviços em nuvem.

Configurar o módulo de logon externo configure-the-external-login-module

Por fim, é necessário configurar o Módulo de logon externo.

Opcional: Implementar um UserInfoProcessor personalizado implement-a-custom-userinfoprocessor

O usuário é autenticado por um Token de ID e atributos adicionais são buscados no ponto de extremidade userInfo definido para o IdP. Se operações não padrão adicionais tiverem que ser executadas, uma implementação personalizada do UserInfoProcessor será a implementação padrão do Sling.

Configurar ACL para grupos externos configure-acl-for-external-groups

Quando os usuários são autenticados por meio do OIDC, suas associações de grupo normalmente são sincronizadas do provedor de identidade externo.
Esses grupos externos são criados dinamicamente no repositório do AEM, mas não são associados automaticamente a nenhuma entrada de controle de acesso.
Para garantir que os usuários tenham as permissões apropriadas, as listas de controle de acesso (ACLs) devem ser explicitamente definidas para esses grupos.

Duas abordagens principais estão disponíveis.

Opção 1 — Grupos locais

O grupo externo pode ser adicionado como membro de um grupo local que já tem as ACLs necessárias.

Opção 2 — ACLs diretas em grupos externos via RepoInit

As ACLs podem ser aplicadas diretamente a grupos externos usando scripts RepoInit.

Exemplo: configurar a autenticação OIDC com o Azure Ative Diretory

Configurar um novo Aplicativo no Azure Ative Diretory configure-a-new-application-in-azure-ad

org.apache.sling.auth.oauth_client.impl.OidcConnectionImpl~azure.cfg.json

{
  "name":"azure",
  "scopes":[
    openid", "User.Read", "profile", "email"
  ],
  "baseUrl":"https://login.microsoftonline.com/tenant-id/v2.0",
  "clientId":"client-id",
  "clientSecret":"secret"
}

org.apache.sling.auth.oauth_client.impl.OidcAuthenticationHandler~azure.cfg.json

{
  "callbackUri":"https://www.mywebsite.com/content/wknd/us/en/adventures/j_security_check",
  "path":[
    "/content/wknd/us/en/adventures"
  ],
  "idp":"azure",
  "defaultConnectionName":"azure"
}

org.apache.jackrabbit.oak.spi.security.authentication.external.impl.ExternalLoginModuleFactory~azure.cfg.json

{
  "sync.handlerName":"azure",
  "idp.name":"azure"
}

org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncHandler~azure.cfg.json

{
  "user.expirationTime":"1h",
  "user.membershipExpTime":"1h",
  "group.expirationTime": "1d"
  "user.propertyMapping":[
    "profile/givenName=profile/given_name",
    "profile/familyName=profile/family_name",
    "rep:fullname=profile/name",
    "profile/email=profile/email",
    "access_token=access_token",
    "refresh_token=refresh_token"
  ],
  "user.pathPrefix":"azure",
  "group.pathPrefix": "oidc",
  "user.membershipNestingDepth": "1",
  "handler.name":"azure"
}

org.apache.sling.jcr.repoinit.RepositoryInitializer~azure.cfg.json

{
  "scripts":[
    "set ACL for \"adventures;azure\"  (ACLOptions=ignoreMissingPrincipal)\r\n  allow jcr:read on /content/wknd/us/en/adventures\r\nend"
  ]
}

org.apache.sling.auth.oauth_client.impl.SlingUserInfoProcessorImpl~azure.cfg.json

{
  "groupsInIdToken": "true",
  "storeAccessToken": "false",
  "storeRefreshToken": "false",
  "connection": "azure",
  "groupsClaimName": "groups"
}

Informações adicionais sobre grupos do Azure AD additional-information-about-azure-ad-groups

Para configurar um grupo para o aplicativo corporativo no Portal do Microsoft Azure, você precisa pesquisar o aplicativo em: Aplicativos Corporativos e adicionar os grupos:

Para habilitar a declaração de grupo no Token de Id, adicione a declaração na seção Configuração de Token do Portal do Microsoft Azure:

A configuração de SlingUserInfoProcessor deve ser modificada como no exemplo abaixo.

O nome de arquivo que precisa ser modificado é org.apache.sling.auth.oauth_client.impl.SlingUserInfoProcessorImpl.cfg.json. O conteúdo deve ser configurado da seguinte maneira:

{
  "connection": "azure",
  "groupsInIdToken": "true",
  "storeAccessToken": "false",
  "storeRefreshToken": "false"
}

Como migrar do Manipulador de autenticação Saml para o Manipulador de autenticação Oidc

Quando o AEM já estiver configurado com um Manipulador de Autenticação SAML e os usuários estiverem presentes no repositório com a sincronização de dados habilitada, poderão ocorrer conflitos entre os usuários SAML originais e os novos usuários OIDC.