Web-Programme bieten häufig Funktionen zur Kontoverwaltung, mit denen sich Endanwender auf einer Website registrieren können. Dadurch werden ihre Anwenderdaten beibehalten, sodass sie sich auch künftig anmelden und von einem einheitlichen Anwendererlebnis profitieren können. In diesem Artikel werden die folgenden Konzepte für AEM as a Cloud Service beschrieben:
Damit die in diesem Artikel beschriebene Funktion ordnungsgemäß genutzt werden kann, muss die Funktion zur Synchronisierung von Anwenderdaten aktiviert sein. Dazu ist derzeit Anfrage beim Kunden-Support erforderlich, in der das betreffende Programm und die entsprechenden Umgebung angegeben werden. Wenn diese Option nicht aktiviert ist, werden Anwenderinformationen nur für einen kurzen Zeitraum (1–24 Stunden) beibehalten.
Wenn sich ein Endanwender für ein Konto in einem AEM-Programm registriert, wird im Veröffentlichungs-Service von AEM ein Benutzerkonto erstellt, wie in einer Anwenderressource unter /home/users
im JCR-Repository dargestellt.
Zur Implementierung der Registrierung gibt es zwei Ansätze, wie nachfolgend beschrieben.
Benutzerdefinierter Registrierungs-Code kann geschrieben werden, der zumindest den Benutzernamen und das Kennwort des Benutzers verwendet und einen Benutzerdatensatz in AEM erstellt, der dann zur Authentifizierung bei der Anmeldung verwendet werden kann. Normalerweise werden die folgenden Schritte zum Aufbau dieses Registrierungsmechanismus verwendet:
findAuthorizables()
-Methoden der UserManager-API überprüfen, ob noch kein Anwender vorhanden istcreateUser()
-Methoden der UserManager-APIsetProperty()
-Methoden der Authorizable-Schnittstelle erfassten ProfildatenIn einigen Fällen erfolgte die Registrierung oder Anwendererstellung zuvor in einer Infrastruktur außerhalb von AEM. In diesem Szenario wird der Anwenderdatensatz bei der Anmeldung in AEM erstellt.
Sobald ein Endanwender beim Veröffentlichungs-Service von AEM registriert ist, kann sich dieser Anwender für den authentifizierten Zugriff anmelden (mithilfe von AEM-Autorisierungsmechanismen). Außerdem können dann anwenderspezifische Daten wie seine Profildaten beibehalten werden.
Die Anmeldung lässt sich mithilfe der beiden folgenden Methoden implementieren:
Kunden können eigene benutzerdefinierte Komponenten schreiben. Dazu empfehlen wir Ihnen, sich hier eingehender informieren:
Kunden können sich mit Identitätsanbieter zusammenarbeiten, der die Anwender authentifiziert. Zu den Integrationstechnologien zählen SAML und OAuth/SSO, wie nachfolgend beschrieben.
SAML-basiert
Kunden können über ihren bevorzugten SAML-Identitätsanbieter die SAML-basierte Authentifizierung nutzen. Bei Verwendung eines IdP mit AEM ist der IdP für die Authentifizierung der Benutzeranmeldeinformationen und die Vermittlung der Benutzerauthentifizierung mit AEM, die Erstellung des Benutzerdatensatzes in AEM nach Bedarf und die Verwaltung der Gruppenmitgliedschaft des Benutzers in AEM, wie in der SAML-Bestätigung beschrieben.
Nur die anfängliche Authentifizierung der Anmeldeinformationen der Anwender wird vom Identitätsanbieter authentifiziert. Die nachfolgenden Anfragen an AEM werden mit einem AEM-Login-Token-Cookie ausgeführt, solange das Cookie verfügbar ist.
Weitere Informationen zum SAML 2.0-Authentifizierungs-Handler finden Sie in der Dokumentation.
OAuth/SSO
Informationen zur Verwendung AEM SSO-Authentifizierungs-Handler-Service finden Sie in der Dokumentation zu Single Sign-On (SSO).
Die com.adobe.granite.auth.oauth.provider
-Schnittstelle kann mit dem OAuth-Anbieter Ihrer Wahl implementiert werden.
AEM as a Cloud Service verfügt über Cookie-basierte Sticky Sessions, die sicherstellen, dass Endbenutzende bei jeder Anfrage an denselben Veröffentlichungsknoten weitergeleitet werden. Um die Leistung zu steigern, ist die Funktion für „Encapsulated Tokens“ standardmäßig aktiviert, sodass Anwenderdatensätze im Repository nicht bei jeder Anfrage referenziert werden müssen. Wenn der Veröffentlichungsknoten, zu dem Endbenutzende gehören, ersetzt wird, ist der Datensatz mit der Anwender-ID auf dem neuen Veröffentlichungsknoten verfügbar, wie im nachfolgenden Abschnitt zur Datensynchronisierung beschrieben.
Es gibt verschiedene Ansätze zur Beibehaltung von Daten, abhängig von der Art der Daten.
Informationen zum Anwenderprofil können auf zwei Arten geschrieben und gelesen werden:
com.adobe.granite.security.user
-Schnittstelle „UserPropertiesManager“, die Daten unter dem Knoten des Anwenders in /home/users
platziert. Stellen Sie sicher, dass Seiten, die pro Benutzer eindeutig sind, nicht zwischengespeichert werden.Endbenutzerdaten können an Drittanbieter wie etwa CRMs gesendet und bei der Anmeldung von Benutzenden über APIs abgerufen werden. Sie werden auf dem Profil-Knoten der AEM-Benutzenden beibehalten und nach Bedarf von AEM verwendet.
Der Echtzeitzugriff auf Dienste von Drittanbietern zum Abruf von Profilattributen ist möglich. Es ist jedoch wichtig sicherzustellen, dass dies die Anfrageverarbeitung in AEM nicht wesentlich beeinflusst.
Zugriffsrichtlinien auf Veröffentlichungsebene, auch geschlossene Benutzergruppen genannt, werden in der AEM-Authoring-Umgebung wie hier beschrieben definiert. Um den Zugriff auf bestimmte Abschnitte oder Seiten einer Website für einige Benutzende zu beschränken, wenden Sie die geschlossenen Benutzergruppen nach Bedarf mithilfe der AEM-Authoring-Umgebung wie hier beschrieben an, und replizieren Sie sie auf der Veröffentlichungsebene.
Unabhängig von der Anmeldung kann benutzerdefinierter Code auch die Gruppenmitgliedschaften eines Anwenders beibehalten und verwalten, wie es die spezifischen Anforderungen eines Unternehmens erfordern.
Website-Endanwender erwarten bei jeder Website-Anfrage ein konsistentes Erlebnis. Das gilt auch dann, wenn sie sich mit einem anderen Browser anmelden, selbst wenn sie ihnen nicht bekannt sind, werden sie an verschiedene Server-Knoten der Infrastruktur auf Veröffentlichungsebene weitergeleitet. AEM as a Cloud Service erreicht dies durch die schnelle Synchronisierung der /home
Ordnerhierarchie (Benutzerprofilinformationen, Gruppenmitgliedschaft usw.) über alle Knoten der Veröffentlichungsstufe hinweg.
Anders als bei anderen AEM-Lösungen verfolgt die Anwender- und Gruppenmitgliedssynchronisierung in AEM as a Cloud Service keinen Point-to-Point-Messaging-Ansatz, sondern einen Ansatz, der auf Veröffentlichen/Abonnieren ausgelegt ist und keine Konfiguration durch den Kunden erfordert.
Standardmäßig ist die Synchronisierung von Anwenderprofilen und Gruppenmitgliedschaften nicht aktiviert, sodass die Daten nicht mit der Veröffentlichungsebene synchronisiert oder gar dauerhaft auf ihr beibehalten werden. Um die Funktion zu aktivieren, senden Sie eine Anfrage an den Kunden-Support, in der das entsprechende Programm und die entsprechenden Umgebung angegeben sind.
Das Zwischenspeichern authentifizierter HTTP-Anfragen sowohl im CDN als auch auf dem Dispatcher kann sich schwierig gestalten, da möglicherweise anwenderspezifische Status als Teil der Antwort auf die Anfrage übertragen werden. Das unbeabsichtigte Zwischenspeichern authentifizierter Anfragen und deren Bereitstellung für andere anfordernde Browser kann zu fehlerhaften Erlebnissen oder sogar zum Verlust von geschützten oder Anwenderdaten führen.
Ansätze für die Aufrechterhaltung einer hohen Cache-Fähigkeit von Anfragen bei gleichzeitiger Unterstützung anwenderspezifischer Antworten: