Prise en charge d’Open ID Connect pour AEM as a Cloud Service au niveau publication open-id-connect-support-for-aem-as-a-cloud-service-on-publish-tier

Présentation introduction

À mesure que les organisations modernisent leurs expériences numériques, la gestion sécurisée et évolutive des identités devient une exigence fondamentale. Cloud Service d’Adobe Experience Manager (AEM) prend désormais en charge Open ID Connect (OIDC) au niveau publication, ce qui permet une intégration transparente et normalisée avec les principaux fournisseurs d’identité (IdP) tels qu’Entra ID (Azure AD), Google, Okta, Auth0, Ping Identity, ForgeRock et les fournisseurs d’identité pris en charge par OIDC.

OIDC est une couche d’identité qui se place sur le protocole OAuth 2.0 et qui permet une authentification robuste des personnes, tout en restant simple pour les développeurs et développeuses. Il est largement adopté pour les scénarios de business-to-consumer (B2C), d’intranet et de portails partenaires, où des fédérations d’identités et de connexion sécurisées sont requises.

Jusqu’à présent, les clientes et clients AEM devaient mettre en œuvre leur propre logique de connexion personnalisée au niveau publication, ce qui accroissait les délais de développement et introduisait des difficultés de maintenance et de sécurité à long terme. Grâce à la prise en charge native d’OIDC, AEM Cloud Service élimine cette responsabilité en proposant un mécanisme d’authentification sécurisé, extensible et pris en charge par Adobe pour les utilisateurs et utilisatrices qui accèdent aux environnements de publication.

Qu’il s’agisse de diffuser un site web client personnalisé ou un portail interne authentifié, OIDC installé au niveau publication simplifie la fédération des identités et réduit les risques grâce à une gouvernance d’identité centralisée. Il aide également les organisations à respecter les normes de conformité et de sécurité modernes sans sacrifier leur agilité.

Configurer AEM pour l’authentification OIDC configure-aem-oidc-authentication

Prérequis prerequisits

Nous partons de l’hypothèse que les informations suivantes sont disponibles ou définies :

Informations provenant de la configuration d’IdP :

Vue d’ensemble des fichiers de configuration overview-of-the-configuration-files

Vous trouverez ci-dessous une liste des fichiers qui doivent être configurés :

Le diagramme suivant montre la façon dont les éléments de configuration mentionnés sont liés. Notez que puisqu’il s’agit de composants ServiceFactory, l’~uniqueid peut être n’importe quelle chaîne unique aléatoire :

Configurer la connexion OIDC configure-the-oidc-connection

Tout d’abord, nous devons configurer la connexion OIDC. Il est possible de configurer plusieurs connexions OIDC. Chacune doit avoir un nom différent.

Dans certains environnements, le fournisseur d’identité (IdP) peut ne pas exposer un point d’entrée .well-known valide.
Dans ce cas, les points d’entrée requis peuvent être définis manuellement en spécifiant les propriétés suivantes dans le fichier de configuration.
Dans ce mode de configuration, la propriété baseUrl ne doit pas être définie.

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

Configurer le gestionnaire d’authentification OIDC configure-oidc-authentication-handler

Configurez maintenant le gestionnaire d’authentification OIDC. Il est possible de configurer plusieurs connexions OIDC. Chacune doit avoir un nom différent. Si elles partagent le même fournisseur d’identité externe OAK, elles peuvent partager des utilisateurs et des utilisatrices.

Configurer SlingUserInfoProcessor configure-slinguserinfoprocessor

Configurer le gestionnaire de synchronisation configure-the-synchronization-handler

Au moins un gestionnaire de synchronisation doit être configuré pour synchroniser les utilisateurs et utilisatrices authentifiés dans Oak. Pour plus d’informations, consultez cette page.

Créez un fichier nommé org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncHandler~azure.cfg.json. Le suffixe azure doit être un identifiant unique. Pour plus d’informations sur la configuration de ses propriétés, consultez la documentation sur la synchronisation des utilisateurs et utilisatrices et des groupes Oak. Vous trouverez un exemple de configuration ci-dessous :

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

Pendant le développement, les délais d’expiration peuvent être réduits à une valeur inférieure (par exemple : 1 s) afin d’accélérer les tests de synchronisation des utilisateurs et des groupes dans oak.
Vous trouverez ci-dessous certains des attributs les plus pertinents à configurer dans DefaultSyncHandler. Notez que l’appartenance à un groupe dynamique doit toujours être activée dans les services cloud.

Configurer le module de connexion externe configure-the-external-login-module

Enfin, vous devez configurer le module de connexion externe.

Facultatif : implémentation d’un UserInfoProcessor personnalisé implement-a-custom-userinfoprocessor

L’utilisateur ou l’utilisatrice est authentifié par un jeton d’ID et des attributs supplémentaires sont récupérés dans le point d’entrée userInfo défini pour l’IdP. Si d’autres opérations non standard doivent être effectuées, une implémentation personnalisée du UserInfoProcessor est l’implémentation par défaut provenant de Sling.

Configuration de la liste de contrôle d’accès pour les groupes externes configure-acl-for-external-groups

Lorsque les utilisateurs sont authentifiés via OIDC, leurs appartenances à un groupe sont généralement synchronisées à partir du fournisseur d’identité externe.
Ces groupes externes sont créés dynamiquement dans le référentiel AEM, mais ne sont pas automatiquement associés à des entrées de contrôle d’accès.
Pour que les utilisateurs disposent des autorisations appropriées, des listes de contrôle d’accès (ACL) doivent être explicitement définies pour ces groupes.

Deux approches principales sont disponibles.

Option 1 — Groupes Locaux

Le groupe externe peut être ajouté en tant que membre d’un groupe local qui possède déjà les listes de contrôle d’accès requises.

Option 2 — Listes de contrôle d’accès directes sur des groupes externes via RepoInit

Les listes de contrôle d’accès peuvent être appliquées directement à des groupes externes à l’aide de scripts RepoInit.

Exemple : configuration de l’authentification OIDC avec Azure Active Directory

Configurer une nouvelle application dans 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"
}

Informations supplémentaires sur les groupes Azure AD additional-information-about-azure-ad-groups

Afin de configurer un groupe pour l’application d’entreprise dans le portail Microsoft Azure, vous devez rechercher l’application dans Applications d’entreprise et ajouter les groupes : .

Pour activer la revendication de groupe dans le jeton d’ID, ajoutez-la dans la section Configuration du jeton du portail Microsoft Azure : .

La configuration de SlingUserInfoProcessor doit être modifiée comme dans l’exemple ci-dessous.

Le nom de fichier qui doit être modifié est org.apache.sling.auth.oauth_client.impl.SlingUserInfoProcessorImpl.cfg.json. Le contenu doit être configuré comme suit :

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

Comment migrer du gestionnaire d’authentification SAML vers le gestionnaire d’authentification OID

Lorsqu’AEM est déjà configuré avec un gestionnaire d’authentification SAML et que les utilisateurs sont présents dans le référentiel avec la synchronisation des données activée, des conflits peuvent se produire entre les utilisateurs SAML d’origine et les nouveaux utilisateurs OIDC.