Ondersteuning voor ingekapselde token encapsulated-token-support
Inleiding introduction
Door gebrek, gebruikt AEM de Symbolische Handler van de Authentificatie om elk verzoek voor authentiek te verklaren. Om verificatieverzoeken te kunnen uitvoeren, vereist de Token Authentication Handler echter toegang tot de opslagplaats voor elk verzoek. Dit gebeurt omdat de koekjes worden gebruikt om de authentificatiestatus te handhaven. Logischerwijze moet de status in de opslagplaats worden voortgezet om volgende aanvragen te valideren. In feite, betekent dit dat het authentificatiemechanisme stateful is.
Dit is van bijzonder belang voor horizontale schaalbaarheid. In een opstelling van meerdere instanties zoals het hieronder afgebeeld publicatielandbouwbedrijf, kan lading het in evenwicht brengen niet op een optimale manier worden bereikt. Met stateful authentificatie, zal de persisted authentificatiestatus slechts op de instantie beschikbaar zijn waar de gebruiker eerst voor authentiek wordt verklaard.
Neem het volgende scenario als voorbeeld:
Een gebruiker kan bij publicatieinstantie één voor authentiek worden verklaard, maar als een verder verzoek instantie twee gaat publiceren, heeft die instantie niet die persisted authentificatiestatus, omdat die staat in de bewaarplaats van publiceert werd voortgeduurd en twee zijn eigen bewaarplaats publiceert.
De oplossing voor dit is kleverige verbindingen op het niveau van het taakverdelingsmechanisme te vormen. Met kleverige verbindingen zou een gebruiker altijd naar hetzelfde publicatie-exemplaar worden geleid. Als gevolg hiervan is een werkelijk optimale taakverdeling niet mogelijk.
Als een publicatie-instantie niet beschikbaar wordt, verliezen alle gebruikers die voor die instantie zijn geverifieerd hun sessie. Dit komt omdat toegang tot de opslagplaats nodig is om het verificatiecookie te valideren.
Stateless Authentificatie met Encapsulated Token stateless-authentication-with-the-encapsulated-token
De oplossing voor horizontale scalability is stateless authentificatie met het gebruik van de nieuwe Encapsulated Token steun in AEM.
Het ingekapselde token is een stuk cryptografie waarmee AEM op veilige wijze verificatiegegevens offline kunt maken en valideren, zonder toegang tot de opslagplaats. Op deze manier kan een verificatieverzoek worden uitgevoerd op alle publicatieexemplaren zonder dat er kleverige verbindingen nodig zijn. Het heeft ook het voordeel om authentificatieprestaties te verbeteren aangezien de bewaarplaats niet voor elk authentificatieverzoek te hoeven worden betreden.
U kunt zien hoe dit werkt in een geografisch gedistribueerde implementatie met MongoMK-auteurs en TarMK-publicatie-instanties hieronder:
Het vormen van Encapsulated Token configuring-the-encapsulated-token
-
Vaste sessies zijn ingeschakeld, of
-
Gebruikers worden al in AEM gemaakt wanneer de synchronisatie start. Dit betekent dat ingekapselde tokens niet in situaties zullen worden gesteund waar de managers maken gebruikers tijdens het synchronisatieproces.
Er zijn een paar dingen u in overweging moet nemen wanneer het vormen van Encapsulated Token:
- Wegens de cryptografie in kwestie, moeten alle instanties de zelfde sleutel HMAC hebben. Sinds AEM 6.3 wordt het sleutelmateriaal niet langer opgeslagen in de gegevensopslagruimte, maar in het eigenlijke bestandssysteem. In dit verband is het de beste manier om de toetsen te repliceren om deze van het bestandssysteem van de broninstantie naar die van de doelinstantie(s) te kopiëren waarnaar u de toetsen wilt repliceren. Zie hieronder meer informatie onder "Replicating the HMAC key".
- Het ingekapselde token moet worden ingeschakeld. Dit kan door de Console van het Web worden gedaan.
Replicatie van de HMAC-sleutel replicating-the-hmac-key
De sleutel HMAC is aanwezig als binair bezit van /etc/key in de repository. U kunt het afzonderlijk downloaden door op de knop weergave koppeling ernaast:
Als u de sleutel in meerdere instanties wilt repliceren, moet u:
-
Toegang krijgen tot de AEM instantie, doorgaans een instantie van de auteur, die het te kopiëren toetsmateriaal bevat.
-
Zoek de
com.adobe.granite.crypto.filein het lokale bestandssysteem. Onder dit pad bijvoorbeeld:- <author-aem-install-dir>/crx-quickstart/launch/felix/bundle21
De
bundle.infoin elke map wordt de bundelnaam weergegeven. -
Navigeer naar de gegevensmap. Bijvoorbeeld:
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Kopieer de HMAC- en master bestanden.
-
Dan, ga naar de doelinstantie u de sleutel HMAC aan wilt dupliceren, en aan de gegevensomslag navigeren. Bijvoorbeeld:
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Plak de twee bestanden die u eerder hebt gekopieerd.
-
De Cryptobundel vernieuwen als de doelinstantie al actief is.
-
Herhaal de bovenstaande stappen voor alle gevallen waarin u de toets wilt repliceren.
Encapsulated Token toelaten enabling-the-encapsulated-token
Zodra de sleutel HMAC is herhaald, kunt u Encapsulated Token via de Console van het Web toelaten:
- Wijs uw browser aan
https://serveraddress:port/system/console/configMgr - Zoek een vermelding die Day CRX Token Authentication Handler en klik erop.
- Tik in het volgende venster op de knop Ondersteuning voor ingekapselde token inschakelen doos en druk op Opslaan.