Autenticazione SAML 2.0
- Si applica a:
- Experience Manager as a Cloud Service
Creato per:
- Intermedio
- Sviluppatore
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:
-----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
È 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
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:
$ 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
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
path
/
idpUrl
idpCertAlias
idpHttpRedirect
false
true
per l'autenticazione avviata da IDP.idpIdentifier
serviceProviderEntityId
.assertionConsumerServiceURL
AssertionConsumerServiceURL
in AuthnRequest che specifica dove inviare il messaggio <Response>
ad AEM.serviceProviderEntityId
useEncryption
true
spPrivateKeyAlias
e keyStorePassword
per essere impostati.spPrivateKeyAlias
authentication-service
. Obbligatorio se useEncryption
è impostato su true
.keyStorePassword
useEncryption
è impostato su true
.defaultRedirectUrl
/
/content/wknd/us/en/html
).userIDAttribute
uid
Subject:NameId
.createUser
true
userIntermediatePath
/home/users/<userIntermediatePath>/jane@wknd.com
). Richiede createUser
per essere impostato su true
.synchronizeAttributes
[ "saml-attribute-name=path/relative/to/user/node" ]
(ad esempio, [ "firstName=profile/givenName" ]
). Consulta l'elenco completo degli attributi nativi di AEM.addGroupMemberships
true
groupMembershipAttribute
groupMembership
addGroupMemberships
per essere impostato su true
.defaultGroups
[ "wknd-user" ]
). Richiede addGroupMemberships
per essere impostato su true
.nameIdFormat
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
storeSAMLResponse
false
samlResponse
è archiviato nel nodo AEM cq:User
.handleLogout
false
logoutUrl
per essere impostato.logoutUrl
handleLogout
è impostato su true
.clockTolerance
60
digestMethod
http://www.w3.org/2001/04/xmlenc#sha256
signatureMethod
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
identitySyncType
default
oppure idp
default
from
per AEM as a Cloud Service.service.ranking
5002
path
.Attributi utente di AEM
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.
rep:User
Mrs
)profile/title
profile/givenName
profile/familyName
profile/jobTitle
profile/email
profile/street
profile/city
profile/postalCode
profile/country
profile/phoneNumber
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.{ "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.{ "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:{ "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" }