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 Pubblicazione (o Anteprima) AEM 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.

Autore AEM
Pubblicazione AEM
Supporto SAML 2.0
Comprendere il flusso SAML 2.0 con AEM

Il flusso tipico di un’integrazione AEM Publish SAML è il seguente:

  1. L’utente invia una richiesta a Pubblicazione AEM dove 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 AEM (ad es. /system/sling/login) che richiede esplicitamente l’azione di accesso.
  2. L’AEM invia una AuthnRequest all’IDP, richiedendo a quest’ultimo di avviare il processo di autenticazione.

  3. 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.
  4. IDP genera un'asserzione SAML contenente i dati dell'utente e la firma utilizzando il certificato privato dell'IDP.

  5. IDP invia l’asserzione SAML tramite HTTP POST, tramite il browser web dell’utente, a AEM Publish.

  6. La pubblicazione AEM riceve l'asserzione SAML e ne convalida l'integrità e l'autenticità utilizzando il certificato pubblico IDP.

  7. AEM Publish gestisce il record utente AEM in base alla configurazione OSGi SAML 2.0 e al contenuto della SAML Assertion.

    • Crea utente
    • Sincronizza gli attributi utente
    • Aggiorna l'iscrizione al gruppo di utenti AEM
  8. Pubblicazione AEM imposta l'AEM login-token cookie nella risposta HTTP, utilizzato per autenticare le richieste successive alla pubblicazione AEM.

  9. Pubblicazione AEM reindirizza l’utente all’URL nella pubblicazione AEM come specificato da saml_request_path cookie.

Procedura dettagliata della configurazione

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

Prerequisiti

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

  • Accesso a Cloud Manager da parte di Deployment Manager
  • Accesso dell’amministratore AEM all’ambiente as a Cloud Service AEM
  • 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 Pubblicazione o Anteprima AEM. Per gestire l’autenticazione di AEM Author tramite e IDP, integrare IDP con Adobe IMS.

Installare il certificato pubblico IDP su AEM

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

Flusso di firma asserzione SAML

SAML 2.0 - Firma dell’asserzione SAML IDP

  1. L'utente si autentica in IDP.
  2. IDP genera un'asserzione SAML contenente i dati dell'utente.
  3. IDP firma l'asserzione SAML utilizzando il certificato privato dell'IDP.
  4. IDP avvia un POST HTTP lato client per l'endpoint SAML della pubblicazione AEM (.../saml_login) che include l'asserzione SAML firmata.
  5. La pubblicazione AEM riceve il POST HTTP contenente l'asserzione SAML firmata, può convalidare la firma utilizzando il certificato pubblico IDP.

Aggiungere il certificato pubblico IDP allarchivio fonti attendibili globale

  1. Ottenere il certificato pubblico dall'IDP. Questo certificato consente all'AEM di convalidare l'asserzione SAML fornita all'AEM dall'IDP.

    Il certificato è in formato PEM e deve essere simile al seguente:

    code language-none
    -----BEGIN CERTIFICATE-----
    MIIC4jCBAcoCCQC33wnybT5QZDANBgkqhkiG9w0BAQsFADAyMQswCQYDVQQGEwJV
    ...
    m0eo2USlSRTVl7QHRTuiuSThHpLKQQ==
    -----END CERTIFICATE-----
    
  2. Accedi a AEM Author come amministratore AEM.

  3. Accedi a Strumenti > Protezione > Archivio fonti attendibili.

  4. Crea o apri l'archivio fonti attendibili globale. Se si crea un archivio fonti attendibili globale, memorizzare la password in un luogo sicuro.

  5. Espandi Aggiungi certificato da file CER.

  6. Seleziona Seleziona file di certificato, e carica il file del certificato fornito dall'IDP.

  7. Esci Mappa certificato a utente vuoto.

  8. Seleziona Invia.

  9. Il nuovo certificato aggiunto viene visualizzato sopra il Aggiungi certificato da file CRT sezione.

  10. Prendi nota di alias, in quanto questo valore viene utilizzato nel Configurazione OSGi del gestore autenticazione SAML 2.0.

  11. Seleziona Salva e chiudi.

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

Replica larchivio fonti attendibili globale in pubblicazione AEM

  1. Accedi a Strumenti > Implementazione > Pacchetti.

  2. Creare un pacchetto

    • Nome pacchetto: Global Trust Store
    • Versione: 1.0.0
    • Gruppo: com.your.company
  3. Modifica il nuovo Archivio attendibile globale pacchetto.

  4. Seleziona la Filtri e aggiungere un filtro per il percorso principale /etc/truststore.

  5. Seleziona Fine e poi Salva.

  6. Seleziona la Genera pulsante per Archivio attendibile globale pacchetto.

  7. Una volta creata, seleziona Altro > Replica per attivare il nodo Archivio fonti attendibili globale (/etc/truststore) alla pubblicazione AEM.

Crea keystore del servizio di autenticazione authentication-service-keystore

La creazione di un keystore per il servizio di autenticazione è necessaria quando Proprietà di configurazione OSGi del gestore autenticazione SAML 2.0 handleLogout è impostato su true o quando Firma AuthnRequest/Crittografia asserzione SAML è obbligatorio

  1. Accedi a AEM Author come amministratore AEM per caricare la chiave privata.

  2. Accedi a Strumenti > Sicurezza > Utenti, e seleziona authentication-service e seleziona Proprietà dalla barra delle azioni superiore.

  3. Seleziona la Registro chiavi scheda.

  4. Crea o apri il keystore. Se crei un keystore, proteggi la password.

    • A 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.
  5. Seleziona Salva e chiudi.

  6. Crea un pacchetto contenente il file aggiornato authentication-service utente.

    Utilizza la seguente soluzione alternativa temporanea utilizzando i pacchetti:

    1. Accedi a Strumenti > Implementazione > Pacchetti.

    2. Creare un pacchetto

      • Nome pacchetto: Authentication Service
      • Versione: 1.0.0
      • Gruppo: com.your.company
    3. Modifica il nuovo Archivio chiavi del servizio di autenticazione pacchetto.

    4. Seleziona la Filtri e aggiungere un filtro per il percorso principale /home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore.

      • Il <AUTHENTICATION SERVICE UUID> possono essere trovati passando a Strumenti > Sicurezza > Utenti, e selezione authentication-service utente. L’UUID è l’ultima parte dell’URL.
    5. Seleziona Fine e poi Salva.

    6. Seleziona la Genera pulsante per Archivio chiavi del servizio di autenticazione pacchetto.

    7. Una volta creata, seleziona Altro > Replica per attivare l’archivio chiavi del servizio di autenticazione in Pubblicazione AEM.

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

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

La funzione Pubblicazione AEM può essere configurata per firmare le richieste di authoring (a IDP) e crittografare le asserzioni SAML (a AEM). Ciò si ottiene fornendo una chiave privata all'AEM Publish, che corrisponde alla chiave pubblica dell'IDP.

Comprendere il flusso di firma AuthnRequest (facoltativo)

AuthnRequest (la richiesta all'IDP da AEM Publish che avvia il processo di accesso) può essere firmata da AEM Publish. A questo scopo, la funzione Pubblica dell’AEM firma la AuthnRequest utilizzando la chiave privata, ossia che l’IDP convalida la firma utilizzando la chiave pubblica. Questo garantisce all'IDP che AuthnRequest è stato avviato e richiesto da AEM Publish, e non a terzi malintenzionati.

SAML 2.0 - Firma SP AuthnRequest

  1. L’utente invia una richiesta HTTP a AEM Publish che restituisce una richiesta di autenticazione SAML all’IDP.
  2. La pubblicazione AEM genera la richiesta SAML da inviare all’IDP.
  3. Pubblicazione AEM firma la richiesta SAML utilizzando la chiave privata AEM.
  4. Con Pubblicazione AEM viene avviata AuthnRequest, un reindirizzamento lato client HTTP all'IDP contenente la richiesta SAML firmata.
  5. IDP riceve la AuthnRequest e convalida la firma utilizzando la chiave pubblica dell'AEM, garantendo che la funzione Publish dell'AEM abbia avviato la AuthnRequest.
  6. La pubblicazione AEM convalida quindi l'integrità e l'autenticità dell'asserzione SAML decrittografata utilizzando il certificato pubblico IDP.
Comprendere il flusso di crittografia dell’asserzione SAML (facoltativo)

Tutte le comunicazioni HTTP tra IDP e pubblicazione AEM 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 l’asserzione SAML viene decrittografata dalla pubblicazione AEM utilizzando la chiave privata.

SAML 2.0 - Crittografia dellasserzione SAML SP

  1. L'utente si autentica in IDP.
  2. IDP genera un'asserzione SAML contenente i dati dell'utente e la firma utilizzando il certificato privato dell'IDP.
  3. L'IDP crittografa quindi l'asserzione SAML con la chiave pubblica AEM, che richiede la chiave privata AEM per decrittografare.
  4. L’asserzione SAML crittografata viene inviata tramite il browser web dell’utente a AEM Publish.
  5. La pubblicazione AEM riceve l’asserzione SAML e la decrittografa utilizzando la chiave privata AEM.
  6. IDP richiede all'utente di eseguire l'autenticazione.

La firma AuthnRequest e la crittografia delle asserzioni SAML sono facoltative, ma entrambe sono abilitate, utilizzando Proprietà di configurazione OSGi del gestore autenticazione SAML 2.0 useEncryption, il che significa che è possibile utilizzare entrambi o nessuno dei due.

Archivio chiavi del servizio di autenticazione AEM

  1. 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
    
  2. Carica la chiave pubblica nell'IDP.

    • Utilizzo di openssl precedente, la chiave pubblica è il aem-public.crt file.
  3. Accedi a AEM Author come amministratore AEM per caricare la chiave privata.

  4. Accedi a Strumenti > Protezione > Archivio fonti attendibili, e seleziona authentication-service e seleziona Proprietà dalla barra delle azioni superiore.

  5. Accedi a Strumenti > Sicurezza > Utenti, e seleziona authentication-service e seleziona Proprietà dalla barra delle azioni superiore.

  6. Seleziona la Registro chiavi scheda.

  7. Crea o apri il keystore. Se crei un keystore, proteggi la password.

  8. Seleziona Aggiungi chiave privata da file DER, e aggiungere la chiave privata e il file della catena all’AEM:

    • Alias: specifica un nome significativo, spesso il nome dell’IDP.
    • File di chiave privata: carica il file della chiave privata (PKCS#8 in formato DER).
      • Utilizzo di openssl metodo precedente, questo è il aem-private-pkcs8.der file
    • Seleziona file catena di certificati: carica il file della catena allegato (potrebbe essere la chiave pubblica).
      • Utilizzo di openssl metodo precedente, questo è il aem-public.crt file
    • Seleziona Invia
  9. Il nuovo certificato aggiunto viene visualizzato sopra il Aggiungi certificato da file CRT sezione.

  10. Seleziona Salva e chiudi.

  11. Crea un pacchetto contenente il file aggiornato authentication-service utente.

    Utilizza la seguente soluzione alternativa temporanea utilizzando i pacchetti:

    1. Accedi a Strumenti > Implementazione > Pacchetti.

    2. Creare un pacchetto

      • Nome pacchetto: Authentication Service
      • Versione: 1.0.0
      • Gruppo: com.your.company
    3. Modifica il nuovo Archivio chiavi del servizio di autenticazione pacchetto.

    4. Seleziona la Filtri e aggiungere un filtro per il percorso principale /home/users/system/cq:services/internal/security/<AUTHENTICATION SERVICE UUID>/keystore.

      • Il <AUTHENTICATION SERVICE UUID> possono essere trovati passando a Strumenti > Sicurezza > Utenti, e selezione authentication-service utente. L’UUID è l’ultima parte dell’URL.
    5. Seleziona Fine e poi Salva.

    6. Seleziona la Genera pulsante per Archivio chiavi del servizio di autenticazione pacchetto.

    7. Una volta creata, seleziona Altro > Replica per attivare l’archivio chiavi del servizio di autenticazione in Pubblicazione AEM.

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

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

Glossario della configurazione OSGi del gestore autenticazione SAML 2.0

Configurazione OSGi del gestore autenticazione SAML 2.0 Adobe Granite 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 cui 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 globale AEM
Reindirizzamento HTTP IDP idpHttpRedirect Booleano false Indica se si tratta di un reindirizzamento HTTP all’URL IDP anziché inviare una AuthnRequest. Imposta su true per l’autenticazione avviata da IDP.
Identificatore IDP idpIdentifier Stringa ID IDP univoco per garantire l’univocità dell’utente e del gruppo AEM. Se vuoto, serviceProviderEntityId viene utilizzato al suo posto.
URL servizio consumer di asserzione assertionConsumerServiceURL Stringa Il AssertionConsumerServiceURL Attributo URL in AuthnRequest che specifica dove <Response> Il messaggio deve essere inviato all’AEM.
ID entità SP serviceProviderEntityId Stringa Identifica in modo univoco l'AEM per l'IDP; di solito il nome dell'host dell'AEM.
Crittografia SP useEncryption Booleano true Indica se l’IDP crittografa le asserzioni SAML. Richiede spPrivateKeyAlias e keyStorePassword da impostare.
Alias chiave privata SP spPrivateKeyAlias Stringa Alias della chiave privata in authentication-service archivio chiavi dell’utente. 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 dell’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 AEM vengono creati dopo la corretta autenticazione.
Percorso intermedio per utenti AEM userIntermediatePath Stringa Quando si creano utenti AEM, questo valore viene utilizzato come percorso intermedio (ad esempio, /home/users/<userIntermediatePath>/jane@wknd.com). Richiede createUser da impostare su true.
Attributi utente AEM synchronizeAttributes Array di stringhe Elenco delle mappature di attributi SAML da memorizzare sull’utente AEM, nel formato [ "saml-attribute-name=path/relative/to/user/node" ] (ad esempio, [ "firstName=profile/givenName" ]). Consulta la elenco completo degli attributi AEM nativi.
Aggiungere un utente ai gruppi AEM addGroupMemberships Booleano true Indica se un utente AEM viene aggiunto automaticamente ai gruppi di utenti 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 da impostare su true.
Gruppi AEM predefiniti defaultGroups Array di stringhe Un elenco di gruppi di utenti AEM a cui vengono sempre aggiunti utenti autenticati (ad esempio, [ "wknd-user" ]). Richiede addGroupMemberships da impostare 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 samlResponse viene memorizzato nell’AEM cq:User nodo.
Gestisci disconnessione handleLogout Booleano false Indica se la richiesta di disconnessione è gestita da questo gestore di autenticazione SAML. Richiede logoutUrl da impostare.
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 Intero 60 Tolleranza di sfasamento dell’orologio di 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 from predefinito per AEM as a Cloud Service.
Classificazione del servizio service.ranking Intero 5002 Configurazioni di classificazione più elevate sono preferite per lo stesso path.

Attributi utente AEM aem-user-attributes

L'AEM utilizza i seguenti attributi utente, che possono essere compilati tramite synchronizeAttributes proprietà nella configurazione OSGi del gestore autenticazione SAML 2.0 Adobe Granite. Qualsiasi attributo IDP può essere sincronizzato con qualsiasi proprietà utente AEM, tuttavia la mappatura a AEM use attribute properties (elencato di seguito) consente al AEM di utilizzarlo 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 da rep:User nodo
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
  1. Crea un file di configurazione OSGi nel progetto all’indirizzo /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json e aprire nell’IDE.

    • Cambia /wknd-examples/ al tuo /<project name>/
    • L’identificatore dopo il ~ 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.
  2. Incolla il seguente JSON in com.adobe.granite.auth.saml.SamlAuthenticationHandler~...cfg.json e aggiorna wknd riferimenti 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"
        ]
    }
    
  3. Aggiorna i valori come richiesto dal progetto. Consulta la Glossario della configurazione OSGi del gestore autenticazione SAML 2.0 sopra per le descrizioni delle proprietà di configurazione

  4. È 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 utilizzando $[env:..;default=the-default-value]" come mostrato sopra.

Configurazioni OSGi per ambiente (config.publish.dev, config.publish.stage, e config.publish.prod) può essere definito con attributi specifici se la configurazione SAML varia tra gli ambienti.

Usa crittografia

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

Facoltativamente, aggiorna la configurazione OSGi per utilizzare la crittografia
  1. Apri /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~saml.cfg.json nell’IDE.

  2. Aggiungi le tre proprietà useEncryption, spPrivateKeyAlias, e keyStorePassword come mostrato 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"
    ]
    }
    
  3. Le tre proprietà di configurazione OSGi necessarie per la crittografia sono:

  • useEncryption imposta su true
  • spPrivateKeyAlias contiene l’alias della voce keystore per la chiave privata utilizzata dall’integrazione SAML.
  • keyStorePassword contiene un Variabile di configurazione segreta OSGi contenente authentication-service password dell'utente keystore.

Configura filtro Referrer

Durante il processo di autenticazione SAML, l’IDP avvia un POST HTTP lato client per la pubblicazione AEM .../saml_login punto finale. Se l'IDP e la pubblicazione AEM hanno origini diverse, la pubblicazione AEM Filtro referrer è configurato tramite la configurazione OSGi per consentire i POST HTTP dall’origine dell’IDP.

  1. Creare (o modificare) un file di configurazione OSGi nel progetto all’indirizzo /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/org.apache.sling.security.impl.ReferrerFilter.cfg.json.

    • Cambia /wknd-examples/ al tuo /<project name>/
  2. Assicurati che allow.empty valore impostato su true, il allow.hosts (o se preferisci, allow.hosts.regexp) contiene l'origine dell'IDP, e filter.methods include POST. 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": [ ]
    }
    

La pubblicazione AEM supporta una singola configurazione del filtro Referrer, in modo da unire i requisiti di configurazione SAML con eventuali configurazioni esistenti.

Configurazioni OSGi per ambiente (config.publish.dev, config.publish.stage, e config.publish.prod) può essere definito con attributi specifici se allow.hosts (o allow.hosts.regex) variano da ambiente a ambiente.

Configurare la condivisione CORS (Cross-Origin Resource Sharing)

Durante il processo di autenticazione SAML, l’IDP avvia un POST HTTP lato client per la pubblicazione AEM .../saml_login punto finale. Se l’IDP e la pubblicazione AEM esistono su host/domini diversi, la pubblicazione AEM Condivisione risorse CRoss-Origin (CORS) deve essere configurato per consentire i POST HTTP dall’host/dominio dell’IDP.

Di questa richiesta HTTP POST Origin L’intestazione di solito ha un valore diverso rispetto all’host di pubblicazione AEM, e richiede quindi la configurazione CORS.

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

  1. Crea un file di configurazione OSGi nel progetto all’indirizzo /ui.config/src/main/content/jcr_root/wknd-examples/osgiconfig/config.publish/com.adobe.granite.cors.impl.CORSPolicyImpl~saml.cfg.json

    • Cambia /wknd-examples/ al nome del progetto
    • L’identificatore dopo il ~ 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.
  2. Incolla il seguente JSON in com.adobe.granite.cors.impl.CORSPolicyImpl~...cfg.json file.

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

Configurazioni OSGi per ambiente (config.publish.dev, config.publish.stage, e config.publish.prod) può essere definito con attributi specifici se alloworigin e allowedpaths varia da un ambiente all’altro.

Configura il Dispatcher AEM per consentire i POST HTTP SAML

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

  1. Apri dispatcher/src/conf.dispatcher.d/filters/filters.any nell’IDE.
  2. Aggiungi nella parte inferiore del file una regola di autorizzazione 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 è configurata la riscrittura dell’URL nel server web Apache (dispatcher/src/conf.d/rewrites/rewrite.rules), assicurati che le richieste agli .../saml_login i punti finali non vengono manipolati accidentalmente.

Distribuzione della configurazione SAML

Le configurazioni OSGi devono essere salvate in Git e distribuite in AEM as a Cloud Service tramite 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 di 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 necessità, ad esempio un pulsante di accesso può impostare saml_request_path: è il punto in cui l’utente viene indirizzato, in seguito a una corretta autenticazione SAML, a diverse pagine AEM, 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:

Nome parametro query
Valore parametro query
resource
Qualsiasi percorso JCR, o percorso secondario, su cui il gestore di autenticazione SAML è in ascolto, come definito nella Adobe di configurazione OSGi del gestore autenticazione SAML 2.0 Granite path proprietà.
saml_request_path
Percorso URL a cui deve essere indirizzato l’utente dopo l’autenticazione SAML riuscita.

Ad esempio, questo collegamento HTML attiverà il flusso di accesso SAML e, in caso di esito positivo, condurrà 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:

Nome dati modulo
Valore dati modulo
resource
Qualsiasi percorso JCR, o percorso secondario, su cui il gestore di autenticazione SAML è in ascolto, come definito nella Adobe di configurazione OSGi del gestore autenticazione SAML 2.0 Granite path proprietà.
saml_request_path
Percorso URL a cui deve essere indirizzato l’utente dopo l’autenticazione SAML riuscita.

Questo pulsante HTML, ad esempio, utilizza un POST HTTP per attivare il flusso di accesso SAML e, in caso di esito positivo, porta 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 del Dispatcher

Entrambi i metodi HTTP GET e POST richiedono l'accesso client all'AEM /system/sling/login e quindi devono essere consentiti tramite Dispatcher per l’AEM.

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" }
recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69