Sie sehen sich Hilfeinhalte der folgenden Version an:

Einführung

Standardmäßig verwendet AEM den Token Authentication Handler, um jede Abfrage zu authentifizieren. Um Authentifizierungsabfragen verarbeiten zu können, benötigt der Token Authentication Handler jedoch bei jeder Abfrage Zugriff auf das Repository. Das liegt daran, dass Cookies zur Beibehaltung des Authentifizierungsstatus verwendet werden. Logischerweise muss der Status im Repository beibehalten werden, um nachfolgende Abfragen zu validieren. Daher ist der Authentifizierungsmechanismus „stateful“.

Dies ist für die horizontale Skalierbarkeit besonders wichtig. Bei einer Bereitstellung mit mehreren Instanzen, wie bei der unten abgebildeten Veröffentlichen-Farm, kann der Lastenausgleich nicht optimal erfolgen. Bei der „stateful“-Authentifizierung ist der beibehaltene Authentifizierungsstatus nur auf der Instanz verfügbar, auf der der Benutzer zuerst authentifiziert wird.

chlimage_1

Nehmen wir das folgende Szenario als Beispiel:

Ein Benutzer wird auf der Veröffentlichungsinstanz 1 authentifiziert. Wenn eine nachfolgende Abfrage an die Veröffentlichungsinstanz 2 erfolgt, ist auf dieser Instanz der beibehaltene Authentifizierungsstatus nicht verfügbar, weil der Status im Repository von Veröffentlichen 1 beibehalten wurde und Veröffentlichen 2 ein eigenes Repository hat.

Die Lösung besteht darin, dauerhafte Verbindungen auf der Ebene des Load-Balancers zu konfigurieren. Mit solchen dauerhaften Verbindungen wird ein Benutzer immer zur selben Veröffentlichungsinstanz geleitet. Dadurch ist ein wirklich optimaler Lastenausgleich nicht möglich.

Wenn eine Veröffentlichungsinstanz nicht mehr verfügbar ist, gehen die Sitzungen aller auf dieser Instanz authentifizierten Benutzer verloren. Dies liegt daran, dass der Zugriff auf das Repository zur Validierung des Authentifizierungs-Cookies erforderlich ist.

„Stateless“-Authentifizierung mit dem Encapsulated Token

Die Lösung für die horizontale Skalierbarkeit besteht in der „Stateless“-Authentifizierung, bei der die neue Unterstützung von Encapsulated Tokens in AEM genutzt wird.

Das Encapsulated Token ist ein kryptografisches Element, das die sichere Erstellung und Validierung von Authentifizierungsdaten offline ermöglicht, ohne dass ein Zugriff auf das Repository nötig ist. So kann eine Authentifizierungsabfrage auf allen Veröffentlichungsinstanzen ohne dauerhafte Verbindung erfolgen. Außerdem bietet dieser Ansatz den Vorteil, dass die Authentifizierungsleistung verbessert wird, da nicht bei jeder Authentifizierungsabfrage ein Zugriff auf das Repository vonnöten ist.

Wie dies in einer geografisch verteilten Bereitstellung mit MongoMK-Autoren und TarMK-Veröffentlichungsinstanzen funktioniert, sehen Sie in der folgenden Grafik:

chlimage_1

Hinweis:

Beachten Sie, dass das Encapsulated Token zur Authentifizierung dient. Es stellt sicher, dass das Cookie validiert werden kann, ohne dass ein Zugriff auf das Repository nötig ist. Dennoch ist es erforderlich, dass der Benutzer auf allen Instanzen vorhanden ist und die unter diesem Benutzer gespeicherten Daten für jede Instanz zugänglich sind.

Wenn beispielsweise ein neuer Benutzer auf der Veröffentlichungsinstanz 1 erstellt wird, wird er mit dem Encapsulated Token auf der Veröffentlichen-Instanz 2 erfolgreich authentifiziert. Wenn der Benutzer auf der zweiten Veröffentlichungsinstanz nicht vorhanden ist, ist die Abfrage dennoch nicht erfolgreich.

Konfigurieren des Encapsulated Tokens

Bei der Konfiguration des Encapsulated Tokens müssen Sie einige Aspekte berücksichtigen:

  1. Wegen der Verschlüsselung müssen alle Instanzen denselben HMAC-Schlüssel aufweisen. Seit AEM 6.3 werden die Schlüsseldaten nicht mehr im Repository, sondern im Dateisystem selbst gespeichert. Daher besteht die beste Möglichkeit zum Replizieren der Schlüssel darin, sie vom Dateisystem der Quellinstanz zum Dateisystem der Zielinstanz(en) zu kopieren, auf die Sie die Schlüssel replizieren möchten. Weitere Informationen dazu finden Sie unter „Replizieren des HMAC-Schlüssels“.
  2. Das Encapsulated Token muss aktiviert werden. Dies ist über die Web-Konsole möglich.

Replizieren des HMAC-Schlüssels

Der HMAC-Schlüssel liegt als binäre Eigenschaft von /etc/key im Repository vor. Sie können ihn separat herunterladen. Klicken Sie dazu auf den Link Anzeigen neben der Eigenschaft:

chlimage_1

Um den Schlüssel auf weitere Instanzen zu replizieren, führen Sie die folgenden Schritte durch:

  1. Greifen Sie auf die AEM-Instanz zu, auf der sich die zu kopierenden Schlüsseldaten befinden. In der Regel handelt es sich dabei um eine Autoreninstanz.

  2. Suchen Sie im lokalen Dateisystem das Bundle com.adobe.granite.crypto.file. Es kann sich z. B. unter diesem Pfad befinden:

    • <Autor-AEM-Installationsverzeichnis>/crx-quickstart/launchpad/felix/bundle21

    Die Datei bundle.info in jedem Ordner identifiziert den Bundle-Namen.

  3. Navigieren Sie zum Ordner „data“. Beispiel:

    • <Autor-AEM-Installationsverzeichnis>/crx-quickstart/launchpad/felix/bundle21/data
  4. Kopieren Sie die HMAC- und die Master-Dateien.

  5. Navigieren Sie dann zur Zielinstanz, auf der Sie den HMAC-Schlüssel duplizieren möchten, und dann zum Ordner „data“. Beispiel:

    • <Veröffentlichung-AEM-Installationsverzeichnis>/crx-quickstart/launchpad/felix/bundle21/data
  6. Fügen Sie die beiden zuvor kopierten Dateien ein.

  7. Aktualisieren Sie das Crypto-Bundle, wenn die Zielinstanz bereits ausgeführt wird.

  8. Wiederholen Sie die vorherigen Schritte für alle Instanzen, auf denen Sie den Schlüssel replizieren möchten.

Aktivieren des Encapsulated Tokens

Wenn Sie den HMAC-Schlüssel repliziert haben, können Sie das Encapsulated Token über die Web-Konsole aktivieren:

  1. Rufen Sie im Browser die URL http://serveraddress:port/system/console/configMgr auf.

  2. Suchen Sie den Eintrag Day CRX Token Authentication Handler und klicken Sie darauf.

  3. Aktivieren Sie im daraufhin angezeigten Fenster das Kontrollkästchen Unterstützung von Encapsulated Tokens aktivieren. Klicken Sie dann auf Speichern.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie