Dienstbenutzer in Adobe Experience Manager (AEM)

Übersicht

Bisher erhielten Sie eine Admin-Sitzung oder einen Resource Resolver in AEM mithilfe der Sling-Methoden SlingRepository.loginAdministrative() und ResourceResolverFactory.getAdministrativeResourceResolver().

Allerdings waren diese beiden Methoden um das sogenannte Principle of Least Privilege (Prinzip der geringsten Berechtigung) aufgebaut und sie machen es Entwicklern zu einfach, anfangs eine angemessene Struktur und entsprechende Zugriffssteuerungsebenen für die Inhalte zu ignorieren. Wenn in einem solche Dienst eine Sicherheitslücke vorhanden ist, führt dies oft zu Berechtigungseskalationen an den admin, auch wenn der Code selbst keine Administratorrechte benötigt, um zu funktionieren.

Ausstieg aus Admin-Sitzungen

Priorität 0: Ist die Funktion aktiv/erforderlich/entfällt?

Es kann vorkommen, dass die Adminsitzung nicht verwendet wird oder die Funktion vollständig deaktiviert ist. Ist dies mit Ihrer Implementierung der Fall, entfernen Sie die Funktion vollständig oder bauen Sie Nulloperations-Code darin ein.

Priorität 1: Verwenden der Anforderungssitzung

Ändern Sie nach Möglichkeit Ihre Funktion so, dass die angegebene, authentifizierte Anfragesitzung zum Lesen oder Schreiben von Inhalten verwendet werden kann. Wenn dies nicht möglich ist, kann dies oft durch die Anwendung der folgenden Prioritäten erreicht werden.

Priorität 2: Inhalt neu strukturieren

Viele Probleme können durch eine inhaltliche Umstrukturierung gelöst werden. Beachten Sie bei der Umstrukturierung die folgenden einfachen Regeln:

• Zugriffskontrolle ändern

  • Stellen Sie sicher, dass die Benutzer oder Gruppen, die wirklich Zugriff benötigen, tatsächlich Zugriff haben.

• Inhaltsstruktur verfeinern

  • Verschieben Sie sie an andere Stellen, z. B. wo die Zugriffssteuerung mit den verfügbaren Anfragesitzungen übereinstimmt.
  • Ändern der Inhaltsgranularität;

• Code zum korrekten Dienst refaktorieren

  • Verschieben Sie die Geschäftslogik vom JSP-Code in den Dienst. Dies ermöglicht eine unterschiedliche Inhaltsmodellierung.

Stellen Sie außerdem sicher, dass alle neuen Funktionen, die Sie entwickeln, diesen Grundsätzen entsprechen:

• Sicherheitsanforderungen sollten die Inhaltsstruktur bestimmen

  • Die Zugriffskontrolle sollte sich als selbstverständlich erweisen
  • Die Zugriffskontrolle muss vom Repository durchgesetzt werden, nicht von der Anwendung

• Verwenden von Knotentypen

  • Beschränken Sie den Satz von Eigenschaften, die festgelegt werden können

• Datenschutzeinstellungen respektieren

  • Wenn es private Profile gibt, könnte ein Beispiel darin bestehen, das Profilbild, die E-Mail-Adresse oder den vollständigen Namen, der auf der privaten Seite gefunden wird, nicht anzuzeigen. /profile Knoten.

Strenge Zugriffssteuerung

Unabhängig davon, ob Sie Zugriffssteuerung bei der Umstrukturierung von Inhalten oder auf neue Dienstbenutzende anwenden, müssen Sie die strengsten möglichen Zugriffssteuerungsebenen anwenden. Nutzen Sie alle verfügbaren Funktionen für die Zugriffssteuerung:

• Wenden Sie beispielsweise jcr:read nicht auf /apps, sondern nur auf /apps/*/components/*/analytics an.

• Verwenden Sie Einschränkungen.

• Anwenden von ACLs für Knotentypen

• Berechtigungen begrenzen

  • Wenn jemand beispielsweise nur Eigenschaften schreiben muss, vergeben Sie nicht die Berechtigung jcr:write, sondern die Berechtigung jcr:modifyProperties.

Dienstbenutzende und Zuordnungen

Wenn der oben genannte Fehler auftritt, bietet Sling 7 einen Dienst für die Benutzerzuordnung, der die Konfiguration einer Bundle-zu-Benutzer-Zuordnung und zweier entsprechender API-Methoden ermöglicht:

• SlingRepository.loginService()
• ResourceResolverFactory.getServiceResourceResolver()

Die Methoden geben nur einen Sitzungs-/Ressourcen-Resolver mit den Berechtigungen eines konfigurierten Benutzers zurück. Diese Methoden verfügen über die folgenden Merkmale:

• Sie ermöglichen die Zuordnung von Diensten zu Benutzenden.

• Sie ermöglichen die Definition von Subdienstbenutzern

• Der zentrale Konfigurationspunkt ist: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.

• service-id = service-name [":" subservice-name]

• service-id wird einem Resource Resolver und/oder einer JCR-Repository-Benutzer-ID zur Authentifizierung zugewiesen.

• service-name ist der symbolische Name des Bundles, das den Service zur Verfügung stellt.

Sonstige Recommendations

Ersetzen der Admin-Sitzung durch einen Service-Benutzer

Ein Dienstbenutzer ist ein JCR-Benutzer ohne festgelegtes Kennwort und mit minimalen Berechtigungen, die für die Ausführung einer bestimmten Aufgabe erforderlich sind. Wenn kein Kennwort festgelegt ist, ist es nicht möglich, sich bei einem Dienstbenutzer anzumelden.

Eine Verwaltungssitzung kann eingestellt werden, indem sie durch Service-Benutzersitzungen ersetzt wird. Sie kann bei Bedarf auch durch mehrere Subdienstbenutzer ersetzt werden.

Um die Admin-Sitzung durch einen Dienstbenutzer zu ersetzen, führen Sie die folgenden Schritte aus:

1. Identifizieren Sie die erforderlichen Berechtigungen für Ihren Dienst unter Berücksichtigung des Prinzips der geringsten Berechtigung.

2. Überprüfen Sie, ob bereits ein Benutzer mit genau den benötigten Berechtigungen verfügbar ist. Erstellen Sie einen Systemdienstbenutzer, wenn kein bestehender Benutzer Ihren Anforderungen entspricht. RTC ist erforderlich, um einen Dienstbenutzer zu erstellen. Manchmal ist es sinnvoll, mehrere Subservice-Benutzer zu erstellen (z. B. einen für das Schreiben und einen für das Lesen), um den Zugriff noch stärker zu gliedern.

3. Richten Sie ACEs ein und testen Sie sie für Ihren Benutzer.

4. Fügen Sie eine service-user-Zuordnung für Ihren Dienst und für user/sub-users hinzu.

5. Stellen Sie das Dienstbenutzer-Sling-Feature Ihrem Bundle zur Verfügung: Aktualisieren Sie auf die neueste Version von org.apache.sling.api.

6. Ersetzen Sie die admin-session in Ihrem Code durch den loginService oder getServiceResourceResolver-APIs.

Dienstbenutzer erstellen

Nachdem Sie überprüft haben, ob kein Benutzer in der Liste AEM Dienstbenutzer für Ihren Anwendungsfall geeignet ist und die entsprechenden RTC-Probleme genehmigt wurden, können Sie fortfahren und den neuen Benutzer zum Standardinhalt hinzufügen.

Es wird empfohlen, einen Dienstbenutzer zu erstellen, um den Repository-Explorer unter https://<Server>:<Port>/crx/explorer/index.jsp zu verwenden.

Das Ziel besteht darin, eine gültige jcr:uuid -Eigenschaft, die erforderlich ist, um den Benutzer über eine Inhaltspaketinstallation zu erstellen.

Dienstbenutzende erstellen Sie wie folgt:

1. Verwenden Sie den Repository-Explorer unter https://<Server>:<Port>/crx/explorer/index.jsp..

2. Melden Sie sich als Administrator an, indem Sie die Anmelden in der oberen linken Ecke des Bildschirms.

3. Erstellen und benennen Sie als Nächstes Ihren Systembenutzer. Um den Benutzer als Systembenutzer zu erstellen, legen Sie den Zwischenpfad auf system und fügen Sie je nach Bedarf optionale Unterordner hinzu:

   

4. Überprüfen Sie, ob Ihr Systembenutzerknoten wie folgt aussieht:

   

   HINWEIS

   Dienstbenutzern sind keine Mixin-Typen zugeordnet. Das heißt, dass es für Systembenutzende keine Zugriffssteuerungsrichtlinien gibt.

Vergewissern Sie sich beim Hinzufügen der entsprechenden „.content.xml“ zum Inhalt des Bundles, dass Sie die rep:authorizableId festgelegt haben und der primäre Typ rep:SystemUser ist. Sie sollte wie folgt aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:rep="internal"
    jcr:primaryType="rep:SystemUser"
    jcr:uuid="4917dd68-a0c1-3021-b5b7-435d0044b0dd"
    rep:principalName="authentication-service"
    rep:authorizableId="authentication-service"/>

Hinzufügen einer Konfigurationsänderung zur ServiceUserMapper-Konfiguration

Um eine Zuordnung von Ihrem Dienst zu den entsprechenden Systembenutzern hinzuzufügen, erstellen Sie eine Werkskonfiguration für die ServiceUserMapper -Dienst. Um diesen modularen Aufbau beizubehalten, kann eine solche Konfiguration mithilfe des Sling-Änderungsmechanismus. Die empfohlene Methode zur Installation solcher Konfigurationen mit Ihrem Bundle ist die Verwendung von Laden anfänglicher Inhalte von Sling:

1. Erstellen Sie unterhalb des Ordners „src/main/resources“ des Bundles einen Unterordner „SLING-INF/content“.

2. Erstellen Sie in diesem Ordner eine Datei mit dem Namen org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.modified-<some unique="" name="" for="" your="" factory="" configuration="">.xml mit dem Inhalt Ihrer Factory-Konfiguration (einschließlich aller Subservice-Benutzerzuordnungen). Beispiel:

3. Erstellen Sie unterhalb des Ordners SLING-INF/content des Bundles einen Ordner src/main/resources.

4. Erstellen Sie in diesem Ordner eine Datei. named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml mit dem Inhalt Ihrer Werkskonfiguration, einschließlich aller Subservice-Benutzerzuordnungen.

   Nehmen Sie zur Veranschaulichung die Datei mit dem Namen org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-com.adobe.granite.auth.saml.xml:

   <?xml version="1.0" encoding="UTF-8"?>
   <node>
       <primaryNodeType>sling:OsgiConfig</primaryNodeType>
       <property>
           <name>user.default</name>
           <value></value>
       </property>
       <property>
           <name>user.mapping</name>
           <values>
               <value>com.adobe.granite.auth.saml=authentication-service</value>
           </values>
       </property>
   </node>
   

5. Verweisen Sie auf den anfänglichen Sling-Inhalt in der Konfiguration des maven-bundle-plugin in der Datei pom.xml Ihres Bundles. Beispiel:

   <Sling-Initial-Content>
      SLING-INF/content;path:=/libs/system/config;overwrite:=true;
   </Sling-Initial-Content>
   

6. Installieren Sie Ihr Bundle und stellen Sie sicher, dass die Werkskonfiguration installiert ist. Gehen Sie dazu wie folgt vor:

   • Wechseln Sie zur Web-Konsole unter https://Serverhost:Server-Adresse/system/console/configMgr.
   • Suchen Sie nach Apache Sling Service User Mapper Service Amendment.
   • Klicken Sie auf den Link, um zu sehen, ob die korrekte Konfiguration vorhanden ist.

Umgang mit freigegebenen Sitzungen in Diensten

loginAdministrative()-Aufrufe treten häufig zusammen mit freigegebenen Sitzungen auf. Diese Sitzungen werden bei Aktivierung des Diensts abgerufen und erst abgemeldet, wenn der Dienst gestoppt wird. Dies ist eine gängige Vorgehensweise führt aber zu zwei Problemen:

• Sicherheit: Diese Admin-Sitzungen werden verwendet, um Ressourcen oder andere Objekte, die an die freigegebene Sitzung gebunden sind, zwischenzuspeichern und zurückzugeben. Später im Aufrufstapel können diese Objekte an Sitzungen oder Ressourcenauflöser mit erhöhten Berechtigungen angepasst werden. Oft ist dem Aufrufer nicht klar, ob es sich um eine Admin-Sitzung handelt, mit der er arbeitet.
• Leistung: In Oak können freigegebene Sitzungen Leistungsprobleme verursachen, und es wird nicht empfohlen, diese zu verwenden.

Die offensichtlichste Lösung für das Sicherheitsrisiko besteht darin, den Aufruf loginAdministrative() durch einen Aufruf loginService() an eine Benutzerin oder einen Benutzer mit eingeschränkten Berechtigungen zu ersetzen. Dies hat jedoch keine Auswirkungen auf eine potenzielle Leistungsbeeinträchtigung. Eine Möglichkeit, dies zu umgehen, besteht darin, alle angeforderten Informationen in ein Objekt einzuschließen, das keine Verbindung zur Sitzung hat. Erstellen (oder zerstören) Sie dann die Sitzung nach Bedarf.

Der empfohlene Ansatz besteht darin, die API des Diensts neu zu gestalten, um dem Anrufer die Kontrolle über die Erstellung/Zerstörung der Sitzung zu geben.

Administrative Sitzungen in JSPs

JSPs können loginService() nicht verwenden, weil kein zugehöriger Dienst vorhanden ist. Allerdings sind Adminsitzungen in JSPs für gewöhnlich ein Zeichen einer Verletzung des MVC-Paradigmas.

Dies kann auf zwei Arten behoben werden:

1. Neustrukturierung des Inhalts auf eine Weise, die die Bearbeitung mit der Benutzersitzung ermöglicht;
2. Extrahieren der Logik zu einem Dienst, der eine API bereitstellt, die dann von der JSP verwendet werden kann.

Die erste Methode wird bevorzugt.

Verarbeitungsereignisse, Replikations-Präprozessoren und Aufträge

Bei der Verarbeitung von Ereignissen oder Aufträgen und manchmal Workflows geht die entsprechende Sitzung, die das Ereignis ausgelöst hat, verloren. Dies führt dazu, dass Ereignis-Handler und Auftragsverarbeiter häufig administrative Sitzungen verwenden, um ihre Arbeit zu erledigen. Es gibt verschiedene denkbare Ansätze, um dieses Problem zu lösen, jeweils mit ihren Vor- und Nachteilen:

1. user-id an die Ereignis-Payload weitergeben und Personifikation nutzen

   Vorteile: Benutzerfreundlich.

   Nachteile: Verwendet dennoch loginAdministrative(). Eine bereits authentifizierte Anforderung wird erneut authentifiziert.

2. Erstellen oder verwenden Sie einen Dienstbenutzer, der Zugriff auf die Daten hat.

   Vorteile: Entspricht aktuellem Design. Erfordert minimale Änderung.

   Nachteile: Benötigt leistungsstarke Dienstbenutzer, um flexibel zu sein, was leicht zu Berechtigungseskalationen führen kann. Umgeht das Sicherheitsmodell.

3. Übergeben Sie eine Serialisierung des Subject in der Ereignis-Payload und erstellen Sie einen ResourceResolver auf Grundlage dieses Betreffs. Ein Beispiel ist die Verwendung des JAAS doAsPrivileged in der ResourceResolverFactory.

   Vorteile: Saubere Implementierung von einem Sicherheitsstandpunkt aus. Es vermeidet die erneute Authentifizierung und funktioniert mit den ursprünglichen Berechtigungen. Der sicherheitsrelevante Code ist für den Verbraucher des Ereignisses transparent.

   Nachteile: Muss umstrukturiert werden. Die Tatsache, dass der sicherheitsrelevante Code für den Verbraucher des Ereignisses transparent ist, kann ebenfalls zu Problemen führen.

Der dritte Ansatz ist die bevorzugte Verarbeitungstechnik.

Workflow-Prozesse

Bei Workflow-Prozessimplementierungen geht die entsprechende Benutzersitzung verloren, die den Workflow ausgelöst hat. Dies führt zu Workflow-Prozessen, die häufig administrative Sitzungen verwenden, um ihre Arbeit auszuführen.

Um diese Probleme zu beheben, wird empfohlen, dieselben Ansätze zu verwenden, die unter Verarbeitungsereignisse, Replikations-Präprozessoren und Aufträge verwendet werden.

Sling POST Processors und gelöschte Seiten

Es gibt einige Verwaltungssitzungen, die in Sling POST Processor-Implementierungen verwendet werden. In der Regel werden Admin-Sitzungen verwendet, um auf Knoten zuzugreifen, die innerhalb der verarbeiteten POST noch gelöscht werden müssen. Daher sind sie nicht mehr über die Anforderungssitzung verfügbar. Auf einen Knoten, dessen Löschung aussteht, kann zugegriffen werden, um Metadaten anzuzeigen, auf die andernfalls nicht zugegriffen werden sollte.