Supporto OpenID Connect per AEM as a Cloud Service sul livello di pubblicazione open-id-connect-support-for-aem-as-a-cloud-service-on-publish-tier

Introduzione introduction

Man mano che le organizzazioni modernizzano le proprie esperienze digitali, la gestione delle identità sicura e scalabile diventa un requisito fondamentale. Adobe Experience Manager (AEM) Cloud Service ora supporta OpenID Connect (OIDC) sul livello di pubblicazione, che consente un'integrazione fluida e basata su standard con i principali provider di identità (IdP) come Entra ID (Azure AD), Google, Okta, Auth0, Ping Identity, ForgeRock e gli IDP supportati da OIDC.

OIDC è un livello di identità sopra il protocollo OAuth 2.0 che consente una solida autenticazione utente mantenendo al contempo la semplicità per gli sviluppatori. È ampiamente adottato per scenari business-to-consumer (B2C), Intranet e portale partner, in cui sono necessari account utente sicuri e federazioni di identità.

Finora, i clienti di AEM erano responsabili dell'implementazione della propria logica di accesso personalizzata sul livello di pubblicazione, che ha aumentato i tempi di sviluppo e introdotto problemi di manutenzione e sicurezza a lungo termine. Con il supporto nativo per OIDC, AEM Cloud Service rimuove questo carico fornendo un meccanismo di autenticazione sicuro, estensibile e supportato da Adobe per gli utenti finali che accedono agli ambienti di pubblicazione.

Che tu stia distribuendo un sito web consumer personalizzato o un portale interno autenticato, OIDC on Publish semplifica la federazione delle identità e riduce i rischi tramite la governance centralizzata delle identità. Consente inoltre alle organizzazioni di soddisfare i moderni standard di conformità e sicurezza senza sacrificare l'agilità.

Configurare AEM per l'autenticazione OIDC configure-aem-oidc-authentication

Prerequisiti prerequisits

Si presuppone che siano disponibili o definite le seguenti informazioni:

Informazioni dalla configurazione IdP:

Panoramica dei file di configurazione overview-of-the-configuration-files

Di seguito è riportato un elenco di file da configurare:

Il diagramma seguente mostra come vengono collegati gli elementi di configurazione menzionati. Poiché si tratta di componenti ServiceFactory, ~uniqueid può essere una qualsiasi stringa univoca casuale:

Configurare la connessione OIDC configure-the-oidc-connection

Per prima cosa, è necessario configurare la connessione OIDC. È possibile configurare più connessioni OIDC, ognuna delle quali deve avere un nome diverso.

In alcuni ambienti, il provider di identità (IdP) potrebbe non esporre un endpoint .well-known valido.
In questo caso, gli endpoint richiesti possono essere definiti manualmente specificando le seguenti proprietà nel file di configurazione.
In questa modalità di configurazione, la proprietà baseUrl non deve essere impostata.

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

Configurare il Gestore autenticazione OIDC configure-oidc-authentication-handler

Ora configura il gestore di autenticazione OIDC. È possibile configurare più connessioni OIDC. Ognuna deve avere un nome diverso. Se condividono lo stesso Provider di identità esterno OAK, possono condividere gli utenti.

Configurare SlingUserInfoProcessor configure-slinguserinfoprocessor

Configurare il gestore di sincronizzazione configure-the-synchronization-handler

È necessario configurare almeno un gestore di sincronizzazione per sincronizzare gli utenti autenticati in oak. Per ulteriori dettagli, consulta questa pagina.

Crea un file denominato org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncHandler~azure.cfg.json. Il suffisso azure deve essere un identificatore univoco. Per ulteriori informazioni su come configurarne le proprietà, consulta la documentazione sulla sincronizzazione di utenti e gruppi di Oak. Di seguito trovi un esempio di configurazione:

{
  "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 lo sviluppo, i tempi di scadenza possono essere ridotti a un valore inferiore (ad esempio: 1 s) per velocizzare il test della sincronizzazione di utenti e gruppi in oak.
Di seguito sono riportati alcuni degli attributi più rilevanti da configurare in DefaultSyncHandler. Tieni presente che l'Iscrizione al gruppo dinamico deve essere sempre abilitata nei Cloud Service.

Configurare il Modulo di accesso esterno configure-the-external-login-module

Infine, devi configurare il Modulo di accesso esterno.

Facoltativo: implementa un UserInfoProcessor personalizzato implement-a-custom-userinfoprocessor

L'utente è autenticato da un token ID e gli attributi aggiuntivi vengono recuperati nell'endpoint userInfo definito per l'IdP. Se è necessario eseguire altre operazioni non standard, l'implementazione predefinita di Sling è un'implementazione personalizzata di UserInfoProcessor.

Configurare ACL per gruppi esterni configure-acl-for-external-groups

Quando gli utenti vengono autenticati tramite OIDC, le appartenenze ai loro gruppi vengono in genere sincronizzate dal provider di identità esterno.
Questi gruppi esterni vengono creati in modo dinamico nell’archivio di AEM, ma non vengono associati automaticamente ad alcuna voce di controllo di accesso.
Per garantire che gli utenti dispongano delle autorizzazioni appropriate, è necessario definire in modo esplicito gli elenchi di controllo di accesso (ACL, Access Control List) per questi gruppi.

Sono disponibili due approcci primari.

Opzione 1 — Gruppi locali

Il gruppo esterno può essere aggiunto come membro di un gruppo locale che dispone già degli ACL richiesti.

Opzione 2 — ACL diretti su gruppi esterni tramite RepoInit

Gli ACL possono essere applicati direttamente ai gruppi esterni utilizzando gli script RepoInit.

Esempio: configurare l'autenticazione OIDC con Azure Active Directory

Configurare una nuova applicazione in 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"
}

Informazioni aggiuntive sui gruppi di Azure AD additional-information-about-azure-ad-groups

Per configurare un gruppo per l'applicazione enterprise nel portale di Microsoft Azure, è necessario cercare l'applicazione in Applicazioni enterprise e aggiungere i gruppi:

Per abilitare l'attestazione di gruppo nel token ID, aggiungi l'attestazione nella sezione Configurazione token del portale di Microsoft Azure:

La configurazione di SlingUserInfoProcessor deve essere modificata come nell'esempio seguente.

Il nome file da modificare è org.apache.sling.auth.oauth_client.impl.SlingUserInfoProcessorImpl.cfg.json. Il contenuto deve essere configurato come segue:

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

Come migrare dal gestore di autenticazione Saml al gestore di autenticazione Oidc

Quando AEM è già configurato con un gestore di autenticazione SAML e gli utenti sono presenti nel repository con sincronizzazione dati abilitata, possono verificarsi conflitti tra gli utenti SAML originali e i nuovi utenti OIDC.