Show Menu
ARGOMENTI×

Supporto token incapsulati

Introduzione

Per impostazione predefinita, AEM usa il gestore autenticazione token per autenticare ogni richiesta. Tuttavia, per soddisfare le richieste di autenticazione, il Gestore autenticazione token richiede l'accesso all'archivio per ogni richiesta. Ciò accade perché i cookie vengono utilizzati per mantenere lo stato di autenticazione. Logicamente, lo stato deve essere mantenuto nella directory archivio per convalidare le richieste successive. In effetti, ciò significa che il meccanismo di autenticazione è statico.
Ciò è di particolare importanza per la scalabilità orizzontale. In una configurazione a più istanze come la farm di pubblicazione descritta di seguito, il bilanciamento del carico non può essere raggiunto in modo ottimale. Con l'autenticazione di stato, lo stato di autenticazione persistente sarà disponibile solo nell'istanza in cui l'utente viene autenticato per la prima volta.
Prendete 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, tale istanza non dispone di tale stato di autenticazione persistente, perché tale stato era persistente nell’archivio di pubblicazione 1 e pubblicazione 2 ha un proprio repository.
La soluzione è configurare connessioni fissi a livello di bilanciamento del carico. Con le connessioni fisse, un utente viene sempre indirizzato alla stessa istanza di pubblicazione. Di conseguenza, non è possibile ottenere un bilanciamento del carico ottimale.
Se un’istanza di pubblicazione non è più disponibile, tutti gli utenti autenticati in tale istanza perderanno la sessione. Questo perché l'accesso del repository è necessario per convalidare il cookie di autenticazione.

Autenticazione senza stato con il token incapsulato

La soluzione per la scalabilità orizzontale è l'autenticazione senza stato con l'utilizzo del nuovo supporto per token incapsulati in AEM.
Il Token incapsulato è un elemento di crittografia che consente ad AEM di creare e convalidare in modo sicuro le informazioni di autenticazione offline, senza accedere all'archivio. In questo modo, una richiesta di autenticazione può essere eseguita su tutte le istanze di pubblicazione e senza la necessità di connessioni permanenti. Offre inoltre il vantaggio di migliorare le prestazioni di autenticazione, poiché l'archivio non deve essere accessibile per ogni richiesta di autenticazione.
Potete vedere come funziona in una distribuzione geograficamente distribuita con autori MongoMK e istanze di pubblicazione TarMK di seguito:
Il token incapsulato riguarda l'autenticazione. Garantisce che il cookie possa essere convalidato senza dover accedere alla directory archivio. Tuttavia, è comunque necessario che l'utente esista su tutte le istanze e che le informazioni memorizzate in tale utente siano accessibili a ogni istanza.
Ad esempio, se un nuovo utente viene creato nell’istanza di pubblicazione numero uno, a causa del funzionamento del Token incapsulato, verrà autenticato correttamente al momento della pubblicazione numero due. Se l’utente non esiste nella seconda istanza di pubblicazione, la richiesta non avrà esito positivo.

Configurazione del token incapsulato

Per configurare il token incapsulato è necessario tenere in considerazione alcuni aspetti:
  1. A causa della crittografia, tutte le istanze devono avere la stessa chiave HMAC. A partire da AEM 6.3, il materiale chiave non è più memorizzato nella directory archivio, ma nel file system effettivo. In questo modo, il modo migliore per replicare le chiavi è copiarle dal file system dell'istanza di origine a quello delle istanze di destinazione a cui si desidera replicare le chiavi. Per ulteriori informazioni, vedere la sezione "Replica del tasto HMAC" di seguito.
  2. Il token incapsulato deve essere abilitato. Questo può essere fatto tramite la console Web.

Replica del tasto HMAC

La chiave HMAC è presente come proprietà binaria di /etc/key nella directory archivio. Potete scaricarlo separatamente premendo il collegamento di visualizzazione accanto:
Per replicare la chiave tra le istanze, è necessario:
  1. Accedete all’istanza di AEM, in genere un’istanza di creazione, che contiene il materiale chiave da copiare;
  2. Individuare il com.adobe.granite.crypto.file bundle nel file system locale. Ad esempio, in questo percorso:
    • <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21
    Il bundle.info file all’interno di ciascuna cartella identificherà il nome del bundle.
  3. Passa alla cartella dei dati. Ad esempio:
    • <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
  4. Copiate i file HMAC e master.
  5. Quindi, passate all'istanza di destinazione alla quale desiderate duplicare la chiave HMAC e individuate la cartella di dati. Ad esempio:
    • <publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
  6. Incollate i due file precedentemente copiati.
  7. Aggiornate Crypto Bundle se l'istanza di destinazione è già in esecuzione.
  8. Ripetere i passaggi indicati sopra per tutte le istanze in cui si desidera replicare la chiave.

Abilitazione del token incapsulato

Una volta replicata la chiave HMAC, potete abilitare il token incapsulato tramite la console Web:
  1. Posiziona il browser su https://serveraddress:port/system/console/configMgr
  2. Cercate una voce denominata Gestore autenticazione token CRX Day e fate clic su di essa.
  3. Nella finestra seguente, selezionate la casella Abilita supporto token incapsulato e premete Salva .