AEM 6.4 hat das Ende der erweiterten Unterstützung erreicht und diese Dokumentation wird nicht mehr aktualisiert. Weitere Informationen finden Sie in unserer technische Unterstützung. Unterstützte Versionen suchen here.
Seit AEM 6.3 gibt es eine neue Implementierung geschlossener Benutzergruppen , die die Leistungs-, Skalierbarkeits- und Sicherheitsprobleme in 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).
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:
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.
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.
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.
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:
Die folgenden Best Practices sollten bei der Definition des eingeschränkten Lesezugriffs über CUGs berücksichtigt werden:
Entscheiden Sie bewusst, ob Sie die CUG benötigen, um Lesezugriff einzuschränken oder die Authentifizierung zu erzwingen. Falls Sie Letzteres oder beides benötigen, finden Sie im Abschnitt „Best Practices“ Details hinsichtlich der 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 Vertraulichkeit der Daten und der Rollen im Zusammenhang mit dem autorisierten Zugriff zu erhalten.
Modellieren Sie den Repository-Inhalt und CUGs unter Berücksichtigung der allgemeinen Aspekte und Best Practices im Zusammenhang mit der Autorisierung:
Beschränken Sie die für CUG-Richtlinien unterstützten Pfade auf einige Bäume im Repository, um eine optimierte Leistung zu ermöglichen. Lassen Sie CUGs beispielsweise nur unterhalb des Knotens „/content“ zu, wie seit Einführung von AEM 6.3 standardmäßig festgelegt ist.
CUG-Richtlinien sind so konzipiert, dass sie Lesezugriff auf eine kleine Gruppe von Prinzipalen gewähren. Die Notwendigkeit einer großen Anzahl von Prinzipalen kann Probleme beim Inhalt oder Anwendungsdesign hervorheben und sollte überdacht werden.
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.
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.
Das Festlegen der Eigenschaft für den Anmeldepfad ist optional und nur erforderlich, wenn der Baum, der die Authentifizierung erfordert, nicht auf die standardmäßige oder anderweitig geerbte Anmeldeseite zurückgesetzt werden kann. Siehe Auswertung des Anmeldepfads unten.
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.
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.
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:
Unterscheidung zwischen abgelaufenem Passwort und Notwendigkeit einer regelmäßigen Anmeldung als Grund für die Umleitung;
Bei einer regulären Anmeldung wird in der folgenden Reihenfolge getestet, ob ein Anmeldepfad abgerufen werden kann:
com.adobe.granite.auth.requirement.impl.RequirementService
)LoginSelectorHandler
erstellten Definition)LoginSelectorHandler
erstellten Definition)Sobald anhand der oben genannten Aufrufe ein gültiger Anmeldepfad abgerufen wurde, wird die Anforderung des Benutzers an diese Seite weitergeleitet.
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:
Die Registrierung von Anmeldepfaden hängt davon ab, ob zwischen abgelaufenem Passwort und der Notwendigkeit einer regulären Anmeldung als Grund für die Umleitung unterschieden wird.
Testen Sie bei regulärer Anmeldung, ob ein Anmeldepfad in der folgenden Reihenfolge abgerufen werden kann:
LoginPathProvider
(entsprechend der Implementierung des neuen com.adobe.granite.auth.requirement.impl.RequirementService
)LoginSelectorHandler
erstellten Definition)LoginSelectorHandler
erstellten Definition)Sobald anhand der oben genannten Aufrufe ein gültiger Anmeldepfad abgerufen wurde, wird die Anforderung des Benutzers an diese Seite weitergeleitet.
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.
Die Auswertung 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 Methoden zur Bestimmung des Anmeldepfads ausgewertet.
Bei der Definition von Authentifizierungsanforderungen sollten die folgenden Best Practices berücksichtigt werden:
Vermeiden Sie Verschachtelung von Authentifizierungsanforderungen: Die Platzierung einer einzelnen Authentifizierungspflicht-Markierung am Anfang eines Baums sollte ausreichend sein und wird an die gesamte vom Zielknoten definierte Unterstruktur vererbt. Zusätzliche Authentifizierungsanforderungen in diesem Baum sollten als redundant betrachtet werden und können bei der Bewertung der Authentifizierungspflicht in Apache Sling zu Leistungsproblemen führen. Durch die Trennung von Autorisierungs- und Authentifizierungsbereichen ist es möglich, den Lesezugriff durch CUG oder andere Richtlinien zu beschränken und gleichzeitig die Authentifizierung für den gesamten Baum durchzusetzen.
Modellieren Sie Repository-Inhalte so, dass Authentifizierungsanforderungen für die gesamte Baumstruktur gelten, ohne verschachtelte Unterbäume erneut von der Anforderung ausschließen zu müssen.
Zur Vermeidung genauer Angaben und der darauf folgenden Registrierung redundanter Anmeldepfade:
LoginSelectorHandler
verknüpft sind.Die Oak-Dokumentation beschreibt, wie die neuen CUG-Richtlinien im Repository-Content dargestellt werden. Weitere Informationen finden Sie unter diese Seite.
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)
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.
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();
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");
}
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.
Bitte beachten Sie den Unterschied zwischen getEffectivePolicies
und das nachfolgende Codebeispiel, das die Hierarchie führt, um zu ermitteln, ob ein bestimmter Pfad bereits Teil einer vorhandenen CUG 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);
}
}
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);
}
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.
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.
Die Änderungen an einem bestimmten Zielknoten, die oben erwähnt werden, werden nur dann auf dem Apache Sling Authenticator angezeigt, wenn die RequirementHandler
wurde konfiguriert und das Ziel ist in den Baumstrukturen enthalten, die von den unterstützten Pfaden definiert werden (siehe Abschnitt Konfigurationsoptionen).
Weitere Informationen finden Sie unter [Zuweisen von Mixin-Knotentypen](https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.10.3 Assigning Mixin Node Types) und [Hinzufügen von Knoten und Festlegen von Eigenschaften](https://docs.adobe.com/docs/de-DE/spec/jcr/2.0/10_Writing.html#10.4 Hinzufügen von Knoten und Festlegen von Eigenschaften).
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();
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();
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");
}
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();
}
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();
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.
In diesem Beispiel wurde die optionale Eigenschaft des Anmeldepfads nicht festgelegt. Folglich wurde kein zweiter Eintrag beim Authentifizierer registriert.
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.
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.
Es wird empfohlen, den Vererbungsmechanismus sowohl für Authentifizierungspflichten als auch für den Anmeldepfad zu verwenden und die Erstellung verschachtelter Authentifizierungspflichten zu vermeiden.
Weitere Informationen finden Sie in Prüfung und Vererbung der Authentifizierungspflicht, Prüfung des Anmeldepfads und Best Practices.
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();
}
}
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.
Authentifizierung erforderlich | Anmeldepfad | Eingeschränkter Lesezugriff | Erwarteter Effekt |
---|---|---|---|
Ja | Ja | Ja | Ein bestimmter Benutzer kann den mit der CUG-Richtlinie markierten Teilbaum nur anzeigen, wenn die effektive Berechtigungsprüfung den Zugriff gewährt. Ein nicht authentifizierter Benutzer wird zur angegebenen Anmeldeseite weitergeleitet. |
Ja | Nein | Ja | Ein bestimmter Benutzer kann den mit der CUG-Richtlinie markierten Teilbaum nur anzeigen, wenn die effektive Berechtigungsprüfung den Zugriff gewährt. Ein nicht authentifizierter Benutzer wird an eine übernommene Standardanmeldeseite umgeleitet. |
Ja | Ja | Nein | Ein nicht authentifizierter Benutzer wird an die angegebene Anmeldeseite 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 gibt keine dedizierte CUG, die den Lesezugriff einschränkt. |
Ja | Nein | Nein | Ein nicht authentifizierter Benutzer wird an eine übernommene Standardanmeldeseite umgeleitet. Ob die mit der Authentifizierungspflicht markierte Baumstruktur angezeigt werden kann, hängt von den effektiven Berechtigungen der einzelnen Elemente in dieser Unterstruktur ab. Es gibt keine dedizierte CUG, die den Lesezugriff einschränkt. |
Nein | Nein | Ja | Ein bestimmter authentifizierter oder nicht authentifizierter Benutzer kann den mit der CUG-Richtlinie markierten Teilbaum nur anzeigen, wenn die effektive Berechtigungsprüfung den Zugriff gewährt. 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. Wird eine JCR-Eigenschaft mit diesem Namen ohne den definierenden Mixin-Typ angegeben, so hat dies keine Auswirkungen und der entsprechende Handler ignoriert die Eigenschaft.
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.
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.
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.
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
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
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration
Bezeichnung | Apache Jackrabbit Oak CUG Configuration |
Beschreibung | Autorisierungskonfiguration zum Einrichten und Prüfen von CUG-Berechtigungen. |
Konfigurationseigenschaften |
Siehe auch Konfigurationsoptionen unten. |
Konfigurationsrichtlinie | ConfigurationPolicy.REQUIRE |
Verweise | CugExclude (ReferenceCardinality.OPTIONAL_UNARY) |
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
Bezeichnung | Apache Jackrabbit Oak CUG Exclude List |
Beschreibung | Ermöglicht den Ausschluss von Prinzipalen mit den konfigurierten Namen von der CUG-Prüfung. |
Konfigurationseigenschaften |
Siehe auch den Abschnitt „Konfigurationsoptionen“ unten. |
Konfigurationsrichtlinie | ConfigurationPolicy.REQUIRE |
Verweise | nicht vorhanden |
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 verfügbaren Konfigurationsoptionen, die mit dem CUG-Autorisierungsmodul verbunden sind, sind im Abschnitt Dokumentation zu Apache Oak.
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.
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.
Aufgrund der obligatorischen Konfigurationsoption mit dem RequirementHandler sind die authentifizierungsbezogenen Teile nur aktiv, wenn die Funktion durch Angabe einer Reihe unterstützter Pfade aktiviert wurde. Bei einer standardmäßigen AEM-Installation ist die Funktion im Autorenausführungsmodus deaktiviert und im Veröffentlichungsausführungsmodus für /content aktiviert.
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
com.adobe.granite.auth.requirement.impl.RequirementService
Bezeichnung | - |
Beschreibung | Dedizierter OSGi-Dienst für Authentifizierungsanforderungen, der einen Beobachter für Inhaltsänderungen registriert, die sich auf die Authentifizierungspflicht auswirken (über den Mixin-Typ granite:AuthenticationRequirement ), und Anmeldepfade werden für LoginSelectorHandler verfügbar gemacht. |
Konfigurationseigenschaften | - |
Konfigurationsrichtlinie | ConfigurationPolicy.OPTIONAL |
Verweise |
|
com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
Bezeichnung | Adobe Granite Authentication Requirement and Login Path Handler |
---|---|
Beschreibung | RequirementHandler -Implementierung, die die Authentifizierungsanforderungen für Apache Sling und den entsprechenden Ausschluss für die zugehörigen Anmeldepfade aktualisiert. |
Konfigurationseigenschaften | supportedPaths |
Konfigurationsrichtlinie | ConfigurationPolicy.REQUIRE |
Verweise | nicht vorhanden |
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"
Eigenschaft | Typ | Standardwert | Beschreibung |
Bezeichnung = Unterstützte Pfade Name = „supportedPaths“ |
Set<String> | - | Pfade, in denen Authentifizierungspflichten von diesem Handler eingehalten werden. Legen Sie diese Konfiguration nicht fest, wenn Sie den Mixin-Typ granite:AuthenticationRequirement Knoten hinzufügen möchten, ohne dass sie erzwungen werden (beispielsweise auf Autoreninstanzen). Wenn nicht vorhanden, ist die Funktion deaktiviert. |
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:
Apache Jackrabbit Oak CUG Configuration | Erklärung |
---|---|
Unterstützte Pfade: /content |
Die Zugriffssteuerungsverwaltung für „CUGpolicies“ ist aktiviert. |
CUG-Prüfung aktiviert: FALSE | Die Berechtigungsprüfung ist deaktiviert. CUG-Richtlinien sind nicht wirksam. |
Ranking | 200 |
Keine Konfiguration für Apache Jackrabbit Oak CUG Exclude List und Adobe Granite-Authentifizierungspflicht und Anmeldungspfad-Handler ist in Standard-Authoring-Instanzen vorhanden.
Apache Jackrabbit Oak CUG Configuration | Erklärung |
---|---|
Unterstützte Pfade: /content |
Die Zugriffssteuerungsverwaltung für CUG-Richtlinien wird in den konfigurierten Pfaden aktiviert. |
CUG-Prüfung aktiviert: TRUE | Die Berechtigungsprüfung wird in den konfigurierten Pfaden aktiviert. CUG-Richtlinien werden wirksam bei Session.save() . |
Ranking | 200 |
Apache Jackrabbit Oak CUG Exclude List | Erklärung |
---|---|
Prinzipalnamen: Admins | Schließt den Administratorprinzipal aus der CUG-Prüfung aus. |
Adobe Granite Authentication Requirement and Login Path Handler | Erklärung |
---|---|
Unterstützte Pfade: /content |
Authentifizierungspflichten, die im Repository mithilfe des Mixin-Typs granite:AuthenticationRequired definiert wurden, werden in /content bei Session.save() wirksam. Sling Authenticator wird aktualisiert. Das Hinzufügen des Mixin-Typs außerhalb der unterstützten Pfade wird ignoriert. |
Die neue Implementierung kann vollständig deaktiviert werden, wenn eine bestimmte Installation keine CUGs nutzt oder andere Authentifizierungs- und Autorisierungsmöglichkeiten verwendet.
Lesen Sie die CUG-Pluggabelbarkeit Dokumentation für Details zum Entfernen des CUG-Autorisierungsmodells aus der Composite-Autorisierungseinrichtung.
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 nicht dazu führt, dass die Registrierung des Mixin-Typs aufgehoben wird, der weiterhin für Knoten gilt, ohne wirksam zu werden.
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.
Der Importmechanismus von Apache Jackrabbit FileVault wurde angepasst, um mit Zugriffssteuerungsrichtlinien des Typs PrincipalSetPolicy
umgehen zu können.
Siehe oben Apache Jackrabbit FileVault Abschnitt.
Das Replikationsmodul wurde geringfügig angepasst, um die CUG-Richtlinien zwischen verschiedenen AEM zu replizieren:
DurboImportConfiguration.isImportAcl()
wird wörtlich interpretiert und betrifft nur Zugriffssteuerungsrichtlinien, die javax.jcr.security.AccessControlList
implementieren.
DurboImportTransformer
respektiert nur diese Konfiguration für echte ACLs.
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. 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.
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.
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.
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
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.
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.
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.
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.
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.
Die Unterschiede in Bezug auf die Authentifizierung werden im Folgenden beschrieben.
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.
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.
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.
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.
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.
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
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:
Adobe bietet ein Tool für die Migration zur neuen CUG-Implementierung. Führen Sie die folgenden Schritte aus, um sie zu verwenden:
https://<serveraddress>:<serverport>/system/console/cug-migration
, um auf das Tool zuzugreifen.Bei Problemen können Sie eine bestimmte Protokollfunktion auf DEBUG-Ebene unter com.day.cq.auth.impl.cug
einrichten, um die Ausgabe des Migrations-Tools abzurufen. Weitere Informationen dazu finden Sie unter Protokollierung.