Supporto token incapsulati encapsulated-token-support
Introduzione introduction
Per impostazione predefinita, AEM utilizza il gestore di autenticazione dei token per autenticare ogni richiesta. Tuttavia, per soddisfare le richieste di autenticazione, il gestore di autenticazione dei token richiede l’accesso all’archivio per ogni richiesta. Questo accade perché i cookie vengono utilizzati per mantenere lo stato di autenticazione. Logicamente, lo stato deve essere mantenuto nell’archivio per convalidare le richieste successive. In effetti, ciò significa che il meccanismo di autenticazione è stabile.
Questo è di particolare importanza per la scalabilità orizzontale. In una configurazione con più istanze come la farm di pubblicazione illustrata di seguito, il bilanciamento del carico non può essere ottenuto in modo ottimale. Con l’autenticazione con stato, lo stato di autenticazione persistente sarà disponibile solo nell’istanza in cui l’utente viene autenticato per la prima volta.
Prendi ad esempio il seguente scenario:
Un utente può essere autenticato nell'istanza di pubblicazione 1, ma se una richiesta successiva va all'istanza di pubblicazione 2, l'istanza non dispone di tale stato di autenticazione persistente, perché tale stato è stato mantenuto nell'archivio di pubblicazione uno e pubblicazione due ha un proprio archivio.
La soluzione è quella di configurare connessioni permanenti a livello di load balancer. Con le connessioni permanenti, un utente veniva sempre indirizzato alla stessa istanza di pubblicazione. Di conseguenza, non è possibile un bilanciamento del carico ottimale.
Nel caso in cui un'istanza di pubblicazione diventi non disponibile, tutti gli utenti autenticati in tale istanza perderanno la sessione. Questo perché l'accesso al repository è necessario per convalidare il cookie di autenticazione.
Autenticazione senza stato con token incapsulato stateless-authentication-with-the-encapsulated-token
La soluzione per la scalabilità orizzontale è l’autenticazione senza stato con l’utilizzo del nuovo supporto per i token incapsulati in AEM.
Il Token incapsulato è un elemento di crittografia che consente AEM creare e convalidare in modo sicuro le informazioni di autenticazione offline, senza accedere all’archivio. In questo modo, una richiesta di autenticazione può avvenire su tutte le istanze di pubblicazione e senza la necessità di connessioni permanenti. Inoltre, ha il vantaggio di migliorare le prestazioni di autenticazione, in quanto l’archivio non deve essere accessibile per ogni richiesta di autenticazione.
Puoi vedere come funziona in una distribuzione geograficamente distribuita con autori MongoMK e istanze di pubblicazione TarMK di seguito:
Configurazione del token incapsulato configuring-the-encapsulated-token
-
Le sessioni permanenti sono abilitate oppure
-
Gli utenti vengono già creati in AEM all'avvio della sincronizzazione. Ciò significa che i token incapsulati non saranno supportati in situazioni in cui i gestori creare utenti durante il processo di sincronizzazione.
Quando configuri il token incapsulato, è necessario tenere in considerazione alcuni aspetti:
- A causa della crittografia in questione, tutte le istanze devono avere la stessa chiave HMAC. A partire dal AEM 6.3, il materiale chiave non viene più memorizzato nell’archivio, ma nel file system effettivo. In questo modo, il modo migliore per replicare le chiavi è copiarle dal file system dell'istanza sorgente a quello delle istanze di destinazione a cui si desidera replicare le chiavi. Vedi altre informazioni sotto "Replica della chiave HMAC" qui sotto.
- Il token incapsulato deve essere abilitato. Questa operazione può essere eseguita tramite la Web Console.
Replica della chiave HMAC replicating-the-hmac-key
La chiave HMAC è presente come proprietà binaria di /etc/key nel repository. È possibile scaricarlo separatamente premendo il pulsante visualizzare link accanto ad esso:
Per replicare la chiave tra le istanze, è necessario:
-
Accedi all'istanza AEM, in genere un'istanza dell'autore, che contiene il materiale chiave da copiare;
-
Individua il
com.adobe.granite.crypto.filenel file system locale. Ad esempio, sotto questo percorso:- <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21
La
bundle.infoall'interno di ogni cartella identificherà il nome del bundle. -
Passa alla cartella dati. Ad esempio:
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Copiare i file HMAC e master.
-
Quindi, vai all'istanza di destinazione a cui desideri duplicare la chiave HMAC e passa alla cartella dei dati. Ad esempio:
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Incolla i due file copiati in precedenza.
-
Aggiorna il bundle Crypto se l’istanza target è già in esecuzione.
-
Ripeti i passaggi precedenti per tutte le istanze a cui desideri replicare la chiave.
Abilitazione del token incapsulato enabling-the-encapsulated-token
Una volta replicata la chiave HMAC, puoi abilitare il Token incapsulato tramite la console Web:
- Posiziona il browser su
https://serveraddress:port/system/console/configMgr - Cerca una voce chiamata Day CRX Token Authentication Handler e fai clic su di esso.
- Nella finestra seguente, spunta la Abilita supporto token incapsulati e premere Salva.