Show Menu
THEMEN×

Geschlossene Benutzergruppen in AEM

Einführung

Seit Einführung von AEM 6.3 gibt es eine neue Implementierung des Features „Geschlossene Benutzergruppe“, welche die Probleme hinsichtlich der Leistung, Skalierbarkeit und Sicherheit der bestehenden Implementierung beheben soll.
Der Einfachheit halber wird das Feature im Rahmen dieser Dokumentation als „CUG“ abgekürzt (für Closed User Group, geschlossene Benutzergruppe).
Ziel der neuen Implementierung ist es, bestehende Funktionen bei Bedarf abzudecken und gleichzeitig Probleme und Designbeschränkungen älterer Versionen zu beheben. Das Ergebnis ist eine neue CUG-Version mit den folgenden Eigenschaften:
  • Deutliche Trennung der Authentifizierungs- und Autorisierungselemente, die einzeln oder in Kombination eingesetzt werden können
  • Dediziertes Autorisierungsmodell, das eingeschränkten Lesezugriff auf die konfigurierten CUG-Baumstrukturen bietet, ohne andere Einrichtungs- und Erlaubnisanforderungen für die Zugriffskontrolle zu beeinträchtigen
  • Trennung zwischen der Einrichtung der Zugriffssteuerung für den eingeschränkten Lesezugriff, die normalerweise in Autoreninstanzen benötigt wird, und der Berechtigungsüberprüfung, die normalerweise nur bei der Veröffentlichung gewünscht wird;
  • Bearbeiten des eingeschränkten Lesezugriffs ohne Berechtigungseskalation
  • Dedizierte Knotentyperweiterung zur Markierung der Authentifizierungspflicht
  • Optionaler, der Authentifizierungspflicht zugehöriger Anmeldepfad

Die neue benutzerdefinierte Benutzergruppenimplementierung

Eine CUG besteht im Kontext von AEM aus den folgenden Schritten:
  • Schränken Sie den Lesezugriff auf die Baumstruktur ein, die geschützt werden muss, und gewähren Sie nur Prinzipalen Lesezugriff, die entweder mit einer gegebenen CUG-Instanz aufgeführt oder in der CUG-Prüfung nicht berücksichtigt werden. Dies wird als Element der Autorisierung bezeichnet.
  • Erzwingen Sie die Authentifizierung bei einer gegebenen Baumstruktur und geben Sie optional eine dedizierte Anmeldeseite für die Struktur an, die daraufhin ausgeschlossen wird. Dies wird als Element der Authentifizierung bezeichnet.
Die neue Implementierung unterscheidet zwischen Autorisierungselementen und Authentifizierungselementen. Seit AEM 6.3 ist es möglich, den Lesezugriff zu beschränken, ohne eine Authentifizierungspflicht hinzufügen. Dies ist beispielsweise gebräuchlich, wenn eine bestimmte Instanz eine vollständige Authentifizierung anfordert oder eine gegebene Baumstruktur bereits in einem Teilbaum vorhanden ist, der bereits eine Authentifizierung anfordert.
Ebenso kann eine bestimmte Struktur mit einer Authentifizierungsanforderung versehen werden, ohne dass die effektive Berechtigungseinstellung geändert werden muss. Die Kombinationen und die Ergebnisse werden im Abschnitt Kombinieren von CUG-Richtlinien und der Authentifizierungspflicht aufgeführt.

Überblick

Autorisierung: Beschränken des Lesezugriffs

Das zentrale Feature einer CUG besteht in der Einschränkung des Lesezugriffs auf eine bestimmte Baumstruktur im Content-Repository für alle außer ausgewählte Prinzipale. Die neue Implementierung manipuliert nicht spontan die Standardinhalte der Zugriffssteuerung, sondern definiert einen dedizierten Typ von Zugriffssteuerungsrichtlinie, der eine CUG darstellt.

Zugriffssteuerungsrichtlinie für CUG

Dieser neue Typ von Richtlinie weist die folgenden Eigenschaften auf:
  • Zugriffssteuerungsrichtlinie des Typs org.apache.jackrabbit.api.security.approval.PrincipalSetPolicy (durch die Apache Jackrabbit-API definiert);
  • PrincipalSetPolicy gewährt Privilegien für einen veränderlichen Satz von Prinzipalen.
  • Die erteilten Berechtigungen und der Umfang dieser Richtlinie sind ein Implementierungsdetail.
Die Implementierung von PrincipalSetPolicy zur Darstellung von CUGs definiert außerdem Folgendes:
  • CUG-Richtlinien gewähren nur Lesezugriff auf reguläre JCR-Elemente (beispielsweise sind Zugriffssteuerungsinhalte ausgeschlossen).
  • Der Umfang wird durch den zugriffsgesteuerten Knoten definiert, der die CUG-Richtlinie enthält.
  • CUG-Richtlinien können verschachtelt werden. Eine verschachtelte CUG fängt als neue CUG an, ohne den Prinzipalsatz der übergeordneten CUG zu übernehmen.
  • Der Effekt der Richtlinie wird an den gesamten Teilbaum und bis an die nächste verschachtelte CUG weitergegeben.
Diese CUG-Richtlinien werden über ein separates Autorisierungsmodul namens oak-approval-cug auf einer AEM-Instanz bereitgestellt. Dieses Modul verfügt über eine eigene Zugriffssteuerungsverwaltung und Berechtigungsprüfung. Das heißt, die Standardversion von AEM umfasst eine Oak-Content-Repository-Konfiguration, die mehrere Autorisierungsmechanismen kombiniert. For more info, see this page on the Apache Oak Documentation .
In diesem Composite-Setup ersetzt ein neues CUG nicht den vorhandenen Zugriffssteuerungsinhalt, der an den Zielknoten angehängt ist, sondern ist als Ergänzung konzipiert, die später auch entfernt werden kann, ohne dass die ursprüngliche Zugriffssteuerung beeinträchtigt wird, die standardmäßig in AEM eine Zugriffssteuerungsliste wäre.
Anders als bei der vorherigen Implementierung werden neue CUG-Richtlinien immer als Zugriffssteuerungsinhalt erkannt und behandelt. Dies bedeutet, dass sie mit der JCR-Zugriffssteuerungsverwaltungs-API erstellt und bearbeitet werden. For more info, see the Managing CUG Policies section.

Berechtigungsprüfung von CUG-Richtlinien

Neben einer dedizierten Zugriffssteuerungsverwaltung für CUGs, ermöglicht das neue Autorisierungsmodell bedingt die Aktivierung der Berechtigungsprüfung für seine Richtlinien. Dies ermöglicht die Einrichtung von CUG-Richtlinien in einer Staging-Umgebung. Dabei wird die Prüfung der effektiven Berechtigungen erst aktiviert, wenn sie in die Produktionsumgebung repliziert werden.
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. See this page for more details.
Die folgenden Eigenschaften gelten für die Berechtigungsprüfung, die mit dem Autorisierungsmodell verknüpft ist, das CUG-Richtlinien verarbeiten und prüfen soll:
  • Sie verarbeitet nur Leseberechtigungen für normale Knoten und Eigenschaften, aber keine Zugriffssteuerungsinhalte.
  • Es werden weder Schreibberechtigungen noch Berechtigungen verarbeitet, die für die Änderung von geschützten JCR-Inhalten erforderlich sind (Zugriffssteuerung, Informationen zum Node-Typ, Versionierung, Sperren oder Benutzerverwaltung unter anderem); Diese Berechtigungen sind nicht von einer CUG-Richtlinie betroffen und werden nicht vom zugehörigen Autorisierungsmodell bewertet. Ob diese Berechtigungen gewährt werden, hängt von den anderen Modellen ab, die in der Sicherheitseinrichtung konfiguriert sind.
Die Auswirkungen einer einzelnen CUG-Richtlinie auf die Beurteilung von Genehmigungen lassen sich wie folgt zusammenfassen:
  • Lesezugriff wird allen vorenthalten, außer Subjekten, die ausgeschlossene oder aufgeführte Prinzipale enthalten.
  • Die Richtlinie gilt für den zugriffsgesteuerten Knoten, der die Richtlinie und ihre Eigenschaften enthält.
  • Der Effekt wird zusätzlich in der Hierarchie geerbt - also in der Elementstruktur, die durch den zugriffsgesteuerten Knoten definiert wird.
  • Gleichrangige Elemente oder Vorgänger des zugriffsgesteuerten Knotens sind nicht betroffen.
  • Die Vererbung einer gegebenen CUG hält an einer verschachtelten CUG an.

Best Practices

Die folgenden bewährten Vorgehensweisen müssen bei der Definition des eingeschränkten Lesezugriffs durch CUGs berücksichtigt werden:
  • Entscheiden Sie bewusst, ob Sie die CUG benötigen, um Lesezugriff einzuschränken oder die Authentifizierung zu erzwingen. Im letzteren Fall oder wenn beides erforderlich ist, finden Sie im Abschnitt über bewährte Verfahren Einzelheiten zur Authentifizierungspflicht
  • Erstellen Sie ein Bedrohungsmodell für die Daten oder Inhalte, die geschützt werden müssen, um Bedrohungsgrenzen zu identifizieren und ein klares Bild der Empfindlichkeit der Daten und Rollen zu erhalten, die mit autorisiertem Zugriff verbunden sind.
  • Modellieren Sie die Repository-Inhalte und CUGs unter Berücksichtigung allgemeiner Aspekte bezüglich der Autorisierung und bewährter Vorgehensweisen:
    • Denken Sie daran, dass Leseberechtigungen nur gewährt werden, wenn eine bestimmte CUG und die Prüfung anderer in der Einrichtung bereitgestellter Module einem bestimmten Subjekt erlauben, ein bestimmtes Repository-Element zu lesen.
    • Vermeiden Sie die Erstellung überflüssiger CUGs, wenn der Lesezugriff bereits von anderen Autorisierungsmodulen eingeschränkt ist.
    • Ein extremer Bedarf an verschachtelten CUGs weist möglicherweise auf Fehler beim Content-Design hin.
    • Ein extrem übermäßiger Bedarf an CUGs (z. B. auf jeder einzelnen Seite) weist möglicherweise darauf hin, dass ein benutzerdefiniertes Autorisierungsmodell besser geeignet wäre, um den Sicherheitsanforderungen der vorliegenden Anwendung und Inhalte gerecht zu werden.
  • Beschränken Sie die Pfade mit Unterstützung für CUG-Richtlinien auf einige wenige Baumstrukturen im Repository, um eine optimale Leistung zu ermöglichen. Beispielsweise können Sie CUGs unter dem Knoten /content nur als Standardwert seit AEM 6.3 zulassen.
  • CUG-Richtlinien sind darauf ausgelegt, einem kleinen Prinzipalsatz Lesezugriff zu gewähren. Der Bedarf an einer sehr großen Anzahl an Prinzipalen deutet möglicherweise auf Fehler beim Content- bzw. Anwendungsdesign hin und sollte überdacht werden.

Authentifizierung: Definieren der Authentifizierungspflicht

Die Teile des CUG-Features, die für Authentifizierung relevant sind, ermöglichen die Markierung von Baumstrukturen, die Authentifizierung erfordern, und optional die Angabe einer dedizierten Anmeldeseite. In accordance to the previous version, the new implementation allows to mark trees that require authentication in the content repository and conditionally enable synchronization with the Sling org.apache.sling.api.auth.Authenticator responsible for ultimately enforcing the requirement and redirecting to a login resource.
Diese Anforderungen werden mit dem Authenticator anhand eines OSGi-Services registriert, der die Registrierungseigenschaft sling.auth.requirements zur Verfügung stellt. Diese Eigenschaften werden dann dazu verwendet, die Authentifizierungspflichten dynamisch zu erweitern. Weitere Informationen finden Sie in der Sling-Dokumentation .

Definieren der Authentifizierungspflicht mithilfe eines dedizierten Mixin-Typs

For security reasons the new implementation replaces the usage of a residual JCR property by a dedicated mixin type called granite:AuthenticationRequired , which defines a single optional property of type STRING for the login path granite:loginPath . Nur Inhaltsänderungen mit Bezug zu diesem Mixin-Typ führen zur Aktualisierung der beim Apache Sling Authenticator registrierten Anforderungen. The modifications are tracked upon persisting any transient modifications and thus require a javax.jcr.Session.save() call to become effective.
The same applies for the granite:loginPath property. Sie wird nur berücksichtigt, wenn sie von dem Mixin-Typ definiert wird, der mit der Authentifizierungspflicht zusammenhängt. Wenn Sie eine Resteigenschaft mit diesem Namen auf einem unstrukturierten JCR-Knoten hinzufügen, wird der gewünschte Effekt nicht angezeigt und die Eigenschaft wird von dem für die Aktualisierung der OSGi-Registrierung verantwortlichen Handler ignoriert.
Die Anmeldepfadeigenschaft ist optional und muss nur dann festgelegt werden, wenn die Baumstruktur, welche die Authentifizierung erfordert, nicht auf den Standard oder eine anderweitig übernommene Anmeldeseite zurückfallen kann. Siehe dazu unten die Prüfung des Anmeldepfads .

Registrieren der Authentifizierungspflicht und des Anmeldepfads mit dem Sling Authenticator

Da diese Art von Authentifizierungsanforderungen voraussichtlich auf bestimmte Ausführungsmodi und auf eine kleine Untergruppe von Bäumen im Inhalts-Repository beschränkt sein wird, ist die Verfolgung des Anforderungsmixtyps und der Eigenschaften des Anmeldepfads bedingt und an eine entsprechende Konfiguration gebunden, die die unterstützten Pfade definiert (siehe Konfigurationsoptionen unten). Daher lösen nur Änderungen im Rahmen dieser unterstützten Pfade eine Aktualisierung der OSGi-Registrierung aus, anderswo werden der Mixin-Typ und die Eigenschaft ignoriert.
Das standardmäßige AEM-Setup nutzt diese Konfiguration jetzt, indem es ermöglicht, das mixin im Autorenmodus festzulegen, jedoch erst bei der Replikation auf die Veröffentlichungsinstanz wirksam zu machen. See this page for details how Sling enforces the authentication requirement.
Adding the granite:AuthenticationRequired mixin type within the configured supported paths will cause the OSGi registration of the responsible handler to be updated containing an new, additional entry with the sling.auth.requirements property. If a given authentication requirement specifes the optional granite:loginPath property, the value is additionally registered with the Authenticator with a '-' prefix in order to be excluded from authentication requirement.

Evaluation and Inheritance of the Authentication Requirement

Apache Sling-Authentifizierungspflichten sollen anhand der Seiten- oder Knotenhierarchie vererbt werden. Die Details der Vererbung und der Prüfung von Authentifizierungspflichten (wie Reihenfolge und Rangfolge) sind ein Implementierungsdetail und werden in diesem Artikel nicht behandelt.

Prüfung des Anmeldepfads

The evaluation of the login path and redirect to the corresponding resource upon authentication is currently an implementation detail of the Adobe Granite Login Selector Authentication Handler ( com.day.cq.auth.impl.LoginSelectorHandler ), which is an Apache Sling AuthenticationHandler configured with AEM by default.
Upon calling AuthenticationHandler.requestCredentials this handler makes an attempt to determine the mapping login page to which the user will be redirected. Dies umfasst die folgenden Schritte:
  • Es wird unterschieden, ob der Grund für die Weiterleitung ein abgelaufenes Kennwort oder eine normale Anmeldeanfrage ist.
  • Im Falle einer regulären Anmeldung wird in der folgenden Reihenfolge überprüft, ob ein Anmeldepfad abgerufen werden kann:
    • from the LoginPathProvider as implemented by the new com.adobe.granite.auth.requirement.impl.RequirementService ,
    • von der veralteten CUG-Implementierung
    • from the Login Page Mappings, as defined with the LoginSelectorHandler ,
    • and finally, fallback to the Default Login Page, as defined with the LoginSelectorHandler .
  • Sobald anhand der oben genannten Aufrufe ein gültiger Anmeldepfad abgerufen wurde, wird die Anforderung des Benutzers an diese Seite weitergeleitet.
The target of this documentation is the evaluation of the login path as exposed by the internal LoginPathProvider interface. Die seit Einführung von AEM 6.3 enthaltene Implementierung verhält sich wie folgt:
  • Die Registrierung des Anmeldepfads hängt von der Unterscheidung ab, ob der Grund für die Weiterleitung ein abgelaufenes Kennwort oder eine normale Anmeldeanfrage ist.
  • Im Falle einer regulären Anmeldung wird in der folgenden Reihenfolge überprüft, ob ein Anmeldepfad abgerufen werden kann:
    • from the LoginPathProvider as implemented by the new com.adobe.granite.auth.requirement.impl.RequirementService ,
    • von der veralteten CUG-Implementierung
    • from the Login Page Mappings as defined with the LoginSelectorHandler ,
    • and finally fallback to the Default Login Page as defined with the LoginSelectorHandler .
  • Sobald anhand der oben genannten Aufrufe ein gültiger Anmeldepfad abgerufen wurde, wird die Anforderung des Benutzers an diese Seite weitergeleitet.
The LoginPathProvider as implemented by the new auth-requirement support in Granite exposes login paths as defined by the granite:loginPath properties, which in turn are defined by the mixin type as described above. Die Zuordnung des Ressourcenpfads, der den Anmeldepfad und den Eigenschaftswert selbst enthält, wird im Speicher aufbewahrt und wird geprüft, um einen geeigneten Anmeldepfad für andere Knoten in der Hierarchie zu ermitteln.
Die Prüfung wird nur für Anfragen durchgeführt, die mit Ressourcen verknüpft sind, die sich in den konfigurierten unterstützten Pfaden befinden. Für alle anderen Anfragen werden die alternativen Möglichkeiten zum Ermitteln des Anmeldepfads geprüft.

Best Practices

Die folgenden bewährten Vorgehensweisen müssen bei der Definition von Authentifizierungspflichten berücksichtigt werden:
  • Verschachtelung von Authentifizierungspflichten vermeiden: Eine einzelne „auth-requirement“-Markierung am Anfang einer Baumstruktur sollte ausreichen und wird an den gesamten vom Zielknoten definierten Teilbaum weitergegeben. Zusätzliche Authentifizierungspflichten innerhalb dieser Baumstruktur sind als redundant zu betrachten und führen möglicherweise zu Leistungseinbußen bei der Prüfung der Authentifizierungspflicht in Apache Sling. Aufgrund der Trennung der autorisierungs- und authentifizierungsrelevanten CUG-Bereiche ist es möglich, den Lesezugriff anhand von CUG-Richtlinien oder anderen Richtlinien einzuschränken und gleichzeitig in der gesamten Baumstruktur die Authentifizierung zu erzwingen.
  • Passen Sie Repository-Inhalte so an, dass die Authentifizierungspflicht für die gesamte Baumstruktur gilt, ohne verschachtelte Nebenbäume wieder von ihr ausnehmen zu müssen.
  • Zur Vermeidung genauer Angaben und der darauf folgenden Registrierung redundanter Anmeldepfade:
    • Nutzen Sie die Vererbung und vermeiden Sie die Erstellung verschachtelter Anmeldepfade.
    • Legen Sie für den optionalen Anmeldepfad keinen Wert fest, der dem Standardwert oder einem vererbten Wert entspricht.
    • Anwendungsentwickler müssen identifizieren, welche Anmeldepfade in den globalen „login-path“-Konfigurationen (Standard und Zuordnungen) konfiguriert werden müssen, die mit dem LoginSelectorHandler verknüpft sind.

Darstellung im Repository

CUG-Richtliniendarstellung im Repository

Die Oak-Dokumentation beschreibt, wie die neuen CUG-Richtlinien im Repository-Inhalt widergespiegelt werden. Weitere Informationen finden Sie auf dieser Seite .

Authentifizierungspflicht im Repository

Die Notwendigkeit einer separaten Authentifizierung wird im Repository-Inhalt widergespiegelt, wobei ein dedizierter Mixin-Knotentyp auf dem Zielknoten platziert wird. Der Mixin-Typ definiert eine optionale Eigenschaft, um für die vom Zielknoten definierte Baumstruktur eine dedizierte Anmeldeseite festzulegen.
Die mit dem Anmeldepfad verknüpfte Seite kann sich innerhalb oder außerhalb dieser Baumstruktur befinden. Sie ist von der Authentifizierungspflicht ausgenommen.
[granite:AuthenticationRequired]
      mixin
      - granite:loginPath (STRING)

Verwalten von CUG-Richtlinien und der Authentifizierungspflicht

Verwalten von CUG-Richtlinien

The new type of access control policies to restrict read access for a CUG is managed using the JCR access control management API and follows the mechanisms described with the JCR 2.0 specification .

Neue CUG-Richtlinie erstellen

Code für die Anwendung einer neuen CUG-Richtlinie auf einen Knoten, der vorher keinen CUG-Satz aufwies. Please note that getApplicablePolicies will only return new policies that have not been set before. 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

Die folgenden Schritte sind erforderlich, um eine vorhandene CUG-Richtlinie zu bearbeiten. Die angepasste Richtlinie muss zurückgeschrieben und Änderungen müssen mit javax.jcr.Session.save() () beibehalten werden.
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

Die JCR-Zugriffssteuerungsverwaltung definiert eine optimale Methode zum Abrufen der Richtlinien, die an einem gegebenen Pfad wirksam sind. Due to the fact that evaluation of CUG policies is conditional and depends on the corresponding configuration to be enabled, calling getEffectivePolicies is a convenient way to verify if a given CUG policy is taking effect in a given installation.
Zwischen getEffectivePolicies und dem folgenden Codebeispiel, das die Hierarchie von unten nach oben betrachtet, um herauszufinden, ob ein gegebener Pfad bereits Teil einer bestehenden CUG ist, bestehen Unterschiede.
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);
     }
}

Übernommene CUG-Richtlinien abrufen

Suchen aller verschachtelten CUGs, die an einem bestimmten Pfad definiert wurden, gleichgültig, ob sie wirksam sind oder nicht. Weitere Informationen finden Sie im Abschnitt Konfigurationsoptionen .
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 Prinzipalen

Die von JackrabbitAccessControlManager definierten Erweiterungen, welche die Bearbeitung von Zugriffssteuerungsrichtlinien nach Prinzipalen ermöglichen, werden nicht anhand der CUG-Zugriffssteuerungsverwaltung implementiert, da CUG-Richtlinien per Definition immer alle Prinzipale betreffen: Den mit der PrincipalSetPolicy aufgeführten Prinzipalen wird Lesezugriff gewährt, während alle anderen Prinzipale in der vom Zielknoten definierten Baumstruktur keine Inhalte lesen können.
Die entsprechenden Methoden geben immer ein leeres Richtlinienfeld zurück, aber keine Ausnahmefehler.

Verwalten der Authentifizierungspflicht

Die Erstellung, Änderung oder Entfernung neuer Authentifizierungsanforderungen wird durch Änderung des effektiven Knotentyps des Zielknotens erreicht. Die optionale Anmeldepfadeigenschaft kann dann mit der normalen JCR-API geschrieben werden.
The modifications to a given target node mentioned above will only be reflected on the Apache Sling Authenticator if the RequirementHandler has been confgured and the target is contained in the trees defined by the supported paths (see section Configuration Options).
Weitere Informationen finden Sie unter #(https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.10.3 Zuweisen von Mischknoten-Typen) und #(https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.4 von Knoten und Festlegen von Eigenschaften).

Hinzufügen einer neuen Authentifizierungspflicht

Im Folgenden finden Sie Schritte zum Erstellen einer neuen Authentifizierungspflicht. Note that the requirement will only be registered with the Apache Sling Authenticator if the RequirementHandler has been configured for the tree containing the target node.
Node targetNode = [...]

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

Neue Authentifizierungspflicht mit Anmeldepfad hinzufügen

Hier finden Sie Schritte zum Erstellen einer neuen Authentifizierungspflicht mit einem Anmeldepfad. Die Pflicht und die Ausnahme für den Anmeldepfad wird nur dann beim Apache Sling Authenticator registriert, wenn der RequirementHandler für die Baumstruktur mit dem Zielknoten konfiguriert wurde.
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

Im Folgenden finden Sie Schritte zum Ändern eines vorhandenen Anmeldepfads. The modification will only be registered with the Apache Sling Authenticator if the RequirementHandler has been configured for the tree containing the target node. Der vorherige Anmeldepfadwert wird aus der Registrierung entfernt. Die mit dem Zielknoten verknüpfte Authentifizierungspflicht ist von dieser Änderung nicht betroffen.
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

Hier finden Sie 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");
}

Alternativ erfüllt die unten aufgeführte Methode denselben Zweck:
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

Hier finden Sie Schritte zum Entfernen einer vorhandenen Authentifizierungspflicht. Die Registrierung der Pflicht wird nur dann aus dem Apache Sling Authenticator entfernt, wenn der RequirementHandler für die Baumstruktur mit dem Zielknoten konfiguriert wurde.
Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");

session.save();

Effektive Authentifizierungspflichten abrufen

Es gibt keine dedizierte öffentliche API zum Lesen aller wirksamen Authentifizierungsanforderungen, die beim Apache Sling Authenticator registriert sind. Die Liste wird jedoch in der Systemkonsole https://<serveraddress>:<serverport>/system/console/slingauth im Abschnitt "Konfiguration der Authentifizierungsanforderung "angezeigt.
Die folgende Abbildung zeigt die Authentifizierungspflichten einer AEM -Veröffentlichungsinstanz mit Demoinhalten an. Der hervorgehobene Pfad der Community-Seite zeigt, wie eine von der in diesem Dokument beschriebenen Implementierung hinzugefügte Anforderung im Sling Apache Authenticator dargestellt wird.
In diesem Beispiel wurde die optionale Anmeldepfadeigenschaft nicht festgelegt. Folglich ist beim Authenticator kein zweiter Eintrag registriert.

Effektiven Anmeldepfad abrufen

Es gibt derzeit keine öffentliche API zum Abrufen des Anmeldepfads, der beim anonymen Zugriff auf eine Ressource, für die eine Authentifizierung erforderlich ist, wirksam wird. Im Abschnitt „Prüfung des Anmeldepfades“ finden Sie weitere Informationen dazu, wie der Anmeldepfad abgerufen wird.
Neben den anhand dieser Funktion definierten Anmeldepfaden gibt es noch andere Wege, die Weiterleitung zur Anmeldung zu definieren. Diese sollten bei der Entwicklung des Inhaltsmodells und der Authentifizierungspflichten einer jeweiligen AEM-Installation immer erwogen werden.

Übernommene Authentifizierungspflicht abrufen

Wie beim Anmeldepfad gibt es keine öffentlichen APIs zum Abrufen der im Inhalt definierten geerbten Authentifizierungspflichten. Im folgenden Beispiel wird veranschaulicht, wie alle Authentifizierungsanforderungen, die mit einer bestimmten Hierarchie definiert wurden, unabhängig davon, ob sie wirksam werden oder nicht, aufgelistet werden. Weitere Informationen finden Sie unter Konfigurationsoptionen .
Es wird empfohlen, sich sowohl für Authentifizierungsanforderungen als auch für den Anmeldepfad auf den Vererbungsmechanismus zu verlassen und die Erstellung verschachtelter Authentifizierungsanforderungen zu vermeiden.
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

In der folgenden Tabelle finden Sie die gültigen Kombinationen von CUG-Richtlinien und der Authentifizierungspflicht in einer AEM-Instanz, in der aufgrund der Konfiguration beide Module aktiviert sind.
Authentifizierung erforderlich
Anmeldepfad
Eingeschränkter Lesezugriff
Erwarteter Effekt
Ja
Ja
Ja
Ein bestimmter Benutzer kann die mit der CUG-Richtlinie markierte Unterstruktur nur anzeigen, wenn eine effektive Berechtigungsbewertung den Zugriff erlaubt. Ein nicht authentifizierter Benutzer wird an die angegebene Anmeldeseite umgeleitet.
Ja
Nein
Ja
Ein bestimmter Benutzer kann die mit der CUG-Richtlinie markierte Unterstruktur nur anzeigen, wenn eine effektive Berechtigungsbewertung den Zugriff erlaubt. Ein nicht authentifizierter Benutzer wird an eine übernommene Standardanmeldeseite umgeleitet.
Ja
Ja
Nein
Ein nicht authentifizierter Benutzer wird zur angegebenen Anmeldeseite weitergeleitet. Ob es erlaubt ist, die mit der Authentifizierungspflicht markierte Baumstruktur anzuzeigen, hängt von den effektiven Berechtigungen der einzelnen Elemente in dem Teilbaum ab. Es ist keine dedizierte CUG vorhanden, die den Lesezugriff einschränkt.
Ja
Nein
Nein
Ein nicht authentifizierter Benutzer wird an eine übernommene Standardanmeldeseite umgeleitet. Ob es erlaubt ist, die mit der Authentifizierungspflicht markierte Baumstruktur anzuzeigen, hängt von den effektiven Berechtigungen der einzelnen Elemente in dem Teilbaum ab. Es ist keine dedizierte CUG vorhanden, die den Lesezugriff einschränkt.
Nein
Nein
Ja
Ein bestimmter authentifizierter oder nicht authentifizierter Benutzer kann die mit der CUG-Richtlinie markierte Unterstruktur nur anzeigen, wenn eine effektive Berechtigungsbewertung den Zugriff zulässt. Ein nicht authentifizierter Benutzer wird gleich behandelt und nicht zur Anmeldeseite weitergeleitet.
Die Kombination Authentifizierungspflicht = Ja und Anmeldepfad = Ja wird oben nicht angeführt, da es sich beim Anmeldepfad um eine optionales, mit einer Authentifizierungspflicht verknüpftes Attribut handelt. Das Angeben einer JCR-Eigenschaft mit diesem Namen ohne Hinzufügen des definierten mixin-Typs hat keine Auswirkungen und wird vom entsprechenden Handler ignoriert.

OSGi-Komponenten und -Konfiguration

Diese Abschnitte bieten einen Überblick über die OSGi-Komponenten und die einzelnen Konfigurationsoptionen, die mit der neuen CUG-Implementierung eingeführt wurden.
Eine umfassende Zuordnung der Konfigurationsoptionen zwischen der alten und der neuen Implementierung finden Sie in der CUG-Zuordnungsdokumentation.

Autorisierung: Einrichtung und Konfiguration

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 Berechtigungsmodell, das als zusätzliche Option für die Verwaltung des Lesezugriffs gedacht ist.

Einrichten der CUG-Autorisierung

Setting up CUG authorization is described in detail in the relevant Apache Documentation . Standardmäßig stellt AEM die CUG-Autorisierung in allen Ausführungsmodi bereit. Die schrittweisen Anweisungen können auch verwendet werden, um die CUG-Autorisierung in Installationen zu deaktivieren, die eine andere Autorisierungseinrichtung erfordern.

Konfigurieren des Referrer-Filters

You also need to configure the Sling Referrer Filter with all hostnames that may be used to access AEM; for example, via CDN, Load Balancer, and any others.
Wenn der Referrer-Filter nicht konfiguriert ist, treten Fehler wie der folgende auf, wenn ein Benutzer versucht, sich bei einer CUG-Website 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

Die folgenden beiden OSGi-Komponenten wurden hinzugefügt, um Authentifizierungspflichten zu definieren und dedizierte Anmeldepfade festzulegen:
  • org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration
  • org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration
Etikett Apache Jackrabbit Oak CUG-Konfiguration
Beschreibung Autorisierungskonfiguration zum Einrichten und Auswerten der CUG-Berechtigungen.
Konfigurationseigenschaften
  • cugSupportedPaths
  • cugEnabled
  • configurationRanking
Siehe auch Konfigurationsoptionen unten.
Konfigurationsrichtlinie ConfigurationPolicy.REQUIRE
Verweise CugExclude (ReferenceCardinality.OPTIONAL_UNARY)
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
Etikett Apache Jackrabbit Oak CUG Liste ausschließen
Beschreibung Ermöglicht den Ausschluss von Prinzipalen mit dem/den konfigurierten Namen/en aus der CUG-Bewertung.
Konfigurationseigenschaften
  • principalNames
Siehe auch Konfigurationsoptionen unten.
Konfigurationsrichtlinie ConfigurationPolicy.REQUIRE
Verweise nicht vorhanden

Konfigurationsoptionen

Die wichtigsten Konfigurationsoptionen sind:
  • cugSupportedPaths : gibt die Teilbäume an, die CUGs enthalten dürfen. Es ist kein Standardwert festgelegt.
  • cugEnabled : Konfigurationsoption zur Aktivierung der Berechtigungsprüfung für die vorhandenen CUG-Richtlinien.
Die mit dem CUG-Autorisierungsmodul verknüpften verfügbaren Konfigurationsoptionen werden in der Apache Oak-Dokumentation aufgeführt und genauer beschrieben.

Ausnehmen von Prinzipalen von der CUG-Prüfung

Das Ausnehmen einzelner Prinzipale von der CUG-Prüfung wurde aus der vorherigen Implementierung übernommen. Die neue CUG-Autorisierung deckt dies mit einer dedizierten Schnittstelle namens CugExclude ab. 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 ist in AEM-Veröffentlichungsinstanzen konfiguriert.
Der Standard seit Einführung von AEM 6.3 verhindert, dass die folgenden Prinzipale von CUG-Richtlinien beeinflusst werden:
  • Prinzipale mit Administratorrechten (Administratoren, Administratorgruppe)
  • Dienstbenutzerprinzipale
  • Repository-interne Systemprinzipale
Weitere Informationen finden Sie in der Tabelle im folgenden Abschnitt Standardkonfiguration seit Einführung von AEM 6.3 .
The exclusion of the 'administrators' group can be altered or expanded in the system console in the configuration section of Apache Jackrabbit Oak CUG Exclude List .
Alternativ können Sie eine benutzerdefinierte Implementierung der CugExclude-Schnittstelle bereitstellen und bereitstellen, um die Gruppe ausgeschlossener Prinzipale bei besonderen Bedürfnissen anzupassen. See the documentation on CUG pluggability for details and an example implementation.

Authentifizierung: Einrichten und Konfiguration

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 Standardinstallation von AEM 
Zur Einrichtung des Authentifizierungspflichtersatzes für die veraltete CUG-Unterstützung müssen einige OSGi-Komponenten in einer jeweiligen AEM-Installation vorhanden und aktiv sein. Weitere Informationen finden Sie im Abschnitt Eigenschaften von OSGi-Komponenten unten.
Aufgrund der obligatorischen Konfigurationsoption mit dem RequirementHandler sind die zur Authentifizierung gehörigen Teile nur aktiv, falls das Feature durch Angabe eines Satzes unterstützter Pfade aktiviert wurde. Bei einer Standardinstallation von AEM ist das Feature im Autorenausführungsmodus deaktiviert und für „/content“ im Veröffentlichungsausführungsmodus aktiviert.
Eigenschaften von OSGi-Komponenten
Die folgenden beiden OSGi-Komponenten wurden hinzugefügt, um Authentifizierungspflichten zu definieren und dedizierte Anmeldepfade festzulegen:
  • com.adobe.granite.auth.requirement.impl.RequirementService
  • com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
com.adobe.granite.auth.requirement.impl.RequirementService
Etikett -
Beschreibung Spezifischer OSGi-Dienst für Authentifizierungsanforderungen, der einen Beobachter für Inhaltsänderungen registriert, die sich auf die Authentifizierungsanforderungen auswirken (durch den granite:AuthenticationRequirement Mixin-Typ), und Anmeldepfade, mit denen der LoginSelectorHandler ...
Konfigurationseigenschaften -
Konfigurationsrichtlinie ConfigurationPolicy.OPTIONAL
Verweise
  • RequirementHandler (ReferenceCardinality.MANDATORY_UNARY)
  • Executor (ReferenceCardinality.MANDATORY_UNARY)
com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
Etikett
Adobe Granite-Authentifizierungsanforderungen und Anmeldungspfad-Handler
Beschreibung
RequirementHandler Implementierung, die die Apache Sling-Authentifizierungsanforderungen und den entsprechenden Ausschluss für die zugehörigen Anmeldepfade aktualisiert.
Konfigurationseigenschaften
supportedPaths
Konfigurationsrichtlinie
ConfigurationPolicy.REQUIRE
Verweise
nicht vorhanden

Konfigurationsoptionen

Die Teile der CUG-Umschreibung, die für Authentifizierung relevant sind, umfassen nur eine einzelne Konfigurationsoption, die „Adobe Granite Authentication Requirement and Login Path Handler“ zugehörig ist:
„Authentication Requirement and Login Path Handler“
Eigenschaft Typ Standardwert Beschreibung
Beschriftung = Unterstützte Pfade
Name = 'supportedPaths'
Set<String> - Pfade, unter denen Authentifizierungsanforderungen von diesem Handler eingehalten werden. Leave this configuration unset if you want to add the granite:AuthenticationRequirement mixin type to nodes without having them enforced (for example, on author instances). Wenn nicht vorhanden, ist die Funktion deaktiviert.

Standardkonfiguration seit Einführung von AEM 6.3

Neue Installationen von AEM verwenden standardmäßig die neuen Implementierungen für die autorisierungs- und authentifizierungsrelevanten Teile des CUG-Features. Die alte Implementierung „Adobe Granite Closed User Group (CUG) Support“ ist veraltet und wird standardmäßig in allen Installationen von AEM deaktiviert. Stattdessen werden die neuen Implementierungen wie folgt aktiviert:

Autoreninstanzen

"Apache Jackrabbit Oak CUG Configuration"
Erklärung
Unterstützte Pfade /content
Zugriffssteuerungsverwaltung für CUGpolicies ist aktiviert.
CUG-Test aktiviert FALSE
Die Berechtigungsauswertung ist deaktiviert. CUG-Richtlinien sind nicht wirksam.
Rangansicht
200
Für Apache Jackrabbit Oak CUG Exclude List und Adobe Granite Authentication Requirement and Login Path Handler ist auf standardmäßigen Autoreninstanzen keine Konfiguration vorhanden.

Veröffentlichungsinstanzen

"Apache Jackrabbit Oak CUG Configuration"
Erklärung
Unterstützte Pfade /content
Die Verwaltung der Zugriffssteuerung für CUG-Richtlinien ist unterhalb der konfigurierten Pfade aktiviert.
CUG-Bewertung aktiviert TRUE
Die Berechtigungsauswertung ist unterhalb der konfigurierten Pfade aktiviert. Die CUG-Politik wird mit Wirkung Session.save() .
Rangansicht
200
"Apache Jackrabbit Oak CUG Exclude List"
Erklärung
Prinzipalnamenadministratoren
Schließt Administratorprinzipal aus der CUG-Auswertung aus.
"Adobe Granite Authentication Requirement and Login Path Handler"
Erklärung
Unterstützte Pfade /content
Die Authentifizierungsanforderungen, wie sie im Repository mithilfe des granite:AuthenticationRequired Mixin-Typs definiert sind, treten /content bei Session.save() ein. Sling Authenticator wird aktualisiert. Wird der Mixin-Typ außerhalb der unterstützten Pfade hinzugefügt, so wird dies ignoriert.

Deaktivieren der CUG-Autorisierungs- und Authentifizierungspflicht

Diese neue Implementierung kann u. U. vollständig deaktiviert werden, falls eine bestimmte Installation keine CUGs nutzt bzw. eine andere Möglichkeit für Authentifizierung und Autorisierung verwendet.

CUG-Autorisierung deaktivieren

In der Dokumentation zur CUG-Austauschbarkeit finden Sie Informationen dazu, wie Sie das CUG-Autorisierungsmodell aus der kombinierten Autorisierungseinrichtung entfernen.

Authentifizierungspflicht deaktivieren

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.
Beachten Sie jedoch, dass das Entfernen der Konfiguration die Registrierung des Mixin-Typs nicht aufheben wird, der weiterhin auf Knoten ohne Wirkung anwendbar war.

Interaktion mit anderen Modulen

Apache Jackrabbit-API

Die von Apache Jackrabbit definierte API wurde erweitert, um dem neuen Typ von Zugriffssteuerungsrichtlinie zu entsprechen, die vom CUG-Autorisierungsmodell verwendet wird. Since version 2.11.0 of the jackrabbit-api module defines a new interface called org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy , which extends from javax.jcr.security.AccessControlPolicy .

Apache Jackrabbit FileVault

The import mechanism of Apache Jackrabbit FileVault has been adjusted to deal with access control policies of type PrincipalSetPolicy .

Apache Sling-Inhaltsverteilung

Weitere Informationen finden Sie oben im Abschnitt Apache Jackrabbit FileVault .

Adobe Granite-Replikation

Das Replikationsmodul wurde etwas angepasst, um in der Lage zu sein, die CUG-Richtlinien zwischen verschiedenen AEM-Instanzen zu replizieren:
  • DurboImportConfiguration.isImportAcl() wird wörtlich interpretiert und betrifft nur die Richtlinien zur Zugangskontrolle, die javax.jcr.security.AccessControlList
  • DurboImportTransformer wird diese Konfiguration nur für echte ACLs respektieren
  • Andere Richtlinien, z. B. vom CUG-Autorisierungsmodell erstellte org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy -Instanzen, werden immer repliziert und die Konfigurationsoption DurboImportConfiguration.isImportAcl () wird ignoriert.
Es gibt eine Einschränkung hinsichtlich der Replikation von CUG-Richtlinien. If a given CUG policy gets removed without removing the corresponding mixin node type rep:CugMixin, the removal will not be reflected upon replication. Dies wurde korrigiert, indem bei Entfernung einer Richtlinie immer der Mixin-Typ entfernt wird. Die Einschränkung macht sich aber möglicherweise bemerkbar, wenn der Mixin-Typ manuell hinzugefügt wurde.

Adobe Granite-Authentifizierungs-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 zurückgefallen 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. Installations using the implementation will no longer get the realm extracted from the CUG implementation but will always display the realm as defined with Adobe Granite HTTP Header Authentication Handler .
Standardmäßig ist Adobe Granite HTTP Header Authentication Handler nur im Veröffentlichungsausführungsmodus konfiguriert, wobei die Option „Anmeldeseite deaktivieren“ ( auth.http.nologin ) aktiviert ist.

AEM-Live Copy

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:
  • /content/we-retail/us/en/blueprint/rep:cugPolicy
  • /content/we-retail/us/en/LiveCopy@granite:loginPath
Both of these elements are created under the cq:Page . With the current design, MSM only handles nodes and properties that are under the cq:PageContent ( jcr:content ) node.
Daher können CUG-Gruppen nicht aus einem Blueprint in eine Live Copy zurückgesetzt werden. Planen Sie entsprechend, wenn Sie eine Live Copy einrichten.

Änderungen mit der neuen CUG-Implementierung

Das Ziel dieses Abschnitts besteht darin, einen Überblick über die am CUG-Feature vorgenommenen Änderungen sowie einen Vergleich der alten und der neuen Implementierung zur Verfügung zu stellen. Es werden alle Änderungen aufgeführt, die beeinflussen, wie CUG-Unterstützung konfiguriert wird, und beschrieben, wie und von wem CUGs im Repository-Content verwaltet werden.

Unterschiede bei CUG-Einrichtung und -Konfiguration

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.

Differences in Managing CUGs in the Repository Content

Die folgenden Abschnitte beschreiben die Unterschiede zwischen der alten und der neuen Implementierung aus der Implementierungs- und Sicherheitsperspektive. Die neue Implementierung soll dieselbe Funktionalität zur Verfügung stellen, aber es gibt einige dezente Unterschiede, die Sie kennen sollten, wenn Sie das neue CUG-Feature verwenden.

Unterschiede in Bezug auf Autorisierung

Im Folgenden finden Sie eine Zusammenfassung der wichtigsten Unterschiede hinsichtlich Autorisierung:
Dedizierter Zugriffssteuerungsinhalt für CUGs
In der alten Implementierung wurde das standardmäßige Autorisierungsmodell dazu verwendet, die Zugriffssteuerungslistenrichtlinien auf der Veröffentlichungsinstanz zu manipulieren, wobei bestehende ACEs aufgrund der von der CUG erzwungenen Einrichtung ersetzt wurden. Dies wurde durch die Eingabe regulärer JCR-Resteigenschaften ausgelöst, die auf der Veröffentlichungsinstanz interpretiert wurden.
Bei der neuen Implementierung wird die Zugriffssteuerungseinrichtung des Standardautorisierungsmodells nicht von der Erstellung, Änderung oder Entfernung von CUGs beeinflusst. Instead a new type of policy called PrincipalSetPolicy is applied as additional access control content to the target node. 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
Dieses Abweichen von JCR-Resteigenschaften hin zu einer dedizierten Zugriffssteuerungsrichtlinie hat Auswirkungen auf die Berechtigung, die zum Erstellen oder Ändern des Autorisierungsteils des CUG-Features benötigt wird. Since this is considered a modification to access control content, it requires jcr:readAccessControl and jcr:modifyAccessControl privileges in order to be written to the repository. Daher können nur Inhaltsautoren, die zur Änderung der Zugriffssteuerungsinhalte einer Seite berechtigt sind, diese Inhalte einrichten oder ändern. Im Vergleich dazu war in der alten Implementierung die Berechtigung zum Schreiben regulärer JCR-Eigenschaften ausreichend. Dies führt zu einer Berechtigungseskalation.
Durch eine Richtlinie definierter Zielknoten
CUG-Richtlinien sollen am JCR-Knoten erstellt werden und die Leseberechtigung für den Teilbaum einschränken. Hierbei handelt es sich wahrscheinlich um eine AEM-Seite, falls die CUG die gesamte Baumstruktur betreffen soll.
Beachten Sie, dass das Platzieren der CUG-Richtlinie nur am Knoten jcr:content unterhalb einer bestimmten Seite den Zugriff auf den Inhalt einer bestimmten Seite beschränkt, jedoch nicht auf Geschwisterseiten oder untergeordneten Seiten wirksam wird. Dies kann ein gültiger Anwendungsfall sein. Sie erreichen dies mithilfe eines Repository-Editors, der die Anwendung detaillierter Zugriffssteuerungsinhalte erlaubt. Es steht jedoch im Gegensatz zur früheren Implementierung, bei der die Platzierung einer cq:cugEnabled-Eigenschaft auf dem Knoten jcr:content intern dem Seitenknoten neu zugeordnet wurde. 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 in der Jackrabbit-Dokumentation beschrieben, wird einem jeweiligen Prinzipal mit der Berechtigung zum Anzeigen des CUGcontent 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 die CUGPolicy als auch die Standardzugriffssteuerungseinträge berücksichtigt. Lesezugriff auf den CUG-Inhalt wird nur gewährt, wenn beide Richtlinientypen ihn gewähren. In a default AEM publish installation where read access to the complete /content tree is granted for everyone, the effect of the CUG policies will be the same as with the old implementation.
Prüfung nach Bedarf
Das CUG-Autorisierungsmodell ermöglicht das individuelle Aktivieren von Zugriffssteuerungsverwaltung und Berechtigungsprüfung:
  • Zugriffssteuerungsverwaltung wird aktiviert, wenn das Modul über einen oder mehrere unterstützte Pfade verfügt, in denen CUGs erstellt werden können.
  • Berechtigungsprüfung wird nur aktiviert, wenn die Option CUG-Prüfung aktiviert zusätzlich aktiviert wird.
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 durch den Vergleich der wirksamen Richtlinien eines Pfades mit den im Inhalt gespeicherten Richtlinien verifizieren. Wirksame Richtlinien werden nur angezeigt, wenn die Berechtigungsprüfung für CUGs aktiviert ist.
As explained above the CUG access control policies are now always stored in the content but evaluation of the effective permissions that result from those policies will only be enforced if CUG Evaluation Enabled is turned on in the system console at Apache Jackrabbit Oak CUG Configuration. Standardmäßig ist sie nur im Ausführungsmodus "Veröffentlichen"aktiviert.

Unterschiede in Bezug auf Authentifizierung

Im Folgenden werden die Unterschiede im Hinblick auf die Authentifizierung beschrieben.

Dedizierter Mixin-Typ für Authentifizierungspflicht

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 Anmeldepfades

The mixin type defines a single, optional property called granite:loginPath , which basically corresponds to the cq:cugLoginPage property. Im Gegensatz zur früheren Implementierung wird die Anmeldepfadeigenschaft nur berücksichtigt, wenn ihr deklarierender Knotentyp im Mixin-Typ aufgeführt wird. Wird eine Eigenschaft mit diesem Namen hinzugefügt, ohne den Mixin-Typ festzulegen, hat dies keine Auswirkungen und an den Authenticator werden keine neue Pflicht und keine Ausnahme für den Anmeldepfad gemeldet.

Berechtigung für Authentifizierungspflicht

Zum Hinzufügen oder Entfernen eines Mixin-Typs ist die Berechtigung jcr:nodeTypeManagement erforderlich. In the previous implementation, the jcr:modifyProperties privilege is used to edit the residual property.
Was granite:loginPath angeht, wird dieselbe Berechtigung benötigt, um die Eigenschaft hinzuzufügen, zu ändern oder zu entfernen.

Vom Mixin-Typ definierter Zielknoten

Authentifizierungspflichten sollen am JCR-Knoten erstellt werden und die Authentifizierungspflicht für den Teilbaum definieren. Hierbei handelt es sich wahrscheinlich um eine AEM-Seite, falls die CUG die gesamte Baumstruktur betreffen soll. Die Benutzeroberfläche für die neue Implementierung fügt den Mixin-Typ „auth-requirement“ konsequent dem Seitenknoten hinzu.
Wenn Sie die CUG-Richtlinie nur auf dem Knoten jcr:content unterhalb einer bestimmten Seite platzieren, wird der Zugriff auf den Inhalt nur eingeschränkt, jedoch nicht auf dem Seitenknoten selbst oder auf untergeordneten Seiten.
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. Das Verhalten steht jedoch im Gegensatz zur früheren Implementierung, bei der das Platzieren einer Eigenschaft cq:cugEnabled oder cq:cugLoginPage auf dem Knoten jcr:content intern letztendlich dem Knoten page zugeordnet wurde. Diese Zuordnung wird nicht mehr durchgeführt.

Konfigurierte unterstützte Pfade

Both the granite:AuthenticationRequired mixin type and the granite:loginPath property will only be respected within the scope defined by the set of Supported Paths configuration option present with the Adobe Granite Authentication Requirement and Login Path Handler . Wenn keine Pfade festgelegt werden, wird das Authentifizierungspflicht-Feature komplett deaktiviert. In diesem Fall werden mixin-Typ und -Eigenschaft wirksam, wenn ein JCR-Knoten hinzugefügt oder auf einen bestimmten JCR-Knoten eingestellt wird.

Zuordnen von JCR-Inhalt, OSGi-Diensten und Konfigurationen

Das nachstehende Dokument bietet eine umfassende Zuordnung von OSGi-Diensten, Konfigurationen und Repository-Inhalten zwischen der alten und der neuen Implementierung.
CUG-Zuordnung seit Einführung von AEM 6.3

Aktualisieren der CUG

Bestehende Installationen, welche die veraltete CUG verwenden

Die alte CUG-Unterstützungsimplementierung ist veraltet und wird aus zukünftigen Versionen entfernt. Es wird empfohlen, bei der Aktualisierung von Versionen vor AEM 6.3 auf die neuen Implementierungen umzustellen.
Bei aktualisierten AEM-Installationen darf nur eine CUG-Implementierung aktiviert sein. Die Kombination der neuen und der veralteten CUG-Unterstützung wurde nicht getestet und verursacht wahrscheinlich ein unerwartetes Verhalten:
  • Kollisionen im Sling Authenticator in Bezug auf Authentifizierungspflichten
  • Verweigerter Lesezugriff, wenn die mit der alten CUG verknüpfte ACL-Einrichtung mit einer neuen CUG-Richtlinie kollidiert

Migrieren vorhandener CUG-Inhalte

Adobe stellt ein Tool für die Migration zur neuen CUG-Implementierung zur Verfügung. Sie müssen die folgenden Schritte ausführen, um es zu verwenden:
  1. Gehen Sie zu, https://<serveraddress>:<serverport>/system/console/cug-migration um auf das Tool zuzugreifen.
  2. Geben Sie den Stammpfad ein, auf den Sie CUGs überprüfen möchten, und klicken Sie auf die Schaltfläche Probelauf durchführen . Dies löst eine Suche am angegebenen Ort nach CUGs aus, die konvertiert werden können.
  3. Klicken Sie nach der Prüfung der Ergebnisse auf die Schaltfläche Migration durchführen , um zur neuen Implementierung zu migrieren.
If you run into issues, it is possible to set up a specific logger at DEBUG level on com.day.cq.auth.impl.cug to get the output of the migration tool. Weitere Informationen dazu finden Sie unter Protokollierung .