Autenticazione SAML 2.0 saml-2-0-authentication

Scopri come impostare e autenticare gli utenti finali (non autori AEM) in un IDP compatibile con SAML 2.0 a tua scelta.

Quale SAML per AEM as a Cloud Service?

L’integrazione SAML 2.0 con AEM Publish (o Anteprima), consente agli utenti finali di un’esperienza web basata su AEM di autenticarsi in un IDP (Identity Provider) non Adobe e di accedere all’AEM come utente autorizzato con nome.

Procedura dettagliata della configurazione

Questo video illustra come configurare l’integrazione SAML 2.0 con il servizio AEM as a Cloud Service Publish e utilizzare Okta come IDP.

Prerequisiti

Per configurare l’autenticazione SAML 2.0 sono necessari i seguenti elementi:

SAML 2.0 è supportato solo per l’autenticazione degli utilizzi in Publish o Anteprima AEM. Per gestire l'autenticazione di AEM Author tramite e IDP, integra l'IDP con Adobe IMS.

Installare il certificato pubblico IDP su AEM

Il certificato pubblico dell'IDP viene aggiunto al Global Trust Store dell'AEM e utilizzato per convalidare la validità dell'asserzione SAML inviata dall'IDP.

L'archivio fonti attendibili globale è configurato con il certificato pubblico dell'IDP per l'autore AEM, ma poiché SAML viene utilizzato solo in AEM Publish, l'archivio fonti attendibili globale deve essere replicato in AEM Publish affinché il certificato pubblico dell'IDP sia accessibile.

Crea keystore del servizio di autenticazione authentication-service-keystore

È necessario creare un keystore per il servizio di autenticazione quando la proprietà di configurazione OSGi handleLogout del gestore di autenticazione SAML 2.0 è impostata su true o quando è richiesta la firma AuthnRequest/la crittografia dell'asserzione SAML

Installare una coppia di chiavi pubblica/privata AEM install-aem-public-private-key-pair

L'installazione della coppia di chiavi pubblica/privata AEM è facoltativa

AEM Publish può essere configurato per firmare AuthnRequests (a IDP) e crittografare le asserzioni SAML (a AEM). Ciò si ottiene fornendo una chiave privata al Publish dell'AEM, che corrisponde alla chiave pubblica dell'IDP.

Sia la firma AuthnRequest che la crittografia delle asserzioni SAML sono facoltative, ma entrambe sono abilitate, utilizzando la proprietà di configurazione OSGi useEncryption🔗 del gestore di autenticazione SAML 2.0, che indica che è possibile utilizzare entrambe o nessuna delle due.

Configura gestore autenticazione SAML 2.0 configure-saml-2-0-authentication-handler

La configurazione SAML dell'AEM viene eseguita tramite la configurazione OSGi Adobe Granite SAML 2.0 Authentication Handler.
La configurazione è una configurazione di fabbrica OSGi, il che significa che un singolo servizio AEM as a Cloud Service Publish può avere più strutture di risorse discrete di copertura della configurazione SAML dell’archivio; questo è utile per le distribuzioni AEM multisito.

Le configurazioni OSGi per ambiente (config.publish.dev, config.publish.stage e config.publish.prod) possono essere definite con attributi specifici se la configurazione SAML varia da un ambiente all'altro.

Usa crittografia

Quando si crittografano le asserzioni AuthnRequest e SAML, sono necessarie le seguenti proprietà: useEncryption, spPrivateKeyAlias e keyStorePassword. keyStorePassword contiene una password, pertanto il valore non deve essere memorizzato nel file di configurazione OSGi, ma inserito utilizzando valori di configurazione segreti

Configura filtro Referrer

Durante il processo di autenticazione SAML, l'IDP avvia un POST HTTP lato client per l'endpoint .../saml_login del Publish AEM. Se il Publish IDP e AEM si trovano in un'origine diversa, il filtro referrer di AEM Publish viene configurato tramite la configurazione OSGi per consentire i POST HTTP dall'origine dell'IDP.

AEM Publish supporta una singola configurazione del filtro Referrer, in modo da unire i requisiti di configurazione SAML con tutte le configurazioni esistenti.

Le configurazioni OSGi per ambiente (config.publish.dev, config.publish.stage e config.publish.prod) possono essere definite con attributi specifici se allow.hosts (o allow.hosts.regex) variano da un ambiente all'altro.

Configurare la condivisione CORS (Cross-Origin Resource Sharing)

Durante il processo di autenticazione SAML, l'IDP avvia un POST HTTP lato client per l'endpoint .../saml_login del Publish AEM. Se l'IDP e il Publish AEM esistono in host/domini diversi, è necessario configurare la condivisione delle risorse CORS CRoss-Origin Resource Sharing di AEM Publish per consentire i POST HTTP dall'host/dominio dell'IDP.

L'intestazione Origin della richiesta HTTP POST in genere ha un valore diverso rispetto all'host Publish dell'AEM, pertanto è necessaria la configurazione CORS.

Durante il test dell'autenticazione SAML sull'SDK AEM locale (localhost:4503), l'IDP può impostare l'intestazione Origin su null. In tal caso, aggiungere "null" all'elenco alloworigin.

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

Le configurazioni OSGi per ambiente (config.publish.dev, config.publish.stage e config.publish.prod) possono essere definite con attributi specifici se alloworigin e allowedpaths variano da un ambiente all'altro.

Configurare AEM Dispatcher per consentire SAML HTTP POST

Dopo aver eseguito correttamente l'autenticazione nell'IDP, l'IDP orchestrerà un POST HTTP per tornare all'endpoint registrato /saml_login dell'AEM (configurato nell'IDP). Questo POST HTTP a /saml_login è bloccato per impostazione predefinita in Dispatcher, pertanto deve essere esplicitamente consentito utilizzando la seguente regola di Dispatcher:

...

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

Se la riscrittura dell'URL nel server web Apache è configurata (dispatcher/src/conf.d/rewrites/rewrite.rules), assicurati che le richieste agli endpoint .../saml_login non vengano gestite accidentalmente.

Abilitare l’iscrizione al gruppo dinamico per gli utenti SAML nei nuovi ambienti

Per migliorare in modo significativo le prestazioni di valutazione dei gruppi nei nuovi ambienti AEM as a Cloud Service, si consiglia di attivare la funzione di iscrizione al gruppo dinamico nei nuovi ambienti.
Questo è anche un passaggio necessario quando viene attivata la sincronizzazione dei dati. Ulteriori dettagli qui .
A questo scopo, aggiungi la seguente proprietà al file di configurazione OSGI:

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

Con questa configurazione, utenti e gruppi vengono creati come Utenti esterni Oak. In AEM, gli utenti e i gruppi esterni dispongono di un rep:principalName predefinito composto da [user name];[idp] o [group name];[idp].
Tenere presente che gli elenchi di controllo di accesso (ACL) sono associati al nome principale degli utenti o dei gruppi.
Quando si distribuisce questa configurazione in una distribuzione esistente in cui in precedenza identitySyncType non era specificato o impostato su default, verranno creati nuovi utenti e gruppi e a questi nuovi utenti e gruppi deve essere applicato l'ACL. I gruppi esterni non possono contenere utenti locali. Repoinit può essere utilizzato per creare ACL per i gruppi esterni SAML, anche se verranno creati solo quando l'utente eseguirà un accesso.
Per evitare il refactoring in ACL, è stata implementata una funzionalità di migrazione standard.

Memorizzazione delle appartenenze in gruppi locali ed esterni con appartenenza a gruppi dinamici

Nei gruppi locali i membri del gruppo sono memorizzati nell'attributo oak: rep:members. L’attributo contiene l’elenco degli UID di ogni membro del gruppo. Ulteriori dettagli sono disponibili qui.
Esempio:

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

I gruppi esterni con appartenenza dinamica al gruppo non memorizzano alcun membro nella voce del gruppo.
L'appartenenza al gruppo viene invece memorizzata nelle voci utente. Ulteriori informazioni sono disponibili qui. Ad esempio, questo è il nodo OAK del gruppo:

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

Questo è il nodo per un membro utente di quel gruppo:

{
  "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"
  ],
  ...
}

Migrazione automatica all'appartenenza a gruppi dinamici per gli ambienti esistenti

Quando questa migrazione è abilitata, viene eseguita durante l’autenticazione dell’utente e consiste dei seguenti passaggi:

Ad esempio, se prima della migrazione user1 è un utente locale e un membro del gruppo locale group1, dopo la migrazione si verificheranno le seguenti modifiche:
user1 diventa un utente esterno. Attributo rep:externalId aggiunto al suo profilo.
user1 diventa membro del gruppo esterno: group1;idp
user1 non è più membro diretto del gruppo locale: group1
group1;idp è membro del gruppo locale: group1.
user1 è quindi membro del gruppo locale: group1 sebbene ereditarietà

L'appartenenza al gruppo per i gruppi esterni è memorizzata nel profilo utente nell'attributo rep:authorizableId

Come configurare la migrazione automatica all'appartenenza a un gruppo dinamico

{
  "idpIdentifier": "<vaule of identitySyncType of saml configuration to be migrated>"
}

Distribuzione della configurazione SAML

Le configurazioni OSGi devono essere salvate in Git e distribuite in AEM as a Cloud Service utilizzando 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

Distribuire il ramo Git Cloud Manager di destinazione (in questo esempio, develop) utilizzando una pipeline di distribuzione full stack.

Richiamare l’autenticazione SAML

Il flusso di autenticazione SAML può essere richiamato da una pagina web del sito AEM, creando un collegamento creato appositamente o un pulsante. I parametri descritti di seguito possono essere impostati a livello di programmazione in base alle esigenze. Ad esempio, un pulsante di accesso può impostare saml_request_path, ovvero il punto in cui l'utente viene indirizzato dopo l'autenticazione SAML, su pagine AEM diverse, in base al contesto del pulsante.

richiesta GET

L’autenticazione SAML può essere richiamata creando una richiesta HTTP GET nel formato:

HTTP GET /system/sling/login

e fornendo parametri di query:

Questo collegamento HTML, ad esempio, attiverà il flusso di accesso SAML e, in caso di esito positivo, porterà l'utente a /content/wknd/us/en/protected/page.html. Questi parametri di query possono essere impostati a livello di programmazione in base alle esigenze.

<a href="/system/sling/login?resource=/content/wknd&saml_request_path=/content/wknd/us/en/protected/page.html">
    Log in using SAML
</a>

richiesta POST

L’autenticazione SAML può essere richiamata creando una richiesta HTTP POST nel formato:

HTTP POST /system/sling/login

e fornendo i dati del modulo:

Questo pulsante HTML, ad esempio, utilizzerà un POST HTTP per attivare il flusso di accesso SAML e, in caso di esito positivo, porterà l'utente a /content/wknd/us/en/protected/page.html. Questi parametri dei dati del modulo possono essere impostati a livello di programmazione in base alle esigenze.

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

Configurazione Dispatcher

Entrambi i metodi HTTP GET e POST richiedono l'accesso client agli endpoint AEM /system/sling/login e pertanto devono essere consentiti tramite AEM Dispatcher.

Consenti i pattern URL necessari in base all’utilizzo di GET o POST

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