依預設,AEM會使用Token驗證處理常式來驗證每個請求。 但是,為了提供驗證請求,Token驗證處理常式要求存取每個請求的儲存庫。 這是因為Cookie用於維護驗證狀態。 從邏輯上講,狀態需要保存在儲存庫中,以驗證後續請求。 實際上,這意味著身份驗證機制是有狀態的。
這對於橫向延展性尤其重要。 在如下所示的發佈群等多執行個體設定中,無法以最佳方式達成負載平衡。 使用狀態驗證時,持續驗證狀態僅適用於第一次驗證使用者的例項。
以下列案例為例:
用戶可以在發佈實例1上獲得驗證,但如果後續請求發佈實例2,則該實例沒有持續的驗證狀態,因為該狀態保存在發佈實例1的儲存庫中,而發佈實例2有自己的儲存庫。
解決方案是在負載平衡器層級配置嚴格連線。 使用嚴格連線時,使用者一律會被導向至相同的發佈例項。 因此,無法實現真正最佳的負載平衡。
如果發佈例項無法使用,在該例項上驗證的所有使用者都將遺失其工作階段。 這是因為驗證Cookie需要存取儲存庫。
橫向調整能力的解決方案是使用AEM中新的封裝Token支援進行無狀態驗證。
Encapsulated Token是一種加密技術,可讓AEM安全地離線建立和驗證驗證資訊,而不需存取儲存庫。 如此,所有發佈例項都可能會發生驗證要求,而不需要嚴格連線。 它還具有提高驗證效能的優勢,因為無需對每個驗證請求訪問儲存庫。
您可在以下MongoMK作者和TarMK發佈例項的地理分佈部署中,瞭解其運作方式:
請注意,封裝的Token與驗證有關。 它可確保Cookie可以驗證,而不需存取儲存庫。 但是,用戶仍然需要存在於所有實例中,並且每個實例都可以訪問儲存在該用戶下的資訊。
例如,如果在發佈實例1上建立了新用戶,由於封裝Token的工作方式,它將在發佈實例2上成功驗證。 如果使用者不存在於第二個發佈例項,請求仍無法成功。
所有同步使用者並依賴Token驗證(例如SAML和OAuth)的驗證處理常式,只有在下列情況下才能與封裝的Token搭配運作:
會啟用自黏作業,或
同步啟動時,使用者已在AEM中建立。 這表示在同步過程中處理常式create使用者的情況下,將不支援封裝的Token。
在設定封裝Token時,您需要考慮以下幾項:
HMAC密鑰以/etc/key
的二進位屬性形式顯示在儲存庫中。 您可以按下其旁邊的view連結,分別下載它:
為了跨實例複製密鑰,您需要:
存取AEM例項(通常為作者例項),其中包含要複製的關鍵材料;
在本地檔案系統中找到com.adobe.granite.crypto.file
包。 例如,在此路徑下:
每個資料夾內的bundle.info
檔案將標識包名稱。
導覽至資料夾。 例如:
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
複製HMAC和主檔案。
然後,前往您要複製HMAC金鑰的目標執行個體,並導覽至資料夾。 例如:
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
貼上您先前複製的兩個檔案。
如果目標實 例已在運行,請刷新Crypto Bundle。
對要將密鑰複製到的所有實例重複上述步驟。
複製HMAC金鑰後,您就可以透過Web主控台啟用封裝的Token:
https://serveraddress:port/system/console/configMgr