Geschlossene Benutzergruppen in AEM closed-user-groups-in-aem

Einführung introduction

Seit AEM 6.3 gibt es eine neue Implementierung geschlossener Benutzergruppen , die die Leistungs-, Skalierbarkeits- und Sicherheitsprobleme in der bestehenden Implementierung beheben soll.

Das Ziel der neuen Implementierung ist, wo nötig vorhandene Funktionen zu übernehmen, aber gleichzeitig Probleme und entwicklungsbedingte Einschränkungen älterer Versionen zu beheben. Das Ergebnis ist ein neues CUG-Design mit den folgenden Eigenschaften:

Die neue Implementierung der benutzerspezifischen Benutzergruppe the-new-custom-user-group-implementation

Eine CUG, wie sie im Kontext von AEM bekannt ist, besteht aus folgenden Schritten:

Die neue Implementierung wurde entwickelt, um eine Linie zwischen den Authentifizierungs- und den Autorisierungselementen zu ziehen. Ab AEM 6.3 ist es möglich, den Lesezugriff zu beschränken, ohne explizit eine Authentifizierungspflicht hinzuzufügen. Wenn beispielsweise eine bestimmte Instanz eine Authentifizierung erfordert oder sich eine bestimmte Struktur bereits in einer Unterstruktur befindet, für die bereits eine Authentifizierung erforderlich ist.

Gleichermaßen kann eine gegebene Baumstruktur mit einer Authentifizierungspflicht markiert werden, ohne die verwendete Berechtigungseinrichtung zu ändern. Die Kombinationen und Ergebnisse werden im Kombinieren von CUG-Richtlinien und der Authentifizierungspflicht Abschnitt.

Übersicht overview

Autorisierung: Beschränken des Lesezugriffs authorization-restricting-read-access

Die Schlüsselfunktion einer CUG besteht darin, den Lesezugriff auf eine bestimmte Struktur im Inhalts-Repository für alle außer ausgewählten Prinzipalen zu beschränken. Anstatt den standardmäßigen Inhalt der Zugriffskontrolle sofort zu bearbeiten, verfolgt die neue Implementierung einen anderen Ansatz, indem sie einen dedizierten Typ von Zugriffssteuerungsrichtlinie definiert, die eine CUG darstellt.

Zugriffssteuerungsrichtlinie für CUG access-control-policy-for-cug

Diese neue Art von Richtlinie weist die folgenden Merkmale auf:

Die Implementierung von PrincipalSetPolicy, das zur Darstellung von CUGs verwendet wird, definiert zusätzlich Folgendes:

Diese CUG-Richtlinien werden anhand eines separaten Autorisierungsmoduls namens „oak-authorization-cug“ auf einer AEM-Instanz bereitgestellt. Dieses Modul verfügt über eine eigene Zugriffssteuerungsverwaltung und Berechtigungsprüfung. Das heißt, die standardmäßige AEM-Einrichtung enthält eine Oak Content Repository-Konfiguration, die mehrere Autorisierungsmechanismen kombiniert. Weitere Informationen finden Sie auf dieser Seite auf der Apache Oak-Dokumentation.

In dieser Verbundeinrichtung ersetzen neue CUGs nicht den vorhandenen Zugriffssteuerungsinhalt, der dem Zielknoten angehängt ist, sondern sind als Zusatz entworfen, der später ebenso entfernt werden kann, ohne die ursprüngliche Zugriffssteuerung zu beeinträchtigen, die in AEM standardmäßig eine Zugriffssteuerungsliste darstellen würde.

Im Gegensatz zur früheren Implementierung werden die neuen CUG-Richtlinien immer als Zugriffssteuerungsinhalte erkannt und behandelt. Dies bedeutet, dass sie mit der JCR-Zugriffssteuerungs-Management-API erstellt und bearbeitet werden. Weitere Informationen finden Sie im Abschnitt Verwalten von CUG-Richtlinien.

Berechtigungsprüfung von CUG-Richtlinien permission-evaluation-of-cug-policies

Neben einer dedizierten Zugriffssteuerungsverwaltung für CUGs ermöglicht das neue Autorisierungsmodell die bedingte Aktivierung der Berechtigungsprüfung für seine Richtlinien. Dies ermöglicht das Einrichten von CUG-Richtlinien in einer Staging-Umgebung und ermöglicht nur die Auswertung der effektiven Berechtigungen, nachdem diese in die Produktionsumgebung repliziert wurden.

Die Berechtigungsprüfung für CUG-Richtlinien und die Interaktion mit dem standardmäßigen oder zusätzlichen Autorisierungsmodellen folgen dem Muster, das für mehrere Autorisierungsmechanismen in Apache Jackrabbit Oak entworfen wurde: Ein gegebener Berechtigungssatz wird gewährt, falls – und nur falls – alle Modelle Zugriff erteilen. Weitere Informationen finden Sie auf dieser Seite.

Die folgenden Merkmale gelten für die Berechtigungsprüfung im Zusammenhang mit dem Autorisierungsmodell zur Verarbeitung und Bewertung von CUG-Richtlinien:

Der Effekt einer einzelnen CUG-Richtlinie auf die Berechtigungsprüfung kann wie folgt zusammengefasst werden:

Best Practices best-practices

Die folgenden Best Practices sollten bei der Definition des eingeschränkten Lesezugriffs über CUGs berücksichtigt werden:

Authentifizierung: Authentifizierungspflicht definieren authentication-defining-the-auth-requirement

Die authentifizierungsbezogenen Teile der CUG-Funktion ermöglichen es, Baumstrukturen zu markieren, die eine Authentifizierung erfordern, und optional eine dedizierte Anmeldeseite anzugeben. Wie die vorherige Version ermöglicht die neue Implementierung das Markieren von Baumstrukturen, die Authentifizierung erfordern, im Content-Repository sowie die bedingte Aktivierung der Synchronisierung mit dem Sling org.apache.sling.api.auth.Authenticator, der für die Durchsetzung der Anforderung und die Weiterleitung an die Anmelderessource verantwortlich ist.

Diese Anforderungen werden mit dem Authenticator anhand eines OSGi-Dienstes registriert, der die Registrierungseigenschaft sling.auth.requirements zur Verfügung stellt. Diese Eigenschaften werden dann verwendet, um die Authentifizierungsanforderungen dynamisch zu erweitern. Weitere Informationen finden Sie im Sling-Dokumentation.

Definieren der Authentifizierungspflicht mit einem dedizierten Mixin-Typ defining-the-authentication-requirement-with-a-dedicated-mixin-type

Aus Sicherheitsgründen ersetzt die neue Implementierung die Verwendung einer übrigen JCR-Eigenschaft durch einen dedizierten Mixin-Typ mit der Bezeichnung granite:AuthenticationRequired. Er definiert eine einzelne optionale Eigenschaft des Typs STRING für den Anmeldepfad granite:loginPath. Nur Inhaltsänderungen mit Bezug zu diesem Mixin-Typ führen zur Aktualisierung der beim Apache Sling Authenticator registrierten Anforderungen. Die Änderungen werden nachverfolgt, wenn Übergangsänderungen beibehalten werden, daher muss javax.jcr.Session.save() aufgerufen werden, damit die Änderungen wirksam werden.

Dasselbe gilt für die Eigenschaft granite:loginPath. Sie wird nur berücksichtigt, wenn sie vom Mixin-Typ "auth-requirement"definiert wird. Wird eine Resteigenschaft mit genau diesem Namen einem nicht strukturierten JCR-Knoten hinzugefügt, hat dies nicht den gewünschten Effekt und die Eigenschaft wird von dem Handler ignoriert, der für die Aktualisierung der OSGi-Registrierung zuständig ist.

Registrieren der Authentifizierungspflicht und des Anmeldepfads mit dem Sling Authenticator registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

Da diese Art der Authentifizierungspflicht nur auf bestimmte Ausführungsmodi und auf eine kleine Teilmenge von Baumstrukturen innerhalb des Content-Repository beschränkt sein soll, ist das Tracking des Mixin-Typs der Anforderung und der Anmeldepfadeigenschaften eine Bedingung und gebunden an eine entsprechende Konfiguration, welche die unterstützten Pfade definiert (siehe „Konfigurationsoptionen“ weiter unten). Daher lösen nur Änderungen im Rahmen dieser unterstützten Pfade eine Aktualisierung der OSGi-Registrierung aus. Ansonsten werden der Mixin-Typ und die Eigenschaft ignoriert.

Die standardmäßige Einrichtung von AEM nutzt nun diese Konfiguration, indem sie ermöglicht, für den Mixin-Typ den Autorenausführungsmodus festzulegen, ihn aber erst wirksam werden zu lassen, wenn er auf die Veröffentlichungsinstanz repliziert wurde. Auf dieser Seite finden Sie Einzelheiten dazu, wie Sling die Authentifizierungspflicht durchsetzt.

Indem Sie in den konfigurierten unterstützten Pfaden den Mixin-Typ granite:AuthenticationRequired hinzufügen, wird die OSGi-Registrierung des verantwortlichen Handlers mit einem neuen, zusätzlichen Eintrag mit der Eigenschaft sling.auth.requirements aktualisiert. Wenn eine bestimmte Authentifizierungspflicht das optionale granite:loginPath -Eigenschaft, wird der Wert zusätzlich beim Authenticator mit dem Präfix "-"registriert, um von der Authentifizierungspflicht ausgeschlossen zu werden.

Prüfung und Vererbung der Authentifizierungspflicht evaluation-and-inheritance-of-the-authentication-requirement

Von Apache Sling-Authentifizierungsanforderungen wird erwartet, dass sie über die Seiten- oder Knotenhierarchie übernommen werden. Die genauen Details der Vererbung und die Bewertung der Authentifizierungsanforderungen wie Reihenfolge und Priorität werden als Implementierungsdetails betrachtet und in diesem Artikel nicht dokumentiert.

Auswertung des Anmeldepfads evaluation-of-login-path

Die Prüfung des Anmeldepfads und die Weiterleitung an die entsprechende Ressource bei Authentifizierung sind derzeit Implementierungsdetails von Adobe Granite Login Selector Authentication Handler (com.day.cq.auth.impl.LoginSelectorHandler), einem Apache Sling-AuthenticationHandler, der standardmäßig mit AEM konfiguriert ist.

Nach dem Aufruf von AuthenticationHandler.requestCredentials versucht dieser Handler, die Zuordnungsanmeldeseite zu identifizieren, an die der Benutzer weitergeleitet wird. Dazu gehören die folgenden Schritte:

Das Ziel dieser Dokumentation ist die Prüfung des Anmeldepfads, wie er von der internen Schnittstelle LoginPathProvider angezeigt wird. Die seit AEM 6.3 ausgelieferte Implementierung verhält sich wie folgt:

LoginPathProvider zeigt anhand der Implementierung der neuen Authentifizierungspflichtunterstützung in Granite Anmeldepfade, wie sie anhand der granite:loginPath-Eigenschaften definiert sind, die wiederum wie oben beschrieben vom Mixin-Typ definiert werden. Die Zuordnung des Ressourcenpfads mit dem Anmeldepfad und dem Eigenschaftswert selbst wird im Speicher beibehalten und ausgewertet, um einen geeigneten Anmeldepfad für andere Knoten in der Hierarchie zu finden.

Best Practices best-practices-1

Bei der Definition von Authentifizierungsanforderungen sollten die folgenden Best Practices berücksichtigt werden:

Darstellung im Repository representation-in-the-repository

Darstellung von CUG-Richtlinien im Repository cug-policy-representation-in-the-repository

Die Oak-Dokumentation beschreibt, wie die neuen CUG-Richtlinien im Repository-Content dargestellt werden. Weitere Informationen finden Sie unter diese Seite.

Authentifizierungspflicht im Repository authentication-requirement-in-the-repository

Die Notwendigkeit einer separaten Authentifizierungspflicht zeigt sich im Repository-Content anhand eines dedizierten Mixin-Knotentyps am Zielknoten. Der Mixin-Typ definiert eine optionale Eigenschaft, um eine dedizierte Anmeldeseite für die vom Zielknoten definierte Baumstruktur anzugeben.

Die mit dem Anmeldepfad verknüpfte Seite kann sich innerhalb oder außerhalb dieses Baums befinden. Sie wird von der Authentifizierungspflicht ausgeschlossen.

[granite:AuthenticationRequired]
      mixin
      - granite:loginPath (STRING)

Verwalten von CUG-Richtlinien und Authentifizierungspflichten managing-cug-policies-and-authentication-requirement

Verwalten von CUG-Richtlinien managing-cug-policies

Der neue Richtlinientyp für die Zugriffssteuerung, mit dem der Lesezugriff für eine CUG eingeschränkt wird, wird mithilfe der JCR-Zugriffssteuerungsverwaltungs-API verwaltet und folgt den Mechanismen, die in der Beschreibung von JCR 2.0 aufgeführt werden.

Neue CUG-Richtlinie festlegen set-a-new-cug-policy

Code zum Anwenden einer neuen CUG-Richtlinie auf einen Knoten, für den zuvor keine CUG festgelegt wurde. getApplicablePolicies gibt nur neue Richtlinien zurück, die noch nie festgelegt wurden. Am Ende muss die Richtlinie zurückgeschrieben und Änderungen müssen beibehalten werden.

String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

AccessControlPolicyIterator it = acMgr.getApplicablePolicies(path);
while (it.hasNext()) {
        AccessControlPolicy policy = it.nextAccessControlPolicy();
        if (policy instanceof PrincipalSetPolicy) {
           cugPolicy = (PrincipalSetPolicy) policy;
           break;
        }
}

if (cugPolicy == null) {
   log.debug("no applicable policy"); // path not supported or no applicable policy (e.g.
                                                   // the policy was set before)
   return;
}

cugPolicy.addPrincipals(toAdd1, toAdd2);
cugPolicy.removePrincipals(toRemove));

acMgr.setPolicy(path, cugPolicy); // as of this step the policy can be edited/removed
session.save();

Vorhandene CUG-Richtlinie bearbeiten edit-an-existing-cug-policy

Die folgenden Schritte sind erforderlich, um eine vorhandene CUG-Richtlinie zu bearbeiten. Beachten Sie, dass die geänderte Richtlinie zurückgeschrieben werden muss und Änderungen beibehalten werden müssen, indem Sie javax.jcr.Session.save().

String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
     if (policy instanceof PrincipalSetPolicy) {
        cugPolicy = (PrincipalSetPolicy) policy;
        break;
     }
}

if (cugPolicy == null) {
   log.debug("no policy to edit"); // path not supported or policy not set before
   return;
}

if (cugPolicy.addPrincipals(toAdd1, toAdd2) || cugPolicy.removePrincipals(toRemove)) {
   acMgr.setPolicy(path, cugPolicy);
   session.save();
} else {
     log.debug("cug policy not modified");
}

Effektive CUG-Richtlinien abrufen retrieve-effective-cug-policies

Die JCR-Zugriffssteuerungsverwaltung definiert eine Methode mit bestem Aufwand, um die Richtlinien abzurufen, die an einem bestimmten Pfad wirksam werden. Weil die Prüfung von CUG-Richtlinien bedingt ist und davon abhängt, ob die entsprechende Konfiguration aktiviert ist, stellt der Aufruf von getEffectivePolicies eine einfache Methode dar, um zu überprüfen, ob eine gegebene CUG-Richtlinie in einer gegebenen Installation wirksam ist.

String path = [...] // needs to be a supported, absolute path

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

// log an debug message of all CUG policies that take effect at the given path
// there could be zero, one or many (creating nested CUGs is possible)
for (AccessControlPolicy policy : acMgr.getEffectivePolicies(path) {
     if (policy instanceof PrincipalSetPolicy) {
        String policyPath = "-";
        if (policy instanceof JackrabbitAccessControlPolicy) {
           policyPath = ((JackrabbitAccessControlPolicy) policy).getPath();
        }
        log.debug("Found effective CUG for path '{}' at '{}', path, policyPath);
     }
}

Vererbte CUG-Richtlinien abrufen retrieve-inherited-cug-policies

Suchen aller verschachtelten CUGs, die an einem bestimmten Pfad definiert wurden, unabhängig davon, ob sie wirksam werden oder nicht. Weitere Informationen finden Sie unter Konfigurationsoptionen Abschnitt.

String path = [...]

List<AccessControlPolicy> cugPolicies = new ArrayList<AccessControlPolicy>();
while (isSupportedPath(path)) {
     for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
         if (policy instanceof PrincipalSetPolicy) {
            cugPolicies.add(policy);
         }
      }
      path = (PathUtils.denotesRoot(path)) ? null : PathUtils.getAncestorPath(path, 1);
}

Verwalten von CUG-Richtlinien nach Prinzipal managing-cug-policies-by-pincipal

Die durch JackrabbitAccessControlManager die die Bearbeitung von Zugriffskontrollrichtlinien durch Prinzipale ermöglichen, werden nicht mit der CUG-Zugriffssteuerungsverwaltung implementiert, da eine CUG-Richtlinie per Definition immer alle Prinzipale betrifft: mit den PrincipalSetPolicy erhalten Lesezugriff, während alle anderen Prinzipale daran gehindert werden, Inhalte in der vom Zielknoten definierten Baumstruktur zu lesen.

Die entsprechenden Methoden geben immer ein leeres Richtlinien-Array zurück, geben jedoch keine Ausnahmen aus.

Verwalten der Authentifizierungspflicht managing-the-authentication-requirement

Sie erstellen, ändern oder entfernen neue Authentifizierungspflichten, indem Sie den effektiven Knotentyp des Zielknotens ändern. Die optionale Anmeldepfadeigenschaft kann dann mit der normalen JCR-API geschrieben werden.

Hinzufügen einer neuen Authentifizierungspflicht adding-a-new-auth-requirement

Die Schritte zum Erstellen einer neuen Authentifizierungspflicht werden nachfolgend beschrieben. Die Pflicht wird nur dann beim Apache Sling Authenticator registriert, wenn der RequirementHandler für die Baumstruktur mit dem Zielknoten konfiguriert wurde.

Node targetNode = [...]

targetNode.addMixin("granite:AuthenticationRequired");
session.save();

Hinzufügen einer neuen Authentifizierungspflicht mit dem Anmeldepfad add-a-new-auth-requirement-with-login-path

Schritte zum Erstellen einer neuen Authentifizierungspflicht, einschließlich eines Anmeldepfads. Beachten Sie, dass die Anforderung und der Ausschluss für den Anmeldepfad nur beim Apache Sling Authenticator registriert werden, wenn die RequirementHandler wurde für den Baum mit dem Zielknoten konfiguriert.

Node targetNode = [...]
String loginPath = [...] // STRING property

Node targetNode = session.getNode(path);
targetNode.addMixin("granite:AuthenticationRequired");

targetNode.setProperty("granite:loginPath", loginPath);
session.save();

Vorhandenen Anmeldepfad ändern modify-an-existing-login-path

Die Schritte zum Ändern eines vorhandenen Anmeldepfads werden nachfolgend beschrieben. Die Änderung wird nur dann beim Apache Sling Authenticator registriert, wenn der RequirementHandler für die Baumstruktur mit dem Zielknoten konfiguriert wurde. Der Wert des vorherigen Anmeldepfads wird aus der Registrierung entfernt. Die mit dem Zielknoten verknüpfte Authentifizierungspflicht wird von dieser Änderung nicht beeinflusst.

Node targetNode = [...]
String newLoginPath = [...] // STRING property

if (targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", newLoginPath);
   session.save();
} else {
     log.debug("cannot modify login path property; mixin type missing");
}

Vorhandenen Anmeldepfad entfernen remove-an-existing-login-path

Schritte zum Entfernen eines vorhandenen Anmeldepfads. Die Registrierung des Anmeldepfadeintrags wird nur dann aus dem Apache Sling Authenticator entfernt, wenn der RequirementHandler für die Baumstruktur mit dem Zielknoten konfiguriert wurde. Die mit dem Zielknoten verknüpfte Authentifizierungspflicht ist nicht betroffen.

Node targetNode = [...]

if (targetNode.hasProperty("granite:loginPath") &&
   targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", null);
   session.save();
} else {
     log.debug("cannot remove login path property; mixin type missing");
}

Oder Sie können die folgende Methode verwenden, um denselben Zweck zu erreichen:

String path = [...] // absolute path to target node

String propertyPath = PathUtils.concat(path, "granite:loginPath");
if (session.propertyExists(propertyPath)) {
    session.getProperty(propertyPath).remove();
    // or: session.removeItem(propertyPath);
    session.save();
}

Authentifizierungspflicht entfernen remove-an-auth-requirement

Hier finden Sie Schritte zum Entfernen einer vorhandenen Authentifizierungspflicht. Die Registrierung der Anforderung wird nur dann vom Apache Sling Authenticator aufgehoben, wenn die RequirementHandler wurde für den Baum mit dem Zielknoten konfiguriert.

Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");

session.save();

Abrufen effektiver Authentifizierungspflichten retrieve-effective-auth-requirements

Es gibt keine dedizierte öffentliche API zum Lesen aller effektiven Authentifizierungspflichten, die beim Apache Sling Authenticator registriert sind. Die Liste wird jedoch in der Systemkonsole unter https://<serveraddress>:<serverport>/system/console/slingauth im Abschnitt Konfiguration der Authentifizierungspflicht verfügbar gemacht.

Die folgende Abbildung zeigt die Authentifizierungsanforderungen einer AEM Veröffentlichungsinstanz mit Demoinhalt. Der hervorgehobene Pfad der Community-Seite zeigt, wie eine von der in diesem Dokument beschriebenen Implementierung hinzugefügte Anforderung im Apache Sling Authenticator dargestellt wird.

Abrufen des effektiven Anmeldepfads retrieve-the-effective-login-path

Derzeit gibt es keine öffentliche API zum Abrufen des Anmeldepfads, der verwendet wird, wenn anonym auf eine Ressource zugegriffen wird, die eine Authentifizierung erfordert. Implementierungsdetails dazu, wie der Anmeldepfad abgerufen wird, finden Sie unter Bewertung des Anmeldepfads .

Beachten Sie jedoch, dass es neben den mit dieser Funktion definierten Anmeldepfaden alternative Möglichkeiten gibt, die Weiterleitung zur Anmeldung anzugeben, die bei der Erstellung des Inhaltsmodells und der Authentifizierungsanforderungen einer bestimmten AEM berücksichtigt werden sollten.

Abrufen der geerbten Authentifizierungspflicht retrieve-the-inherited-auth-requirement

Wie beim Anmeldepfad gibt es keine öffentliche API zum Abrufen der im Inhalt definierten geerbten Authentifizierungsanforderungen. Das folgende Beispiel zeigt, wie alle Authentifizierungspflichten aufgeführt werden, die mit einer bestimmten Hierarchie definiert wurden, unabhängig davon, ob sie wirksam sind oder nicht. Weitere Informationen finden Sie unter Konfigurationsoptionen.

String path = [...]
Node node = session.getNode(path);

Map<String, String> authRequirements = new ArrayList<String, String>();
while (isSupported(node)) {
     if (node.isNodeType("granite:AuthenticationRequired")) {
         String loginPath = (node.hasProperty("granite:loginPath") ?
                                     node.getProperty("granite:loginPath").getString() :
                                     "";
        authRequirements.put(node.getPath(), loginPath);
        node = node.getParent();
     }
}

Kombinieren von CUG-Richtlinien und der Authentifizierungspflicht combining-cug-policies-and-the-authentication-requirement

In der folgenden Tabelle sind die gültigen Kombinationen von CUG-Richtlinien und die Authentifizierungspflicht in einer AEM Instanz aufgeführt, in der beide Module durch Konfiguration aktiviert sind.

OSGi-Komponenten und -Konfiguration osgi-components-and-configuration

In diesen Abschnitten erhalten Sie einen Überblick über die OSGi-Komponenten und die einzelnen Konfigurationsoptionen, die mit der neuen CUG-Implementierung eingeführt wurden.

In der CUG-Zuordnungsdokumentation finden Sie eine umfassende Aufstellung der Konfigurationsoptionen der alten und der neuen Implementierung.

Autorisierung: Einrichtung und Konfiguration authorization-setup-and-configuration

Die neuen Teile für die Autorisierung gehören zum Bundle Oak CUG Authorization (org.apache.jackrabbit.oak-authorization-cug), das Teil der Standardinstallation von AEM ist. Das Bundle definiert ein separates Autorisierungsmodell, das als zusätzliche Methode zur Verwaltung des Lesezugriffs bereitgestellt werden soll.

Einrichten der CUG-Autorisierung setting-up-cug-authorization

Das Einrichten der CUG-Autorisierung wird in der relevanten Apache-Dokumentation detailliert beschrieben. Standardmäßig AEM die CUG-Autorisierung in allen Ausführungsmodi bereitgestellt. Die Schritt-für-Schritt-Anleitung kann auch verwendet werden, um die CUG-Autorisierung in Installationen zu deaktivieren, die eine andere Autorisierung erfordern.

Konfigurieren des Referrer-Filters configuring-the-referrer-filter

Sie müssen außerdem den Sling Referrer-Filter mit allen Host-Namen konfigurieren, die für den Zugriff auf AEM verwendet werden können, z. B. via CDN oder Lastenausgleich.

Wenn der Referrer-Filter nicht konfiguriert ist, treten Fehler wie die folgende auf, wenn ein Benutzer versucht, sich bei einer CUG-Site anzumelden:

31.01.2017 13:49:42.321 *INFO* [qtp1263731568-346] org.apache.sling.security.impl.ReferrerFilter Rejected referrer header for POST request to /libs/granite/core/content/login.html/j_security_check : https://hostname/libs/granite/core/content/login.html?resource=%2Fcontent%2Fgeometrixx%2Fen%2Ftest-site%2Ftest-page.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown

Eigenschaften von OSGi-Komponenten characteristics-of-osgi-components

Die folgenden beiden OSGi-Komponenten wurden eingeführt, um Authentifizierungspflichten zu definieren und dedizierte Anmeldepfade anzugeben:

org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration

org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl

Konfigurationsoptionen configuration-options

Die wichtigsten Konfigurationsoptionen sind:

Die verfügbaren Konfigurationsoptionen, die mit dem CUG-Autorisierungsmodul verbunden sind, sind im Abschnitt Dokumentation zu Apache Oak.

Ausschluss von Prinzipalen aus der CUG-Auswertung excluding-principals-from-cug-evaluation

Die Befreiung einzelner Prinzipale von der CUG-Bewertung wurde von der früheren Implementierung übernommen. Die neue CUG-Autorisierung behandelt dies anhand einer dedizierten Schnittstelle mit der Bezeichnung „CugExclude“. Apache Jackrabbit Oak 1.4 umfasst eine Standardimplementierung, die einen festen Satz von Prinzipalen sowie eine erweiterte Implementierung umfasst, welche die Konfiguration individueller Prinzipalnamen ermöglicht. Letztere wird in AEM Veröffentlichungsinstanzen konfiguriert.

Der Standardwert seit AEM 6.3 verhindert, dass die folgenden Prinzipale von CUG-Richtlinien betroffen sind:

Weitere Informationen finden Sie in der Tabelle im Standardkonfiguration seit AEM 6.3 unten.

Die Ausnahme der Administratorgruppe kann in der Systemkonsole im Konfigurationsabschnitt Apache Jackrabbit Oak CUG Exclude List geändert oder erweitert werden.

Alternativ ist es möglich, eine benutzerdefinierte Implementierung der CugExclude-Schnittstelle bereitzustellen, um den Satz ausgenommener Prinzipale im Falle spezieller Anforderungen anzupassen. Weitere Informationen sowie eine Beispielimplementierung finden Sie in der Dokumentation zu CUG-Austauschbarkeit.

Authentifizierung: Einrichtung und Konfiguration authentication-setup-and-configuration

Die neuen Teile für die Authentifizierung gehören zum Bundle Adobe Granite Authentication Handler (com.adobe.granite.auth.authhandler, Version 5.6.48). Dieses Bundle ist Teil der AEM Standardinstallation.

Um den Ersatz der Authentifizierungspflicht für die veraltete CUG-Unterstützung einzurichten, müssen einige OSGi-Komponenten in einer bestimmten AEM vorhanden und aktiv sein. Weitere Informationen finden Sie unter Eigenschaften von OSGi-Komponenten unten.

Eigenschaften von OSGi-Komponenten

Die folgenden 2 OSGi-Komponenten wurden eingeführt, um Authentifizierungspflichten zu definieren und dedizierte Anmeldepfade anzugeben:

com.adobe.granite.auth.requirement.impl.RequirementService

com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler

Konfigurationsoptionen configuration-options-1

Die authentifizierungsbezogenen Teile des CUG-Neuschreibens enthalten nur eine Konfigurationsoption, die mit der Adobe Granite Authentication Requirement and Login Path Handler verknüpft ist:

"Authentication Requirement and Login Path Handler"

Standardkonfiguration seit AEM 6.3 default-configuration-since-aem

Neue Installationen von AEM werden standardmäßig die neuen Implementierungen sowohl für die autorisierungs- als auch authentifizierungsbezogenen Teile der CUG-Funktion verwenden. Die alte Implementierung "Adobe Granite Closed User Group (CUG) Support" ist veraltet und wird standardmäßig in allen AEM Installationen deaktiviert. Die neuen Implementierungen werden stattdessen wie folgt aktiviert:

Autoreninstanzen author-instances

Veröffentlichungsinstanzen publish-instances

Deaktivieren der CUG-Autorisierungs- und Authentifizierungspflicht disabling-cug-authorization-and-authentication-requirement

Die neue Implementierung kann vollständig deaktiviert werden, wenn eine bestimmte Installation keine CUGs nutzt oder andere Authentifizierungs- und Autorisierungsmöglichkeiten verwendet.

CUG-Autorisierung deaktivieren disable-cug-authorization

Lesen Sie die CUG-Pluggabelbarkeit Dokumentation für Details zum Entfernen des CUG-Autorisierungsmodells aus der Composite-Autorisierungseinrichtung.

Authentifizierungspflicht deaktivieren disable-the-authentication-requirement

Zum Deaktivieren der Unterstützung der Authentifizierungspflicht, die vom Modul granite.auth.authhandler bereitgestellt wird, muss nur die Konfiguration entfernt werden, die mit Adobe Granite Authentication Requirement and Login Path Handler verknüpft ist.

Interaktion mit anderen Modulen interaction-with-other-modules

Apache Jackrabbit-API apache-jackrabbit-api

Um den neuen Typ der Zugriffssteuerungsrichtlinie widerzuspiegeln, die vom CUG-Autorisierungsmodell verwendet wird, wurde die von Apache Jackrabbit definierte API erweitert. Seit Version 2.11.0 definiert das Modul jackrabbit-api eine neue Schnittstelle mit der Bezeichnung org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy, die aus javax.jcr.security.AccessControlPolicy hervorgeht.

Apache Jackrabbit FileVault apache-jackrabbit-filevault

Der Importmechanismus von Apache Jackrabbit FileVault wurde angepasst, um mit Zugriffssteuerungsrichtlinien des Typs PrincipalSetPolicy umgehen zu können.

Apache Sling-Inhaltsverteilung apache-sling-content-distribution

Siehe oben Apache Jackrabbit FileVault Abschnitt.

Adobe Granite-Replikation adobe-granite-replication

Das Replikationsmodul wurde geringfügig angepasst, um die CUG-Richtlinien zwischen verschiedenen AEM zu replizieren:

Es gibt eine Einschränkung hinsichtlich der Replikation von CUG-Richtlinien. Wenn eine CUG-Richtlinie entfernt wird, ohne dass der entsprechende Mixin-Knotentyp rep:CugMixin, entfernt wird, wird die Entfernung in der Replikation nicht berücksichtigt. Dies wurde behoben, indem das Mixin beim Entfernen der Richtlinie immer entfernt wurde. Die Einschränkung kann jedoch angezeigt werden, wenn der Mixin-Typ manuell hinzugefügt wird.

Adobe Granite Authentication Handler adobe-granite-authentication-handler

Der Authentifizierungs-Handler Adobe Granite HTTP Header Authentication Handler im Bundle com.adobe.granite.auth.authhandler verweist auf die Schnittstelle CugSupport, die vom selben Modul definiert wird. Sie wird unter bestimmten Bedingungen zur Berechnung des Bereichs verwendet, wobei auf den mit dem Handler konfigurierten Bereich ausgewichen wird.

Dies wurde angepasst, um den Verweis auf CugSupport optional zu machen, um die größtmögliche Abwärtskompatibilität zu erreichen, wenn eine Einrichtung entscheidet, die veraltete Implementierung erneut zu aktivieren. Für Installationen, welche die Implementierung verwenden, wird der Bereich nicht mehr aus der CUG-Implementierung extrahiert, stattdessen wird der Bereich immer als mit Adobe Granite HTTP Header Authentication Handler definiert angezeigt.

AEM Live Copy aem-livecopy

Die Konfiguration von CUGs in Verbindung mit Live Copy wird im Repository durch das Hinzufügen eines zusätzlichen Knotens und einer zusätzlichen Eigenschaft wie folgt dargestellt:

Beide Elemente werden unter cq:Page erstellt. Mit dem aktuellen Design verarbeitet MSM nur Knoten und Eigenschaften, die sich unter dem Knoten cq:PageContent (jcr:content) befinden.

Daher können CUG-Gruppen in Live Copies nicht aus Blueprints bereitgestellt werden. Planen Sie dies ein, wenn Sie eine Live Copy konfigurieren.

Änderungen an der neuen CUG-Implementierung changes-with-the-new-cug-implementation

Ziel dieses Abschnitts ist es, einen Überblick über die Änderungen an der CUG-Funktion sowie einen Vergleich zwischen der alten und der neuen Implementierung zu geben. Er listet die Änderungen auf, die sich auf die Konfiguration der CUG-Unterstützung auswirken, und beschreibt, wie und von wem CUGs im Repository-Inhalt verwaltet werden.

Unterschiede bei der CUG-Einrichtung und -Konfiguration diferences-in-cug-setup-and-configuration

Die veraltete OSGi-Komponente Adobe Granite Closed User Group (CUG) Support (com.day.cq.auth.impl.cug.CugSupportImpl) wurde durch neue Komponenten ersetzt, damit die autorisierungs- und authentifizierungsrelevanten Teile des vorherigen CUG-Features getrennt verwaltet werden können.

Unterschiede beim Verwalten von CUGs im Repository-Content differences-in-managing-cugs-in-the-repository-content

In den folgenden Abschnitten werden die Unterschiede zwischen den alten und den neuen Implementierungen aus der Implementierung und der Sicherheitsperspektive beschrieben. Obwohl die neue Implementierung darauf abzielt, die gleichen Funktionen bereitzustellen, gibt es geringfügige Änderungen, die bei der Verwendung der neuen CUG wichtig sind.

Unterschiede bei der Zulassung diferences-with-regards-to-authorization

Die wichtigsten Unterschiede aus der Sicht der Zulassung sind in der folgenden Liste zusammengefasst:

Dedizierte Zugriffssteuerungsinhalte für CUGs

In der alten Implementierung wurde das standardmäßige Autorisierungsmodell verwendet, um Zugriffssteuerungslisten-Richtlinien bei der Veröffentlichung zu bearbeiten und bestehende ACEs durch das von der CUG angeforderte Setup zu ersetzen. Dies wurde durch das Schreiben regulärer, verbleibender JCR-Eigenschaften ausgelöst, die bei der Veröffentlichung interpretiert wurden.

Mit der neuen Implementierung wird die Einrichtung der Zugriffskontrolle des Standard-Autorisierungsmodells nicht dadurch beeinflusst, dass CUG erstellt, geändert oder entfernt wird. Stattdessen wird ein neuer Typ von Richtlinie mit der Bezeichnung PrincipalSetPolicy als zusätzlicher Zugriffssteuerungsinhalt auf den Zielknoten angewendet. Diese zusätzliche Richtlinie ist ein untergeordnetes Element des Zielknotens und ist ein gleichrangiges Element des Standardrichtlinienknotens, falls dieser vorhanden ist.

Bearbeiten von CUG-Richtlinien in der Zugriffssteuerungsverwaltung

Dieser Wechsel von den restlichen JCR-Eigenschaften zu einer dedizierten Zugriffskontrollrichtlinie hat Auswirkungen auf die Berechtigung, die zum Erstellen oder Ändern des Autorisierungsteils der CUG-Funktion erforderlich ist. Da dies eine Modifikation am Zugriffssteuerungsinhalt darstellt, sind die Berechtigungen jcr:readAccessControl und jcr:modifyAccessControl für das Schreiben in das Repository erforderlich. Daher können nur Inhaltsautoren, die berechtigt sind, den Inhalt der Zugriffskontrolle einer Seite zu ändern, diesen Inhalt einrichten oder ändern. Dies steht im Gegensatz zur alten Implementierung, bei der die Möglichkeit zum Schreiben regulärer JCR-Eigenschaften ausreichend war, was zu einer Berechtigungseskalation führte.

Von Richtlinie definierter Zielknoten

Es wird erwartet, dass CUG-Richtlinien auf dem JCR-Knoten erstellt werden, der die Unterstruktur definiert, die eingeschränktem Lesezugriff unterliegen soll. Dies ist wahrscheinlich eine AEM Seite, falls die CUG sich auf den gesamten Baum auswirken sollte.

Beachten Sie, dass das Platzieren der CUG-Richtlinie nur im Knoten jcr:content unterhalb einer bestimmten Seite nur den Zugriff auf den Inhalt einer bestimmten Seite einschränkt, jedoch nicht auf gleichrangigen oder untergeordneten Seiten wirkt. Dies kann ein gültiger Anwendungsfall sein. Sie erreichen dies mithilfe eines Repository-Editors, der die Anwendung detaillierter Zugriffssteuerungsinhalte erlaubt. In der früheren Implementierung wurde eine auf dem Knoten „jcr:content“ platzierte Eigenschaft „cq:cugEnabled“ intern dem Seitenknoten zugeordnet. Diese Zuordnung wird nicht mehr durchgeführt.

Berechtigungsprüfung mit CUG-Richtlinien

Die Umstellung von der alten CUG-Unterstützung auf ein zusätzliches Autorisierungsmodell verändert die Art und Weise, wie wirksame Leseberechtigungen geprüft werden. Wie im Abschnitt Jackrabbit-Dokumentation, ein bestimmter Prinzipal, der die CUGcontent wird nur dann Lesezugriff gewährt, wenn die Berechtigungsprüfung aller im Oak-Repository konfigurierten Modelle Lesezugriff gewährt.

Anders ausgedrückt, bei der Auswertung der wirksamen Berechtigungen werden sowohl CUGPolicy als auch die standardmäßigen Zugriffssteuerungseinträge berücksichtigt. Lesezugriff auf den CUG-Inhalt wird nur gewährt, wenn beide Richtlinientypen ihn gewähren. In einer standardmäßigen Veröffentlichungsinstallation von AEM, in der jedem Lesezugriff auf die vollständige Baumstruktur /content gewährt wird, haben die CUG-Richtlinien dieselben Auswirkungen wie in der alten Implementierung.

On-Demand-Auswertung

Das CUG-Autorisierungsmodell ermöglicht es, die Zugriffskontrolle und Berechtigungsprüfung einzeln zu aktivieren:

In der neuen Standardeinrichtung von AEM wird die Prüfung von CUG-Richtlinien nur im Ausführungsmodus „publish“ aktiviert. Zeigen Sie dazu die näheren Informationen zur Standardkonfiguration seit Einführung von AEM 6.3 an. Dies lässt sich überprüfen, indem die effektiven Richtlinien für einen bestimmten Pfad mit den im Inhalt gespeicherten Richtlinien verglichen werden. Wirksame Richtlinien werden nur angezeigt, wenn die Berechtigungsprüfung für CUGs aktiviert ist.

Wie oben erklärt, werden die CUG-Zugriffssteuerungsrichtlinien nicht immer im Inhalt gespeichert, aber die Prüfung der gültigen Berechtigungen, die aus diesen Richtlinien hervorgehen, wird nur durchgesetzt, wenn in der Systemkonsole in der CUG-Konfiguration von Apache Jackrabbit Oak die Option CUG-Prüfung aktiviert. aktiviert ist. Standardmäßig wird sie nur im Ausführungsmodus „Veröffentlichen“ aktiviert.

Unterschiede bei der Authentifizierung differences-with-regards-to-authentication

Die Unterschiede in Bezug auf die Authentifizierung werden im Folgenden beschrieben.

Dedizierter Mixin-Typ für Authentifizierungspflicht dedicated-mixin-type-for-authentication-requirement

In der bisherigen Implementierung wurden die Autorisierungs- und Authentifizierungsaspekte einer CUG durch eine einzelne JCR-Eigenschaft ausgelöst (cq:cugEnabled). Insoweit die Authentifizierung betroffen ist, hat dies zu einer aktualisierten Liste von Authentifizierungspflichten geführt, die in der Apache Sling Authenticator-Implementierung gespeichert werden. Bei der neuen Implementierung wird dasselbe Ergebnis erzielt, indem der Zielknoten mit einem dedizierten Mixin-Typ (granite:AuthenticationRequired) markiert wird.

Eigenschaft zum Ausnehmen des Anmeldepfads property-for-excluding-login-path

Der Mixin-Typ definiert eine einzelne optionale Eigenschaft mit der Bezeichnung granite:loginPath, die grundsätzlich der Eigenschaft cq:cugLoginPage entspricht. Im Gegensatz zur vorherigen Implementierung wird die Eigenschaft des Anmeldepfads nur berücksichtigt, wenn der deklarierende Knotentyp der erwähnte Mixin ist. Das Hinzufügen einer Eigenschaft mit diesem Namen ohne Festlegen des Mixin-Typs hat keine Auswirkungen, und weder eine neue Anforderung noch ein Ausschluss für den Anmeldepfad wird dem Authentifizierer gemeldet.

Berechtigung für Authentifizierungspflicht privilege-for-authentication-requirement

Zum Hinzufügen oder Entfernen eines Mixin-Typs ist die Berechtigung jcr:nodeTypeManagement erforderlich. In der vorherigen Implementierung wurde zum Bearbeiten der Resteigenschaft die Berechtigung jcr:modifyProperties benötigt.

Was granite:loginPath angeht, wird dieselbe Berechtigung benötigt, um die Eigenschaft hinzuzufügen, zu ändern oder zu entfernen.

Vom Mixin-Typ definierter Zielknoten target-node-defined-by-mixin-type

Authentifizierungspflichten sollen am JCR-Knoten erstellt werden und die Authentifizierungspflicht für den Teilbaum definieren. Dies ist wahrscheinlich eine AEM Seite, falls die CUG voraussichtlich die gesamte Baumstruktur betrifft und die Benutzeroberfläche für die neue Implementierung dementsprechend den Mixin-Typ auth-requirement auf dem Seitenknoten hinzufügt.

Wird die CUG-Richtlinie am Knoten „jcr:content“ unterhalb einer bestimmten Seite platziert, so wird nur der Zugriff auf den Inhalt einer bestimmten Seite eingeschränkt, wobei die Richtlinie keine Auswirkungen auf den Seitenknoten selbst oder auf untergeordnete Seiten hat.

Dies kann ein gültiges Szenario sein. Sie erreichen dies mithilfe eines Repository-Editors, der die Platzierung des Mixin-Typs an allen Knoten ermöglicht. Allerdings stellt das Verhalten einen Kontrast zur vorherigen Implementierung dar, wo eine auf dem Knoten „jcr:content“ platzierte Eigenschaft „cq:cugEnabled“ oder „cq:cugLoginPage“ intern dem Seitenknoten zugeordnet wurde. Diese Zuordnung wird nicht mehr durchgeführt.

Konfigurierte unterstützte Pfade configured-supported-paths

Sowohl der Mixin-Typ granite:AuthenticationRequired als auch die Eigenschaft „granite:loginPath“ werden nur innerhalb des Bereichs berücksichtigt, der durch den Konfigurationsoptionssatz Unterstützte Pfade in Adobe Granite Authentication Requirement and Login Path Handler definiert wird. Wenn keine Pfade festgelegt werden, wird das Authentifizierungspflicht-Feature komplett deaktiviert. In diesem Fall werden weder der Mixin-Typ noch die Eigenschaft wirksam, wenn sie hinzugefügt oder auf einen JCR-Knoten festgelegt werden.

Zuordnen von JCR-Inhalt, OSGi-Diensten und Konfigurationen mapping-of-jcr-content-osgi-services-and-configurations

Das folgende Dokument bietet eine umfassende Zuordnung von OSGi-Diensten, Konfigurationen und Repository-Inhalten der alten und der neuen Implementierung.

CUG-Zuordnung seit Einführung von AEM 6.3

Datei abrufen

CUG-Aktualisierung upgrade-cug

Vorhandene Installationen mit der veralteten CUG existing-installations-using-the-deprecated-cug

Die alte Implementierung der CUG-Unterstützung ist veraltet und wird in zukünftigen Versionen entfernt. Es wird empfohlen, beim Upgrade von älteren Versionen als AEM 6.3 auf die neuen Implementierungen umzustellen.

Bei einer aktualisierten AEM ist es wichtig sicherzustellen, dass nur eine CUG-Implementierung aktiviert ist. Die Kombination der neuen und alten, veralteten CUG-Unterstützung wird nicht getestet und kann wahrscheinlich zu unerwünschtem Verhalten führen:

Migrieren vorhandener CUG-Inhalte migrating-existing-cug-content

Adobe bietet ein Tool für die Migration zur neuen CUG-Implementierung. Führen Sie die folgenden Schritte aus, um sie zu verwenden: