Compatibilidad con Open ID Connect para AEM as a Cloud Service en el nivel de publicación open-id-connect-support-for-aem-as-a-cloud-service-on-publish-tier

Introducción introduction

A medida que las organizaciones modernizan sus experiencias digitales, la administración de identidades segura y escalable se convierte en un requisito básico. Adobe Experience Manager (AEM) Cloud Service ahora es compatible con OpenID Connect (OIDC) en el nivel de publicación, lo que permite una integración perfecta y basada en estándares con los principales proveedores de identidad (IdPs), como Entra ID (Azure AD), Google, Okta, Auth0, Ping Identity, ForgeRock y OIDC con los IDP admitidos.

OIDC es una capa de identidad que se suma al protocolo OAuth 2.0, que permite una autenticación de usuario sólida y, al mismo tiempo, mantiene la simplicidad para los desarrolladores. Se ha adoptado ampliamente en los escenarios de portal de socio, intranet y de empresa a consumidor (B2C), en los que se requieren federaciones de identidad e inicio de sesión de usuarios seguras.

Hasta ahora, los clientes de AEM eran responsables de implementar su propia lógica de inicio de sesión personalizada en el nivel de publicación, lo que aumentó el tiempo de desarrollo e introdujo desafíos de mantenimiento y seguridad a largo plazo. Con la compatibilidad nativa con OIDC, AEM Cloud Service elimina esta carga al proporcionar un mecanismo de autenticación seguro, extensible y compatible con Adobe para los usuarios finales que acceden a entornos de publicación.

Tanto si desea ofrecer un sitio web personalizado para consumidores como un portal interno autenticado, OIDC en Publish simplifica la federación de identidades y reduce el riesgo mediante la gobernanza de identidades centralizada. También ayuda a las organizaciones a cumplir con los estándares modernos de cumplimiento y seguridad sin sacrificar la agilidad.

Configuración de AEM para la autenticación de OIDC configure-aem-oidc-authentication

Requisitos previos prerequisits

Suponemos que la siguiente información está disponible o definida:

Información de la configuración de IdP:

Descripción general de los archivos de configuración overview-of-the-configuration-files

A continuación, encontrará una lista de los archivos que se deben configurar:

El diagrama siguiente muestra cómo se vinculan los elementos de configuración mencionados. Tenga en cuenta que como estos son ServiceFactory componentes, ~uniqueid puede ser cualquier cadena única aleatoria:

Configuración de la conexión de OIDC configure-the-oidc-connection

En primer lugar, es necesario configurar la conexión de OIDC. Se pueden configurar varias conexiones de OIDC, y cada una debe tener un nombre diferente.

En algunos entornos, es posible que el proveedor de identidad (IdP) no exponga un extremo .well-known válido.
Cuando esto sucede, los puntos de conexión necesarios se pueden definir manualmente especificando las siguientes propiedades en el archivo de configuración.
En este modo de configuración, no se debe establecer la propiedad baseUrl.

"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"

Configuración del controlador de autenticación OIDC configure-oidc-authentication-handler

Ahora, configure el controlador de autenticación OIDC. Se pueden configurar varias conexiones de OIDC. Cada una debe tener un nombre diferente. Si comparten el mismo proveedor de identidad externa de OAK, pueden compartir usuarios.

Configuración de SlingUserInfoProcessor configure-slinguserinfoprocessor

Configuración del controlador de sincronización configure-the-synchronization-handler

Debe haber al menos un controlador de sincronización configurado para sincronizar los usuarios autenticados en Oak. Para obtener más detalles, consulte esta página.

Cree un archivo con el nombre org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncHandler~azure.cfg.json. El sufijo azure debe ser un identificador único. Para obtener más información sobre cómo configurar sus propiedades, consulte la Documentación de sincronización de grupos y usuarios de Oak. A continuación, encontrará un ejemplo de configuración:

{
  "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 el desarrollo, los tiempos de caducidad se pueden reducir a un valor menor (por ejemplo: 1) para acelerar las pruebas de sincronización de usuarios y grupos en Oak.
A continuación, se muestran algunos de los atributos más relevantes que se van a configurar en DefaultSyncHandler. Tenga en cuenta que la pertenencia a grupos dinámicos siempre debe estar habilitada en Cloud Services.

Configuración del módulo de inicio de sesión externo configure-the-external-login-module

Finalmente, debe configurar el módulo de inicio de sesión externo.

Opcional: implementar un UserInfoProcessor personalizado implement-a-custom-userinfoprocessor

El usuario se autentica mediante un token de ID y se recuperan atributos adicionales en el punto final userInfo definido para el IdP. Si se deben realizar operaciones no estándar adicionales, la implementación predeterminada de Sling es una implementación personalizada de UserInfoProcessor.

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

Cuando los usuarios se autentican a través de OIDC, las pertenencias a sus grupos generalmente se sincronizan desde el proveedor de identidad externo.
Estos grupos externos se crean dinámicamente en el repositorio de AEM, pero no se asocian automáticamente con ninguna entrada de control de acceso.
Para garantizar que los usuarios tengan los permisos adecuados, las listas de control de acceso (ACL) deben definirse explícitamente para estos grupos.

Hay dos enfoques principales disponibles.

Opción 1 - Grupos locales

El grupo externo se puede agregar como miembro de un grupo local que ya tiene las ACL requeridas.

Opción 2: Direccionar ACL en grupos externos mediante RepoInit

Las ACL se pueden aplicar directamente a grupos externos mediante scripts de RepoInit.

Ejemplo: configurar la autenticación de OIDC con Azure Active Directory

Configurar una nueva aplicación en Azure Active Directory 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"
}

Información adicional acerca de los grupos de Azure AD additional-information-about-azure-ad-groups

Para configurar un grupo para la aplicación empresarial en el portal de Microsoft Azure, debe buscar en la aplicación: Aplicaciones empresariales y añadir los grupos:

Para habilitar la notificación de grupo en el token de ID, añada la notificación a la sección Configuración del token del portal de Microsoft Azure:

La configuración de SlingUserInfoProcessor debe modificarse como en el ejemplo siguiente.

El nombre de archivo que debe modificarse es org.apache.sling.auth.oauth_client.impl.SlingUserInfoProcessorImpl.cfg.json. El contenido debe configurarse de la siguiente manera:

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

Migración del Controlador de autenticación Saml al Controlador de autenticación Oidc

Cuando AEM ya está configurado con un controlador de autenticación SAML y los usuarios están presentes en el repositorio con sincronización de datos habilitada, pueden producirse conflictos entre los usuarios de SAML originales y los nuevos usuarios de OIDC.