Autenticazione SAML 2.0 saml-2-0-authentication
Scopri come impostare e autenticare gli utenti finali (non autori di 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 ad AEM come utente autorizzato con nome.
Il flusso tipico di un’integrazione SAML di pubblicazione AEM è il seguente:
-
L’utente invia una richiesta ad AEM Publish, che indica che è necessaria l’autenticazione.
- L’utente richiede una risorsa protetta da CUG/ACL.
- L’utente richiede una risorsa soggetta a un requisito di autenticazione.
- L'utente segue un collegamento all'endpoint di accesso di AEM (ad esempio
/system/sling/login
) che richiede esplicitamente l'azione di accesso.
-
AEM invia una AuthnRequest all’IDP, richiedendo a quest’ultimo di avviare il processo di autenticazione.
-
L'utente si autentica in IDP.
- L'IDP richiede all'utente le credenziali.
- L'utente è già autenticato con l'IDP e non deve fornire ulteriori credenziali.
-
IDP genera un'asserzione SAML contenente i dati dell'utente e la firma utilizzando il certificato privato dell'IDP.
-
IDP invia l’asserzione SAML tramite HTTP POST, tramite il browser web dell’utente (RESPECTIVE_PROTECTED_PATH/saml_login), ad AEM Publish.
-
AEM Publish riceve l’asserzione SAML e ne convalida l’integrità e l’autenticità utilizzando il certificato pubblico IDP.
-
AEM Publish gestisce il record utente di AEM in base alla configurazione OSGi SAML 2.0 e al contenuto dell’asserzione SAML.
- Crea utente
- Sincronizza gli attributi utente
- Aggiorna l'iscrizione al gruppo utenti di AEM
-
AEM Publish imposta il cookie AEM
login-token
nella risposta HTTP, utilizzato per autenticare le richieste successive in AEM Publish. -
AEM Publish reindirizza l'utente all'URL in AEM Publish come specificato dal cookie
saml_request_path
.
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:
- Accesso di Responsabile dell’implementazione a Cloud Manager
- Accesso amministratore AEM all’ambiente AEM as a Cloud Service
- Accesso amministratore all'IDP
- Facoltativamente, accesso a una coppia di chiavi pubblica/privata utilizzata per crittografare i payload SAML
SAML 2.0 è supportato solo per l’autenticazione degli utilizzi in AEM Publish o Preview. 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 all'archivio fonti attendibili globale di AEM e utilizzato per convalidare la validità dell'asserzione SAML inviata dall'IDP.
- L'utente si autentica in IDP.
- IDP genera un'asserzione SAML contenente i dati dell'utente.
- IDP firma l'asserzione SAML utilizzando il certificato privato dell'IDP.
- IDP avvia un HTTP POST lato client all'endpoint SAML di AEM Publish (
.../saml_login
) che include l'asserzione SAML firmata. - AEM Publish riceve il POST HTTP contenente l’asserzione SAML firmata; può convalidare la firma utilizzando il certificato pubblico IDP.
-
Ottieni il file del certificato pubblico dall'IDP. Questo certificato consente ad AEM di convalidare l’asserzione SAML fornita ad AEM dall’IDP.
Il certificato è in formato PEM e deve essere simile al seguente:
code language-none -----BEGIN CERTIFICATE----- MIIC4jCBAcoCCQC33wnybT5QZDANBgkqhkiG9w0BAQsFADAyMQswCQYDVQQGEwJV ... m0eo2USlSRTVl7QHRTuiuSThHpLKQQ== -----END CERTIFICATE-----
-
Accedi ad AEM Author come amministratore di AEM.
-
Passa a Strumenti > Sicurezza > Archivio attendibile.
-
Crea o apri l'archivio fonti attendibili globale. Se si crea un archivio fonti attendibili globale, memorizzare la password in un luogo sicuro.
-
Espandere Aggiungi certificato da file CER.
-
Selezionare Seleziona file certificato e caricare il file certificato fornito dall'IDP.
-
Lascia vuoto Mappa certificato all'utente.
-
Seleziona Invia.
-
Il certificato appena aggiunto viene visualizzato sopra la sezione Aggiungi certificato da file CRT.
-
Prendere nota dell'alias alias, in quanto questo valore viene utilizzato nella configurazione OSGi del gestore autenticazione SAML 2.0.
-
Seleziona Salva e chiudi.
L’archivio fonti attendibili globale è configurato con il certificato pubblico dell’IDP su AEM Author, ma poiché SAML viene utilizzato solo su AEM Publish, l’archivio fonti attendibili globale deve essere replicato su AEM Publish affinché il certificato pubblico dell’IDP sia accessibile.
-
Passa a Strumenti > Distribuzione > Pacchetti.
-
Creare un pacchetto
- Nome pacchetto:
Global Trust Store
- Versione:
1.0.0
- Gruppo:
com.your.company
- Nome pacchetto:
-
Modifica il nuovo pacchetto Archivio attendibile globale.
-
Selezionare la scheda Filtri e aggiungere un filtro per il percorso radice
/etc/truststore
. -
Seleziona Fine e quindi Salva.
-
Selezionare il pulsante Genera per il pacchetto Archivio attendibilità globale.
-
Una volta generato, selezionare Altro > Replica per attivare il nodo dell'archivio fonti attendibili globale (
/etc/truststore
) in AEM Publish.
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
-
Accedi ad AEM Author come amministratore di AEM per caricare la chiave privata.
-
Passa a Strumenti > Protezione > Utenti, seleziona l'utente authentication-service e seleziona Proprietà dalla barra delle azioni superiore.
-
Selezionare la scheda Registro chiavi.
-
Crea o apri il keystore. Se crei un keystore, proteggi la password.
- Un keystore pubblico/privato è installato in questo keystore solo se è richiesta la firma AuthnRequest/la crittografia dell'asserzione SAML.
- Se questa integrazione SAML supporta la disconnessione ma non l'asserzione di firma AuthnRequest/SAML, è sufficiente un keystore vuoto.
-
Seleziona Salva e chiudi.
-
Crea un pacchetto contenente l'utente authentication-service aggiornato.
Utilizzare la seguente soluzione alternativa temporanea utilizzando i pacchetti:
-
Passa a Strumenti > Distribuzione > Pacchetti.
-
Creare un pacchetto
- Nome pacchetto:
Authentication Service
- Versione:
1.0.0
- Gruppo:
com.your.company
- Nome pacchetto:
-
Modifica il nuovo pacchetto Archivio chiavi del servizio di autenticazione.
-
Selezionare la scheda Filtri e aggiungere un filtro per il percorso radice
/home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore
.- Per trovare
<AUTHENTICATION SERVICE UUID>
, passa a Strumenti > Protezione > Utenti e seleziona l'utente authentication-service. L’UUID è l’ultima parte dell’URL.
- Per trovare
-
Seleziona Fine e quindi Salva.
-
Selezionare il pulsante Build per il pacchetto Authentication Service Key Store.
-
Una volta generato, seleziona Altro > Replica per attivare l'archivio chiavi del servizio di autenticazione in AEM Publish.
-
Installare una coppia di chiavi pubblica/privata di AEM install-aem-public-private-key-pair
L'installazione della coppia di chiavi pubblica/privata di AEM è facoltativa
AEM Publish può essere configurato per firmare le richieste di authoring (a IDP) e crittografare le asserzioni SAML (ad AEM). Ciò si ottiene fornendo una chiave privata ad AEM Publish, che corrisponde alla chiave pubblica dell'IDP.
AuthnRequest (la richiesta all'IDP da AEM Publish che avvia il processo di accesso) può essere firmata da AEM Publish. A questo scopo, AEM Publish firma la AuthnRequest utilizzando la chiave privata, in modo che l’IDP convalidi la firma utilizzando la chiave pubblica. In questo modo si garantisce all’IDP che AuthnRequest è stato avviato e richiesto da AEM Publish e non a una terza parte dannosa.
- L’utente invia una richiesta HTTP ad AEM Publish che restituisce una richiesta di autenticazione SAML all’IDP.
- AEM Publish genera la richiesta SAML da inviare all'IDP.
- AEM Publish firma la richiesta SAML utilizzando la chiave privata di AEM.
- AEM Publish avvia AuthnRequest, un reindirizzamento HTTP lato client all'IDP contenente la richiesta SAML firmata.
- IDP riceve la AuthnRequest e convalida la firma utilizzando la chiave pubblica di AEM, garantendo che AEM Publish abbia avviato la AuthnRequest.
- AEM Publish convalida quindi l’integrità e l’autenticità dell’asserzione SAML decrittografata utilizzando il certificato pubblico IDP.
Tutte le comunicazioni HTTP tra IDP e AEM Publish devono essere effettuate tramite HTTPS e quindi protette per impostazione predefinita. Tuttavia, come richiesto, le asserzioni SAML possono essere crittografate nel caso in cui sia richiesta ulteriore riservatezza oltre a quella fornita da HTTPS. A questo scopo, l’IDP crittografa i dati dell’asserzione SAML utilizzando la chiave privata e AEM Publish decrittografa l’asserzione SAML utilizzando la chiave privata.
- L'utente si autentica in IDP.
- IDP genera un'asserzione SAML contenente i dati dell'utente e la firma utilizzando il certificato privato dell'IDP.
- IDP crittografa quindi l’asserzione SAML con la chiave pubblica di AEM, che richiede la chiave privata AEM per la decrittografia.
- L’asserzione SAML crittografata viene inviata tramite il browser web dell’utente ad AEM Publish.
- AEM Publish riceve l’asserzione SAML e la decrittografa utilizzando la chiave privata di AEM.
- IDP richiede all'utente di eseguire l'autenticazione.
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.
-
Ottieni la chiave pubblica, la chiave privata (PKCS#8 in formato DER) e il file della catena di certificati (questa potrebbe essere la chiave pubblica) utilizzati per firmare la richiesta di authoring e crittografa l’asserzione SAML. Le chiavi vengono in genere fornite dal team di sicurezza dell'organizzazione IT.
- È possibile generare una coppia di chiavi autofirmate utilizzando openssl:
code language-none $ openssl req -x509 -sha256 -days 365 -newkey rsa:4096 -keyout aem-private.key -out aem-public.crt # Provide a password (keep in safe place), and other requested certificate information # Convert the keys to AEM's required format $ openssl rsa -in aem-private.key -outform der -out aem-private.der $ openssl pkcs8 -topk8 -inform der -nocrypt -in aem-private.der -outform der -out aem-private-pkcs8.der
-
Carica la chiave pubblica nell'IDP.
- Utilizzando il metodo
openssl
precedente, la chiave pubblica è il fileaem-public.crt
.
- Utilizzando il metodo
-
Accedi ad AEM Author come amministratore di AEM per caricare la chiave privata.
-
Passa a Strumenti > Sicurezza > Archivio attendibile, seleziona l'utente authentication-service e seleziona Proprietà dalla barra delle azioni superiore.
-
Passa a Strumenti > Protezione > Utenti, seleziona l'utente authentication-service e seleziona Proprietà dalla barra delle azioni superiore.
-
Selezionare la scheda Registro chiavi.
-
Crea o apri il keystore. Se crei un keystore, proteggi la password.
-
Seleziona Aggiungi chiave privata dal file DER e aggiungi la chiave privata e il file della catena ad AEM:
- Alias: fornire un nome significativo, spesso il nome dell'IDP.
- File di chiave privata: carica il file di chiave privata (PKCS#8 in formato DER).
- Utilizzando il metodo
openssl
, si tratta del fileaem-private-pkcs8.der
- Utilizzando il metodo
- Selezionare il file della catena di certificati: caricare il file della catena associato (potrebbe essere la chiave pubblica).
- Utilizzando il metodo
openssl
, si tratta del fileaem-public.crt
- Utilizzando il metodo
- Seleziona Invia
-
Il certificato appena aggiunto viene visualizzato sopra la sezione Aggiungi certificato da file CRT.
- Prendere nota dell'alias alias utilizzato nella configurazione OSGi del gestore di autenticazione SAML 2.0
-
Seleziona Salva e chiudi.
-
Crea un pacchetto contenente l'utente authentication-service aggiornato.
Utilizzare la seguente soluzione alternativa temporanea utilizzando i pacchetti:
-
Passa a Strumenti > Distribuzione > Pacchetti.
-
Creare un pacchetto
- Nome pacchetto:
Authentication Service
- Versione:
1.0.0
- Gruppo:
com.your.company
- Nome pacchetto:
-
Modifica il nuovo pacchetto Archivio chiavi del servizio di autenticazione.
-
Selezionare la scheda Filtri e aggiungere un filtro per il percorso radice
/home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore
.- Per trovare
<AUTHENTICATION SERVICE UUID>
, passa a Strumenti > Protezione > Utenti e seleziona l'utente authentication-service. L’UUID è l’ultima parte dell’URL.
- Per trovare
-
Seleziona Fine e quindi Salva.
-
Selezionare il pulsante Build per il pacchetto Authentication Service Key Store.
-
Una volta generato, seleziona Altro > Replica per attivare l'archivio chiavi del servizio di autenticazione in AEM Publish.
-
Configura gestore autenticazione SAML 2.0 configure-saml-2-0-authentication-handler
La configurazione SAML di 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 di pubblicazione AEM as a Cloud Service può avere più strutture di risorse discrete di copertura della configurazione SAML dell’archivio; questo è utile per le distribuzioni AEM multisito.
Configurazione OSGi del gestore autenticazione Adobe Granite SAML 2.0 configure-saml-2-0-authentication-handler-osgi-configuration
table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 14-row-6 15-row-6 16-row-6 17-row-6 18-row-6 19-row-6 20-row-6 21-row-6 22-row-6 23-row-6 24-row-6 25-row-6 26-row-6 27-row-6 3-align-center 4-align-center 10-align-center 11-align-center 17-align-center 18-align-center 24-align-center 25-align-center 31-align-center 32-align-center 38-align-center 39-align-center 45-align-center 46-align-center 52-align-center 53-align-center 59-align-center 60-align-center 66-align-center 67-align-center 73-align-center 74-align-center 80-align-center 81-align-center 87-align-center 88-align-center 94-align-center 95-align-center 101-align-center 102-align-center 108-align-center 109-align-center 115-align-center 116-align-center 122-align-center 123-align-center 129-align-center 130-align-center 136-align-center 137-align-center 143-align-center 144-align-center 150-align-center 151-align-center 157-align-center 158-align-center 164-align-center 165-align-center 171-align-center 172-align-center 178-align-center 179-align-center 185-align-center 186-align-center 192-align-center 193-align-center | |||||
---|---|---|---|---|---|
Proprietà OSGi | Obbligatorio | Formato del valore | Valore predefinito | Descrizione | |
Percorsi | path |
✔ | Array di stringhe | / |
Percorsi AEM per i quali viene utilizzato questo gestore di autenticazione. |
URL IDP | idpUrl |
✔ | Stringa | URL IDP viene inviata la richiesta di autenticazione SAML. | |
Alias certificato IDP | idpCertAlias |
✔ | Stringa | Alias del certificato IDP trovato nell'archivio fonti attendibili globali di AEM | |
Reindirizzamento HTTP IDP | idpHttpRedirect |
✘ | Booleano | false |
Indica se si tratta di un reindirizzamento HTTP all’URL IDP anziché inviare una AuthnRequest. Impostato su true per l'autenticazione avviata da IDP. |
Identificatore IDP | idpIdentifier |
✘ | Stringa | ID IDP univoco per garantire l’univocità di utenti e gruppi di AEM. Se vuoto, viene utilizzato serviceProviderEntityId . |
|
URL servizio consumer di asserzione | assertionConsumerServiceURL |
✘ | Stringa | Attributo URL AssertionConsumerServiceURL in AuthnRequest che specifica dove inviare il messaggio <Response> ad AEM. |
|
ID entità SP | serviceProviderEntityId |
✔ | Stringa | Identifica in modo univoco AEM nell’IDP; di solito il nome host di AEM. | |
Crittografia SP | useEncryption |
✘ | Booleano | true |
Indica se l’IDP crittografa le asserzioni SAML. Richiede spPrivateKeyAlias e keyStorePassword per essere impostati. |
Alias chiave privata SP | spPrivateKeyAlias |
✘ | Stringa | Alias della chiave privata nell'archivio chiavi dell'utente authentication-service . Obbligatorio se useEncryption è impostato su true . |
|
Password archivio chiavi SP | keyStorePassword |
✘ | Stringa | Password dell'archivio chiavi dell'utente del servizio di autenticazione. Obbligatorio se useEncryption è impostato su true . |
|
Reindirizzamento predefinito | defaultRedirectUrl |
✘ | Stringa | / |
URL di reindirizzamento predefinito dopo l’autenticazione riuscita. Può essere relativo all'host AEM (ad esempio, /content/wknd/us/en/html ). |
Attributo ID utente | userIDAttribute |
✘ | Stringa | uid |
Nome dell’attributo di asserzione SAML contenente l’ID utente dell’utente AEM. Lascia vuoto per usare Subject:NameId . |
Creazione automatica di utenti AEM | createUser |
✘ | Booleano | true |
Indica se gli utenti di AEM vengono creati in caso di autenticazione riuscita. |
Percorso intermedio per utenti AEM | userIntermediatePath |
✘ | Stringa | Durante la creazione di utenti AEM, questo valore viene utilizzato come percorso intermedio (ad esempio, /home/users/<userIntermediatePath>/jane@wknd.com ). Richiede createUser per essere impostato su true . |
|
Attributi utente di AEM | synchronizeAttributes |
✘ | Array di stringhe | Elenco dei mapping di attributi SAML da archiviare nell'utente AEM nel formato [ "saml-attribute-name=path/relative/to/user/node" ] (ad esempio, [ "firstName=profile/givenName" ] ). Consulta l'elenco completo degli attributi nativi di AEM. |
|
Aggiungere un utente ai gruppi di AEM | addGroupMemberships |
✘ | Booleano | true |
Indica se un utente di AEM viene aggiunto automaticamente ai gruppi di utenti di AEM dopo la corretta autenticazione. |
Attributo di iscrizione al gruppo AEM | groupMembershipAttribute |
✘ | Stringa | groupMembership |
Nome dell’attributo di asserzione SAML contenente un elenco di gruppi di utenti AEM a cui l’utente deve essere aggiunto. Richiede addGroupMemberships per essere impostato su true . |
Gruppi predefiniti di AEM | defaultGroups |
✘ | Array di stringhe | Un elenco di gruppi di utenti autenticati di AEM viene sempre aggiunto a (ad esempio, [ "wknd-user" ] ). Richiede addGroupMemberships per essere impostato su true . |
|
Formato NameIDPolicy | nameIdFormat |
✘ | Stringa | urn:oasis:names:tc:SAML:2.0:nameid-format:transient |
Valore del parametro di formato NameIDPolicy da inviare al messaggio AuthnRequest. |
Memorizza risposta SAML | storeSAMLResponse |
✘ | Booleano | false |
Indica se il valore samlResponse è archiviato nel nodo AEM cq:User . |
Gestisci disconnessione | handleLogout |
✘ | Booleano | false |
Indica se la richiesta di disconnessione è gestita da questo gestore di autenticazione SAML. Richiede logoutUrl per essere impostato. |
URL disconnessione | logoutUrl |
✘ | Stringa | URL dell'IDP a cui viene inviata la richiesta di disconnessione SAML. Obbligatorio se handleLogout è impostato su true . |
|
Tolleranza orologio | clockTolerance |
✘ | Numero intero | 60 |
La tolleranza di sfasamento dell’orologio IDP e AEM (SP) durante la convalida delle asserzioni SAML. |
Metodo digest | digestMethod |
✘ | Stringa | http://www.w3.org/2001/04/xmlenc#sha256 |
Algoritmo di digest utilizzato dall'IDP per firmare un messaggio SAML. |
Metodo di firma | signatureMethod |
✘ | Stringa | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
Algoritmo di firma utilizzato dall'IDP per firmare un messaggio SAML. |
Tipo di sincronizzazione identità | identitySyncType |
✘ | default oppure idp |
default |
Non modificare il valore predefinito di from per AEM as a Cloud Service. |
Classificazione del servizio | service.ranking |
✘ | Numero intero | 5002 |
Configurazioni di classificazione superiori sono preferite per lo stesso path . |
Attributi utente di AEM aem-user-attributes
AEM utilizza i seguenti attributi utente, che possono essere compilati tramite la proprietà synchronizeAttributes
nella configurazione OSGi del gestore autenticazione SAML 2.0 di Adobe Granite. Qualsiasi attributo IDP può essere sincronizzato con qualsiasi proprietà utente di AEM, tuttavia la mappatura ad AEM usa le proprietà attributo (elencate di seguito) consente ad AEM di utilizzarle naturalmente.
table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2 6-row-2 7-row-2 8-row-2 9-row-2 10-row-2 11-row-2 | |
---|---|
Attributo utente | Percorso proprietà relativa dal nodo rep:User |
Titolo (ad esempio, Mrs ) |
profile/title |
Nome (ossia nome) | profile/givenName |
Cognome (ad esempio cognome) | profile/familyName |
Qualifica | profile/jobTitle |
Indirizzo e-mail | profile/email |
Indirizzo | profile/street |
Città | profile/city |
Codice postale | profile/postalCode |
Paese | profile/country |
Numero di telefono | profile/phoneNumber |
Informazioni su di me | profile/aboutMe |
-
Crea un file di configurazione OSGi nel progetto in
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json
e aprilo nell'IDE.- Cambia
/wknd-examples/
in/<project name>/
- L'identificatore dopo
~
nel nome file deve identificare in modo univoco questa configurazione, quindi potrebbe essere il nome dell'IDP, ad esempio...~okta.cfg.json
. Il valore deve essere alfanumerico con trattini.
- Cambia
-
Incolla il seguente JSON nel file
com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json
e aggiorna i riferimentiwknd
in base alle esigenze.code language-json { "path": [ "/content/wknd", "/content/dam/wknd" ], "idpCertAlias": "$[env:SAML_IDP_CERT_ALIAS;default=certalias___1652125559800]", "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/exk4z55r44Jz9C6am5d7]", "idpUrl": "$[env:SAML_IDP_URL;default=https://dev-5511372.okta.com/app/dev-5511372_aemasacloudservice_1/exk4z55r44Jz9C6am5d7/sso/saml]", "serviceProviderEntityId": "$[env:SAML_AEM_ID;default=https://publish-p123-e456.adobeaemcloud.com]", "useEncryption": false, "createUser": true, "userIntermediatePath": "wknd/idp", "synchronizeAttributes":[ "firstName=profile/givenName" ], "addGroupMemberships": true, "defaultGroups": [ "wknd-users" ] }
-
Aggiorna i valori come richiesto dal progetto. Per le descrizioni delle proprietà di configurazione, vedi il glossario di configurazione OSGi Gestore autenticazione SAML 2.0 sopra
-
È consigliabile, ma non obbligatorio, utilizzare le variabili di ambiente OSGi e i segreti, quando i valori possono non essere sincronizzati con il ciclo di rilascio o quando i valori differiscono tra tipi di ambiente/livelli di servizio simili. I valori predefiniti possono essere impostati con la sintassi
$[env:..;default=the-default-value]"
, come illustrato sopra.
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
-
Apri
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json
nell'IDE. -
Aggiungere le tre proprietà
useEncryption
,spPrivateKeyAlias
ekeyStorePassword
come illustrato di seguito.code language-json { "path": [ "/content/wknd", "/content/dam/wknd" ], "idpCertAlias": "$[env:SAML_IDP_CERT_ALIAS;default=certalias___1234567890]", "idpIdentifier": "$[env:SAML_IDP_ID;default=http://www.okta.com/abcdef1235678]", "idpUrl": "$[env:SAML_IDP_URL;default=https://dev-5511372.okta.com/app/dev-123567890_aemasacloudservice_1/abcdef1235678/sso/saml]", "serviceProviderEntityId": "$[env:SAML_AEM_ID;default=https://publish-p123-e456.adobeaemcloud.com]", "useEncryption": true, "spPrivateKeyAlias": "$[env:SAML_AEM_KEYSTORE_ALIAS;default=aem-saml-encryption]", "keyStorePassword": "$[secret:SAML_AEM_KEYSTORE_PASSWORD]", "createUser": true, "userIntermediatePath": "wknd/idp" "synchronizeAttributes":[ "firstName=profile/givenName" ], "addGroupMemberships": true, "defaultGroups": [ "wknd-users" ] }
-
Le tre proprietà di configurazione OSGi necessarie per la crittografia sono:
useEncryption
impostato sutrue
spPrivateKeyAlias
contiene l'alias della voce keystore per la chiave privata utilizzata dall'integrazione SAML.keyStorePassword
contiene una variabile di configurazione segreta OSGi contenente la password del keystore utenteauthentication-service
.
Configura filtro Referrer
Durante il processo di autenticazione SAML, l'IDP avvia un HTTP POST lato client all'endpoint .../saml_login
di AEM Publish. Se l'IDP e la pubblicazione AEM esistono 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.
-
Crea (o modifica) un file di configurazione OSGi nel progetto in
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/org.apache.sling.security.impl.ReferrerFilter.cfg.json
.- Cambia
/wknd-examples/
in/<project name>/
- Cambia
-
Verificare che il valore
allow.empty
sia impostato sutrue
, cheallow.hosts
(o se si preferisce,allow.hosts.regexp
) contenga l'origine dell'IDP e chefilter.methods
includaPOST
. La configurazione OSGi deve essere simile a:code language-json { "allow.empty": true, "allow.hosts.regexp": [ ], "allow.hosts": [ "$[env:SAML_IDP_REFERRER;default=dev-123567890.okta.com]" ], "filter.methods": [ "POST", ], "exclude.agents.regexp": [ ] }
AEM Publish supporta una singola configurazione del filtro Referrer, in modo da unire i requisiti di configurazione SAML con eventuali 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 HTTP POST lato client all'endpoint .../saml_login
di AEM Publish. Se l'IDP e la pubblicazione AEM esistono su host/domini diversi, è necessario configurare la condivisione CORS (CRoss-Origin Resource Sharing)di AEM Publish per consentire i POST HTTP dall'host/dominio dell'IDP.
L'intestazione Origin
di questa richiesta HTTP POST in genere ha un valore diverso rispetto all'host AEM Publish, pertanto è necessaria la configurazione CORS.
Durante il test dell'autenticazione SAML sul SDK AEM locale (localhost:4503
), l'IDP può impostare l'intestazione Origin
su null
. In tal caso, aggiungere "null"
all'elenco alloworigin
.
-
Crea un file di configurazione OSGi nel progetto in
/ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.cors.impl.CORSPolicyImpl~saml.cfg.json
- Cambia
/wknd-examples/
con il nome del progetto - L'identificatore dopo
~
nel nome file deve identificare in modo univoco questa configurazione, quindi potrebbe essere il nome dell'IDP, ad esempio...CORSPolicyImpl~okta.cfg.json
. Il valore deve essere alfanumerico con trattini.
- Cambia
-
Incolla il seguente JSON nel file
com.adobe.granite.cors.impl.CORSPolicyImpl~...cfg.json
.
{
"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.
Configura 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 /saml_login
registrato di AEM (configurato nell'IDP). Questo HTTP POST a /saml_login
è bloccato per impostazione predefinita in Dispatcher, pertanto deve essere consentito esplicitamente utilizzando la seguente regola di Dispatcher:
- Apri
dispatcher/src/conf.dispatcher.d/filters/filters.any
nell'IDE. - Aggiungere nella parte inferiore del file una regola Consenti per i POST HTTP agli URL che terminano con
/saml_login
.
...
# 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.
Appartenenza a gruppo dinamico
L'appartenenza al gruppo dinamico è una funzionalità di Apache Jackrabbit Oak che aumenta le prestazioni della valutazione e del provisioning del gruppo. Questa sezione descrive come vengono memorizzati utenti e gruppi quando questa funzione è abilitata e come modificare la configurazione del gestore di autenticazione SAML per abilitarlo per gli ambienti nuovi o esistenti.
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"
],
...
}
Abilitare l’iscrizione al gruppo dinamico per gli utenti SAML negli ambienti esistenti
Come spiegato nella sezione precedente, il formato degli utenti e dei gruppi esterni è leggermente diverso da quello utilizzato per gli utenti e i gruppi locali. È possibile definire un nuovo ACL per i gruppi esterni ed eseguire il provisioning di nuovi utenti esterni, oppure utilizzare lo strumento di migrazione come descritto di seguito.
Abilitazione dell’iscrizione dinamica ai gruppi per gli ambienti esistenti con utenti esterni
Il gestore di autenticazione SAML crea utenti esterni quando viene specificata la seguente proprietà: "identitySyncType": "idp"
. In questo caso, è possibile abilitare l'appartenenza al gruppo dinamico modificando questa proprietà in: "identitySyncType": "idp_dynamic"
. Non è richiesta alcuna migrazione.
Migrazione automatica all'appartenenza a gruppi dinamici per gli ambienti esistenti con utenti locali
Il gestore di autenticazione SAML crea utenti locali quando viene specificata la proprietà seguente: "identitySyncType": "default"
. Questo è anche il valore predefinito quando la proprietà non è specificata. In questa sezione vengono descritti i passaggi eseguiti dalla procedura di migrazione automatica.
Quando questa migrazione è abilitata, viene eseguita durante l’autenticazione dell’utente e consiste dei seguenti passaggi:
- L’utente locale viene migrato a un utente esterno mantenendo il nome utente originale. Ciò implica che gli utenti locali migrati, che ora agiscono come utenti esterni, manterranno il nome utente originale invece di seguire la sintassi di denominazione indicata nella sezione precedente. Verrà aggiunta una proprietà aggiuntiva denominata:
rep:externalId
con il valore di[user name];[idp]
. UtentePrincipalName
non modificato. - Per ogni gruppo esterno ricevuto nell'asserzione SAML, viene creato un gruppo esterno. Se esiste un gruppo locale corrispondente, il gruppo esterno viene aggiunto al gruppo locale come membro.
- L'utente viene aggiunto come membro del gruppo esterno.
- L’utente locale viene quindi rimosso da tutti i gruppi locali Saml di cui era membro. I gruppi locali Saml sono identificati dalla proprietà OAK:
rep:managedByIdp
. Questa proprietà viene impostata dal gestore di autenticazione Saml quando l'attributosyncType
non è specificato o è impostato sudefault
.
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 è archiviata nel profilo utente nella proprietà rep:externalPrincipalNames
Come configurare la migrazione automatica all'appartenenza a un gruppo dinamico
- Abilitare la proprietà
"identitySyncType": "idp_dynamic_simplified_id"
nel file di configurazione OSGi SAML:com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json
: - Configurare il nuovo servizio OSGi con PID di fabbrica che inizia con:
com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration~
. Ad esempio, un PID può essere:com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration~myIdP
. Imposta la seguente proprietà:
{
"idpIdentifier": "<value of IDP Identifier (idpIdentifier)" property from the "com.adobe.granite.auth.saml.SamlAuthenticationHandler" configuration to be migrated>"
}
Per migrare più configurazioni SAML, è necessario creare più configurazioni OSGi factory per com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration
, ognuna delle quali specifica un idpIdentifier
per la migrazione.
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.
Memorizzazione in cache protetta durante l’utilizzo di SAML
Nell’istanza di pubblicazione di AEM, la maggior parte delle pagine viene generalmente memorizzata nella cache. Tuttavia, per i percorsi protetti da SAML, la memorizzazione nella cache deve essere disabilitata o abilitata utilizzando la configurazione auth_checker. Per ulteriori informazioni, fare riferimento ai dettagli forniti qui
Tieni presente che se memorizzi nella cache i percorsi protetti senza abilitare auth_checker, potresti riscontrare un comportamento imprevedibile.
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:
resource
path
🔗 del gestore di autenticazione OSGi Adobe Granite SAML 2.0 Authentication Handler.saml_request_path
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:
resource
path
🔗 del gestore di autenticazione OSGi Adobe Granite SAML 2.0 Authentication Handler.saml_request_path
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 /system/sling/login
di AEM 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" }