Gesloten gebruikersgroepen in AEM closed-user-groups-in-aem

Inleiding introduction

Sinds AEM 6.3, is er een nieuwe gesloten implementatie van de Groep van de Gebruiker bedoeld om de prestaties, scalability en veiligheidskwesties te behandelen die met de bestaande implementatie worden voorgesteld.

Het doel van de nieuwe implementatie is om waar nodig bestaande functionaliteit te bestrijken en tegelijkertijd problemen en ontwerpbeperkingen van oudere versies aan te pakken. Het resultaat is een nieuw ontwerp van CUG met de volgende kenmerken:

De nieuwe implementatie van de aangepaste gebruikersgroep the-new-custom-user-group-implementation

Een CUG zoals deze in de context van AEM bekend is, bestaat uit de volgende stappen:

De nieuwe implementatie is ontworpen om een lijn te trekken tussen de authenticatie en de autorisatieonderdelen. Met ingang van AEM 6.3 is het mogelijk leestoegang te beperken zonder expliciet een verificatievereiste toe te voegen. Bijvoorbeeld, als een bepaalde instantie volledig authentificatie vereist of een bepaalde boom verblijft reeds in een subboom die authentificatie reeds vereist.

Eveneens, kan een bepaalde boom met een authentificatievereiste worden gemerkt zonder de efficiënte toestemmingsopstelling te veranderen. De combinaties en resultaten worden vermeld in de Het combineren van het Beleid van de KUG en de Vereisten van de Authentificatie sectie.

Overzicht overview

Autorisatie: Leestoegang beperken authorization-restricting-read-access

De belangrijkste eigenschap van een CUG beperkt leestoegang op een bepaalde boom in de inhoudsbewaarplaats voor iedereen behalve geselecteerde hoofden. In plaats van het manipuleren van de standaardtoegangsbeheerinhoud op de vlucht neemt de nieuwe implementatie een verschillende benadering door een specifiek type van toegangsbeheerbeleid te bepalen dat een KUG vertegenwoordigt.

Toegangscontrolebeleid voor CUG access-control-policy-for-cug

Dit nieuwe type beleid heeft de volgende kenmerken:

De implementatie van PrincipalSetPolicy die wordt gebruikt om CUGs te vertegenwoordigen bepaalt daarnaast:

Dit beleid van CUG wordt opgesteld aan een AEM instantie door een afzonderlijke vergunningsmodule genoemd oak-vergunning-insect. Deze module komt met zijn eigen beheer van toegangsbeheer en toestemmingsevaluatie. Met andere woorden, de standaard AEM installatie verzendt een configuratie van de opslagplaats voor eik-inhoud die meerdere machtigingsmechanismen combineert. Zie voor meer informatie deze pagina op de Apache Oak-documentatie.

In deze samengestelde opstelling vervangt een nieuwe KUG niet de bestaande inhoud van het toegangsbeheer in bijlage aan de doelknoop, maar wordt ontworpen om een aanvulling te zijn die ook later kan worden verwijderd zonder het originele toegangsbeheer te beïnvloeden, dat door gebrek in AEM een toegangsbeheerlijst zou zijn.

In tegenstelling tot de vorige implementatie worden het nieuwe beleid van de GG altijd erkend en behandeld als inhoud van de toegangscontrole. Dit houdt in dat ze worden gemaakt en bewerkt met de API voor toegangsbeheer van de JCR. Zie voor meer informatie de CUG-beleid beheren sectie.

Evaluatie van machtigingen voor CUG-beleid permission-evaluation-of-cug-policies

Naast een specifiek toegangsbeheerbeheer voor CUGs, staat het nieuwe vergunningsmodel toe om toestemmingsevaluatie voor zijn beleid voorwaardelijk toe te laten. Dit staat aan opstelling toe het beleid van CUG in een het opvoeren milieu, en laat slechts evaluatie van de efficiënte toestemmingen toe zodra herhaald aan het productiemilieu.

De evaluatie van de toestemming voor het beleid van de CUG en de interactie met het gebrek of om het even welk extra vergunningsmodel volgt het patroon dat voor veelvoudige vergunningsmechanismen in Apache Jackrabbit Oak wordt ontworpen: een bepaalde reeks toestemmingen wordt verleend als en slechts als alle modellen toegang verlenen. Zie deze pagina voor meer informatie .

De volgende kenmerken zijn voor de toestemmingsevaluatie verbonden aan het vergunningsmodel van toepassing dat wordt ontworpen om het beleid van de CUG te behandelen en te evalueren:

Het effect van één enkel beleid van CUG op toestemmingsevaluatie kan als volgt worden samengevat:

Best practices voor best-practices

Bij het definiëren van beperkte leestoegang via CUG's moet rekening worden gehouden met de volgende aanbevolen procedures:

Verificatie: Bepaling van de Auth-eis authentication-defining-the-auth-requirement

De authentificatie verwante delen van de eigenschap van CUG staan toe om bomen te merken die authentificatie vereisen en naar keuze een specifieke login pagina specificeren. In overeenstemming met de vorige versie staat de nieuwe implementatie toe om bomen te markeren die authentificatie in de inhoudsbewaarplaats vereisen en synchronisatie met voorwaardelijk toelaten Sling org.apache.sling.api.auth.Authenticatorverantwoordelijk voor uiteindelijk het handhaven van het vereiste en het opnieuw richten aan een login middel.

Deze vereisten worden geregistreerd met de Authenticator door middel van de dienst OSGi die verstrekt sling.auth.requirements registration, eigenschap. Deze eigenschappen worden dan gebruikt om de authentificatievereisten dynamisch uit te breiden. Voor meer informatie raadpleegt u de Verkoopdocumentatie.

De verificatievereiste definiëren met een specifiek mixertype defining-the-authentication-requirement-with-a-dedicated-mixin-type

Om veiligheidsredenen vervangt de nieuwe implementatie het gebruik van een resterende JCR-eigenschap door een speciaal mixintype dat wordt aangeroepen granite:AuthenticationRequired, die één facultatieve bezit van type STRING voor de login weg bepaalt granite:loginPath. Alleen inhoudswijzigingen met betrekking tot dit mixintype leiden tot het bijwerken van de vereisten die zijn geregistreerd bij Apache Sling Authenticator. De wijzigingen worden bijgehouden bij het aanhouden van eventuele tijdelijke wijzigingen en vereisen dus een javax.jcr.Session.save() oproep om effectief te worden.

Hetzelfde geldt voor granite:loginPath eigenschap. Er wordt alleen aan voldaan als het wordt gedefinieerd door het aan de auteisen gerelateerde mengtype. Het toevoegen van een restbezit met deze zeer naam bij een ongestructureerde knoop JCR zal niet het gewenste effect tonen en het bezit zal door de manager verantwoordelijk voor het bijwerken van de registratie worden genegeerd OSGi.

Registreren van de Vereiste van de Authentificatie en Login Weg met de Verschuivende Authenticator registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

Aangezien dit type van authentificatievereiste naar verwachting tot bepaalde looppaswijzen en tot een kleine ondergroep van bomen binnen de inhoudsbewaarplaats zal worden beperkt, is het volgen van het vereiste mixintype en de login wegeigenschappen voorwaardelijk en verbindend aan een overeenkomstige configuratie die de gesteunde wegen bepaalt (zie de Opties van de Configuratie hieronder). Bijgevolg zullen alleen wijzigingen binnen het bereik van deze ondersteunde paden een update van de OSGi-registratie activeren, elders worden zowel het mixintype als de eigenschap genegeerd.

De standaard AEM opstelling maakt nu gebruik van deze configuratie door toe te staan om de mixin op de wijze van de auteurslooppas te plaatsen maar het slechts van kracht te hebben op replicatie aan te publiceren instantie. Zie deze pagina voor details hoe Sling de authentificatievereiste afdwingt.

Het toevoegen van granite:AuthenticationRequired het mixintype binnen de gevormde gesteunde wegen zal de registratie OSGi van de verantwoordelijke manager veroorzaken om worden bijgewerkt die een nieuwe, extra ingang met bevat sling.auth.requirements eigenschap. Als een bepaalde authenticatievoorwaarde de facultatieve granite:loginPath eigenschap, wordt de waarde aanvullend geregistreerd bij de authenticator met een '-' voorvoegsel om te worden uitgesloten van de verificatievereiste.

Evaluatie en overerving van de authenticatievereiste evaluation-and-inheritance-of-the-authentication-requirement

Van Apache Sling-verificatievereisten wordt verwacht dat deze worden overgeërfd via de pagina- of knooppunthiërarchie. De details zelf van de erfenis en de evaluatie van de authentificatievereisten zoals orde en belangrijkheid worden beschouwd als implementatiedetails en zullen niet in dit artikel worden gedocumenteerd.

Evaluatie van aanmeldingspad evaluation-of-login-path

De evaluatie van de login weg en redirect aan het overeenkomstige middel op authentificatie is momenteel een implementatiedetails van de Behandelaar van de Authentificatie van de Selecteur van de Registratie van de Adobe Granite ( com.day.cq.auth.impl.LoginSelectorHandler), wat een Apache Sling AuthenticationHandler is die standaard met AEM is geconfigureerd.

Bij aanroepen AuthenticationHandler.requestCredentials deze manager doet een poging om de kaartlogin pagina te bepalen waaraan de gebruiker opnieuw zal worden gericht. Dit omvat de volgende stappen:

Het doel van deze documentatie is de evaluatie van het aanmeldingspad zoals dit door de interne LoginPathProvider interface. De implementatie die sinds AEM 6.3 wordt verzonden, functioneert als volgt:

De LoginPathProvider zoals geïmplementeerd door de nieuwe ondersteuning voor auteisen in Granite stelt aanmeldingspaden beschikbaar zoals gedefinieerd door de granite:loginPath eigenschappen, die op hun beurt worden gedefinieerd door het hierboven beschreven mixintype. De afbeelding van de middelweg die de login weg en de bezitswaarde zelf houdt wordt gehouden in geheugen en zal worden geëvalueerd om een geschikte login weg voor andere knopen in de hiërarchie te vinden.

Best practices voor best-practices-1

Bij het bepalen van de verificatievereisten moet rekening worden gehouden met de volgende beste praktijken:

Vertegenwoordiging in de opslagplaats representation-in-the-repository

Beleidsvertegenwoordiging CUG in de opslagplaats cug-policy-representation-in-the-repository

De documentatie van het Eak behandelt hoe het nieuwe beleid van CUG in de bewaarplaats inhoud wordt weerspiegeld. Voor meer informatie raadpleegt u deze pagina.

Verificatievereiste in de opslagplaats authentication-requirement-in-the-repository

De behoefte aan een afzonderlijk authentificatievereiste wordt weerspiegeld in de inhoud van de bewaarplaats met een specifiek mixinknooptype dat bij de doelknoop wordt geplaatst. Het mixintype bepaalt een facultatieve bezit om een specifieke login pagina voor de boom te specificeren die door de doelknoop wordt bepaald.

De pagina die aan het aanmeldingspad is gekoppeld, kan zich binnen of buiten die structuur bevinden. Het zal van de authentificatievereiste worden uitgesloten.

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

Het beheren van het Beleid van de CUG en de Vereiste van de Authentificatie managing-cug-policies-and-authentication-requirement

CUG-beleid beheren managing-cug-policies

Het nieuwe type toegangsbeheerbeleid om gelezen toegang voor een KUG te beperken wordt beheerd gebruikend JCR toegangsbeheer API en volgt de mechanismen die met worden beschreven JCR 2.0-specificatie.

Een nieuw CUG-beleid instellen set-a-new-cug-policy

Code om een nieuw beleid van de GECG op een knoop toe te passen die geen KUG had eerder geplaatst. Houd er rekening mee dat getApplicablePolicies alleen nieuwe beleidsvormen terugsturen die nog niet eerder zijn vastgesteld. Uiteindelijk moet het beleid worden teruggeschreven en moeten de veranderingen worden voortgezet.

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();

Een bestaand CUG-beleid bewerken edit-an-existing-cug-policy

De volgende stappen zijn nodig om een bestaand beleid van CUG uit te geven. Houd er rekening mee dat het gewijzigde beleid moet worden teruggeschreven en dat de wijzigingen moeten worden voortgezet met 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");
}

Effectief CUG-beleid ophalen retrieve-effective-cug-policies

Het beheer van het toegangsbeheer JCR bepaalt een beste inspanningsmethode om het beleid terug te winnen dat op een bepaalde weg van kracht wordt. Wegens het feit dat de evaluatie van het beleid van CUG voorwaardelijk is en van de overeenkomstige configuratie afhangt om worden toegelaten, roepend getEffectivePolicies is een geschikte manier om te verifiëren of een bepaald beleid van de CUG in een bepaalde installatie van kracht wordt.

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);
     }
}

Overerfd CUG-beleid ophalen retrieve-inherited-cug-policies

Alle geneste CUG's zoeken die op een bepaald pad zijn gedefinieerd, ongeacht of ze van kracht worden of niet. Zie voor meer informatie de Configuratieopties sectie.

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);
}

Het Beleid van de KUG door Pincipal beheren managing-cug-policies-by-pincipal

De extensies die worden gedefinieerd door JackrabbitAccessControlManager die toestaan om toegangsbeheerbeleid door hoofd uit te geven wordt niet uitgevoerd met het beheer van de toegangscontrole van de CUG, aangezien een beleid van de CUG altijd alle hoofden beïnvloedt: die bij de PrincipalSetPolicy worden verleend lees toegang terwijl alle andere hoofden worden verhinderd om inhoud in de boom te lezen die door de doelknoop wordt bepaald.

De bijbehorende methoden retourneren altijd een lege beleidsarray, maar genereren geen uitzonderingen.

De verificatievereiste beheren managing-the-authentication-requirement

Het creëren, de wijziging of de verwijdering van een nieuwe authentificatievereisten worden bereikt door het efficiënte knooptype van de doelknoop te veranderen. De eigenschap voor het optionele aanmeldingspad kan vervolgens worden geschreven met de gewone JCR API.

Nieuwe auteisen toevoegen adding-a-new-auth-requirement

De stappen om een nieuw authentificatievereiste tot stand te brengen zijn hieronder gedetailleerd. Merk op dat het vereiste alleen bij de Apache Sling Authenticator wordt geregistreerd als de RequirementHandler is gevormd voor de boom die de doelknoop bevatten.

Node targetNode = [...]

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

Voeg een Nieuwe Vereiste van de Auth met Login Weg toe add-a-new-auth-requirement-with-login-path

Stappen om een nieuw authentificatievereiste met inbegrip van een login weg tot stand te brengen. Merk op dat het vereiste en de uitsluiting voor de login weg slechts met de Authenticator van de Apache Sling zullen worden geregistreerd als RequirementHandler is veroorzaakt voor de boom die de doelknoop bevat.

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

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

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

Een bestaand aanmeldingspad wijzigen modify-an-existing-login-path

De stappen om een bestaand login weg te veranderen zijn hieronder gedetailleerd. De wijziging wordt alleen geregistreerd bij de Apache Sling Authenticator als de RequirementHandler is gevormd voor de boom die de doelknoop bevatten. De vorige waarde van het aanmeldingspad wordt uit de registratie verwijderd. Deze wijziging heeft geen invloed op de vereiste auth die aan het doelknooppunt is gekoppeld.

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

Een bestaand aanmeldingspad verwijderen remove-an-existing-login-path

Stappen om een bestaand aanmeldingspad te verwijderen. De invoer van het aanmeldingspad wordt alleen niet geregistreerd bij de Apache Sling Authenticator als de RequirementHandler is gevormd voor de boom die de doelknoop bevatten. De auth-vereiste die aan het doelknooppunt is gekoppeld, wordt niet beïnvloed.

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

U kunt ook de onderstaande methode gebruiken om hetzelfde doel te bereiken:

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();
}

Een Auth-vereiste verwijderen remove-an-auth-requirement

Stappen om een bestaand authentificatievereiste te verwijderen. De vereiste wordt alleen niet geregistreerd bij de Apache Sling Authenticator als de RequirementHandler is veroorzaakt voor de boom die de doelknoop bevat.

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

session.save();

Effectieve Auth Requirements ophalen retrieve-effective-auth-requirements

Er is geen speciale openbare API om alle effectieve verificatievereisten te lezen zoals die zijn geregistreerd bij de Apache Sling Authenticator. Nochtans, wordt de lijst blootgesteld in de systeemconsole bij https://<serveraddress>:<serverport>/system/console/slingauth onder "Configuratie van verificatievereisten".

In de volgende afbeelding ziet u de verificatievereisten van een AEM-publicatie-instantie met demo-inhoud. Het gemarkeerde pad van de communitypagina toont hoe een vereiste die wordt toegevoegd door de implementatie die in dit document wordt beschreven, wordt weerspiegeld in de Apache Sling Authenticator.

Het effectieve aanmeldingspad ophalen retrieve-the-effective-login-path

Er is momenteel geen openbare API om de login weg terug te winnen die op anoniem toegang tot van een middel zal ingaan dat authentificatie vereist. Zie sectieEvaluatie van Login Weg voor implementatiedetails op hoe de login weg wordt teruggewonnen.

Naast de aanmeldingspaden die met deze functie zijn gedefinieerd, zijn er echter andere manieren om het omleiden naar de aanmelding op te geven. Hiermee moet rekening worden gehouden bij het ontwerpen van het inhoudsmodel en de verificatievereisten van een bepaalde AEM.

De overerfde Auth-vereiste ophalen retrieve-the-inherited-auth-requirement

Net als bij het aanmeldingspad is er geen openbare API om de overgenomen verificatievereisten op te halen die in de inhoud zijn gedefinieerd. Het volgende voorbeeld laat zien hoe u alle verificatievereisten kunt weergeven die zijn gedefinieerd met een bepaalde hiërarchie, ongeacht of deze van kracht worden of niet. Zie voor meer informatie Configuratieopties.

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();
     }
}

Het combineren van het Beleid van de KUG en de Vereisten van de Authentificatie combining-cug-policies-and-the-authentication-requirement

De volgende lijst maakt een lijst van de geldige combinaties beleid van de CUG en het authentificatievereiste in een AEM instantie die beide modules heeft die door configuratie worden toegelaten.

OSGi-componenten en -configuratie osgi-components-and-configuration

Deze secties verstrekken een overzicht aan de componenten OSGi en de individuele configuratieopties die met de nieuwe implementatie van de CUG worden geïntroduceerd.

Zie ook de de afbeeldingsdocumentatie van de KUG voor een uitvoerige afbeelding van de configuratieopties tussen oude en nieuwe implementatie.

Autorisatie: Instellen en configureren authorization-setup-and-configuration

De nieuwe, vergunningsgerelateerde onderdelen zijn opgenomen in de Oak CUG Authorization bundel ( org.apache.jackrabbit.oak-authorization-cug), dat onderdeel is van de AEM standaardinstallatie. De bundel bepaalt een gescheiden vergunningsmodel dat wordt opgesteld als extra manier om gelezen toegang te beheren.

CUG-autorisatie instellen setting-up-cug-authorization

De CUG-autorisatie instellen wordt gedetailleerd beschreven in het gedeelte relevante Apache-documentatie. Door gebrek, AEM heeft de vergunning van de GECG die in alle looppaswijzen wordt opgesteld. De stapsgewijze instructies kunnen ook worden gebruikt om de CUG-autorisatie uit te schakelen in die installaties waarvoor een andere instelling van de autorisatie vereist is.

Filter Referrer configureren configuring-the-referrer-filter

U moet ook de Filter Verschuivingsverwijzing met alle hostnamen die kunnen worden gebruikt om toegang te krijgen tot AEM; bijvoorbeeld via CDN, Load Balancer en andere.

Als het verwijzingsfilter niet wordt gevormd, dan worden de fouten, gelijkend op het volgende, gezien wanneer een gebruiker probeert om aan te melden bij een plaats van de CUG:

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

Kenmerken van OSGi-componenten characteristics-of-osgi-components

De volgende twee componenten OSGi zijn geïntroduceerd om authentificatievereisten te bepalen en specifieke login wegen te specificeren:

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

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

Configuratieopties configuration-options

De belangrijkste configuratieopties zijn:

De beschikbare configuratieopties verbonden aan de CUG-vergunningsmodule zijn vermeld en meer gedetailleerd beschreven bij Documentatie voor Apache Oak.

Exclusief stafmedewerkers van de CUG-evaluatie excluding-principals-from-cug-evaluation

Van de vorige uitvoering zijn individuele beginselen van de CUG-evaluatie vrijgesteld. De nieuwe vergunning van de GECG behandelt dit met een specifieke interface genoemd CugExclude. Apache Jackrabbit Oak 1.4 schepen met een standaardimplementatie die een vaste reeks principes evenals een uitgebreide implementatie uitsluit die individuele belangrijkste namen toestaat te vormen. De laatste is geconfigureerd in AEM publicatieinstanties.

Het gebrek sinds AEM 6.3 verhindert de volgende hoofden door beleid van de CG worden beïnvloed:

Zie de tabel in het dialoogvenster Standaardconfiguratie sinds AEM 6.3 hieronder.

De uitsluiting van de groep 'beheerders' kan worden gewijzigd of uitgebreid in de systeemconsole in de configuratiesectie van Apache Jackrabbit Oak CUG Exclusive List.

Alternatief, is het mogelijk om een douaneimplementatie van de interface te verstrekken en op te stellen CugExclude om de reeks uitgesloten hoofden in het geval van speciale behoeften aan te passen. Zie de documentatie op CUG-pluggable voor details en een voorbeeldimplementatie.

Verificatie: Instellen en configureren authentication-setup-and-configuration

De nieuwe, aan verificatie gerelateerde onderdelen zijn opgenomen in de Adobe graniet-verificatiehandler bundel ( com.adobe.granite.auth.authhandler versie 5.6.48). Deze bundel maakt deel uit van de AEM standaardinstallatie.

Om de vervanging van het authentificatievereiste voor de verouderde steun van de GN te plaatsen, moeten sommige componenten OSGi aanwezig en actief in een bepaalde AEM installatie zijn. Zie voor meer informatie Kenmerken van OSGi-componenten hieronder.

Kenmerken van OSGi-componenten

De volgende 2 componenten OSGi zijn geïntroduceerd om authentificatievereisten te bepalen en specifieke login wegen te specificeren:

com.adobe.granite.auth.requirements.impl.RequirementService

com.adobe.granite.auth.requirements.impl.DefaultRequirementHandler

Configuratieopties configuration-options-1

De authentificatiegerelateerde delen van CUG herschrijven slechts met één enkele configuratieoptie verbonden aan de Vereiste van de Authentificatie van de Adobe Granite en de Bediener van de Weg van de Login komen:

"De Vereiste van de authentificatie en de Bediener van de Weg van de Login"

Standaardconfiguratie sinds AEM 6.3 default-configuration-since-aem

De nieuwe installaties van AEM zullen door gebrek de nieuwe implementaties zowel voor de vergunning als authentificatiegerelateerde delen van de eigenschap van CUG gebruiken. De oude implementatie "Adobe Granite Closed User Group (CUG) Support" is vervangen en wordt standaard uitgeschakeld in alle AEM installaties. De nieuwe implementaties zullen in plaats daarvan als volgt worden toegelaten:

Auteursinstanties author-instances

Exemplaren publiceren publish-instances

Het onbruikbaar maken van de Vereiste van de Authorificatie en van de Authentificatie van de CUG disabling-cug-authorization-and-authentication-requirement

De nieuwe implementatie kan volledig worden uitgeschakeld als een bepaalde installatie geen gebruik maakt van CUG's of andere middelen gebruikt voor verificatie en autorisatie.

CUG-autorisatie uitschakelen disable-cug-authorization

Raadpleeg de CUG-pluggable documentatie voor details over hoe te om het de vergunningsmodel van de GIDS van de samengestelde vergunningsopstelling te verwijderen.

De verificatievereiste uitschakelen disable-the-authentication-requirement

Om steun voor het authentificatievereiste zoals voorzien door uit te schakelen granite.auth.authhandler de module het volstaat om de configuratie te verwijderen verbonden aan Adobe Granite-verificatie vereist en Aanmeldingspad-handler.

Interactie met andere modules interaction-with-other-modules

Apache Jackrabbit API apache-jackrabbit-api

Om het nieuwe type toegangsbeheerbeleid te weerspiegelen dat door het de vergunningsmodel van de GG wordt gebruikt, is API die door Apache Jackrabbit wordt bepaald uitgebreid. Sinds versie 2.11.0 van het jackrabbit-api module bepaalt een nieuwe geroepen interface org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy, die zich uitstrekt van javax.jcr.security.AccessControlPolicy.

Apache Jackrabbit FileVault apache-jackrabbit-filevault

Het importmechanisme van Apache Jackrabbit FileVault is aangepast aan het type toegangsbeheerbeleid PrincipalSetPolicy.

Apache Sling Content Distribution apache-sling-content-distribution

Zie bovenstaande Apache Jackrabbit FileVault sectie.

Adobe granietreplicatie adobe-granite-replication

De replicatiemodule is lichtjes aangepast om het beleid van de CUG tussen verschillende AEM instanties te kunnen herhalen:

Er is één beperking van het repliceren van beleid van CUG. Als een bepaald beleid van de KUG wordt verwijderd zonder het overeenkomstige mixinknooppunttype te verwijderen rep:CugMixin, de verwijdering wordt niet weerspiegeld bij replicatie. Dit probleem is opgelost door de mix bij het verwijderen van het beleid altijd te verwijderen. De beperking kan desondanks opduiken als het mixintype handmatig wordt toegevoegd.

Adobe graniet-verificatiehandler adobe-granite-authentication-handler

De verificatiehandler Adobe Granite HTTP Header Authentication Handler meegeleverd bij de com.adobe.granite.auth.authhandler bundel bevat een verwijzing naar de CugSupport interface die door de zelfde module wordt bepaald. Het wordt gebruikt om het "domein"in bepaalde omstandigheden te berekenen, die terug naar het domein vallen dat met de manager wordt gevormd.

Dit is aangepast om de verwijzing naar CugSupport facultatief om maximale achterwaartse verenigbaarheid te verzekeren als een bepaalde opstelling besluit om de verouderde implementatie opnieuw toe te laten. Installaties die gebruikmaken van de implementatie krijgen niet langer het domein dat wordt opgehaald uit de CUG-implementatie, maar geven altijd het domein weer zoals gedefinieerd met Adobe Granite HTTP Header Authentication Handler.

AEM LiveCopy aem-livecopy

Het configureren van CUG's in combinatie met LiveCopy wordt in de opslagplaats vertegenwoordigd door toevoeging van één extra knooppunt en één extra eigenschap, en wel als volgt:

Beide elementen worden gemaakt onder de cq:Page. Met het huidige ontwerp, behandelt MSM slechts knopen en eigenschappen die onder zijn cq:PageContent (jcr:content) node.

CUG-groepen kunnen daarom niet worden geïmplementeerd in Actieve kopieën van blauwdrukken. Plan dit probleem bij het configureren van Live Copy.

Wijzigingen aanbrengen in de nieuwe CUG-implementatie changes-with-the-new-cug-implementation

Het doel van deze sectie is een overzicht te geven van de wijzigingen die in de CUG-functie zijn aangebracht, en een vergelijking te maken tussen de oude en de nieuwe implementatie. Het maakt een lijst van de veranderingen die van invloed zijn op de manier de steun van CUG wordt gevormd en beschrijft hoe en door wie CUGs in de bewaarplaats inhoud wordt beheerd.

Verschillen in de Opstelling en de Configuratie van de KUG diferences-in-cug-setup-and-configuration

De vervangen OSGi-component Ondersteuning voor Adobe Granite Closed User Group (CUG) ( com.day.cq.auth.impl.cug.CugSupportImpl) is vervangen door nieuwe onderdelen om de onderdelen van de vroegere CUG-functionaliteit die betrekking hebben op autorisatie en verificatie afzonderlijk te kunnen verwerken.

Verschillen in het beheren van CUG's in de inhoud van de opslagplaats differences-in-managing-cugs-in-the-repository-content

In de volgende secties worden de verschillen tussen de oude en de nieuwe implementaties vanuit het perspectief van implementatie en veiligheid beschreven. Terwijl de nieuwe implementatie de zelfde functionaliteit probeert te verstrekken, zijn er subtiele veranderingen die belangrijk zijn om te weten wanneer het gebruiken van nieuwe CUG.

Verschillen in de vergunningen diferences-with-regards-to-authorization

De belangrijkste verschillen vanuit het oogpunt van vergunningverlening worden samengevat in de onderstaande lijst:

Specifieke inhoud van het Toegangsbeheer voor CUGs

In de oude implementatie werd het model van de standaardvergunning gebruikt om het beleid van de toegangsbeheerlijst te manipuleren bij publiceren, die om het even welke bestaande ACEs door de opstelling vervangen die door CUG wordt gemachtigd. Dit werd geactiveerd door het schrijven van reguliere, resterende JCR-eigenschappen die tijdens de publicatie werden geïnterpreteerd.

Met de nieuwe implementatie wordt de opstelling van het toegangsbeheer van het standaard vergunningsmodel niet beïnvloed door enige CUG die wordt gecreeerd, wordt gewijzigd of wordt verwijderd. In plaats daarvan wordt een nieuw type beleid aangeroepen PrincipalSetPolicy wordt toegepast als extra inhoud van het toegangsbeheer aan de doelknoop. Dit extra beleid zal als kind van de doelknoop worden gevestigd en zou een sibling van de standaardbeleidsknoop zijn indien aanwezig.

CUG-beleid bewerken in Access Control Management

Deze beweging van resterende eigenschappen JCR aan een specifiek toegangsbeheerbeleid heeft een invloed op de toestemming nodig om het vergunningsdeel van de eigenschap van de GG tot stand te brengen of te wijzigen. Aangezien dit als een wijziging van de inhoud van de toegangscontrole wordt beschouwd, vereist het jcr:readAccessControl en jcr:modifyAccessControl rechten om naar de opslagplaats te worden geschreven. Daarom kunnen alleen inhoudsauteurs die gemachtigd zijn om de inhoud van het toegangsbeheer van een pagina te wijzigen, deze inhoud instellen of wijzigen. Dit staat in schril contrast met de oude implementatie waar de capaciteit om regelmatige eigenschappen te schrijven JCR voldoende was, resulterend in een voorrechtescalatie.

Doelknooppunt gedefinieerd door beleid

Van het beleid van de CUG wordt verwacht om bij de knoop worden gecreeerd JCR die de subboom bepaalt aan beperkte lees toegang te worden onderworpen. Dit is waarschijnlijk een AEM pagina als de CUG wordt verwacht voor de gehele boom.

Merk op dat het plaatsen van het beleid van de GIDS slechts bij jcr:inhoudsknoop die onder een bepaalde pagina wordt gevestigd slechts toegang tot de inhoud van een bepaalde pagina zal beperken maar niet op om het even welke siblings of kindpagina's van kracht zal worden. Dit kan een geldig gebruiksgeval zijn en het is mogelijk om met een bewaargegevensopslagredacteur te bereiken die toestaat om fijnkorrelige inhoud van de toegangsinhoud toe te passen. Nochtans, contrasteert het de vroegere implementatie waar het plaatsen van een cq:cugEnabled bezit op jcr:content knoop intern aan de paginaknooppunt werd opnieuw in kaart gebracht. Deze toewijzing wordt niet meer uitgevoerd.

Evaluatie van machtigingen met CUG-beleid

De beweging van de oude steun van de GIDS aan een extra vergunningsmodel, verandert de manier efficiënte gelezen toestemmingen worden geëvalueerd. Zoals beschreven in het Jackrabbit-documentatie, een bepaalde aangever die de CUGcontent alleen leestoegang wordt verleend als de machtigingsevaluatie van alle modellen die in de Oak-opslagplaats zijn verward leestoegang verleent.

Met andere woorden, voor de evaluatie van de effectieve machtigingen CUGPolicy en de standaardingangen van de toegangscontrole zullen in aanmerking worden genomen en leestoegang op de inhoud van de CG zal slechts worden verleend als het door beide soorten beleid wordt verleend. In een standaard AEM publiceer installatie waar gelezen toegang tot het volledige /content De boom wordt verleend voor iedereen, zal het effect van het beleid van CUG het zelfde als met de oude implementatie zijn.

Evaluatie op aanvraag

Met het machtigingsmodel CUG kunt u het beheer van toegangsbeheer en de evaluatie van machtigingen afzonderlijk inschakelen:

In de nieuwe AEM standaardopstellingsevaluatie van het beleid van de GIDS wordt het slechts toegelaten met "publiceer"looppaswijze. Zie de details op de standaardconfiguratie sinds AEM 6.3 voor meer informatie . Dit kan worden gecontroleerd door het efficiënte beleid voor een bepaalde weg aan het beleid te vergelijken dat in de inhoud wordt opgeslagen. Het efficiënte beleid zal slechts worden getoond in het geval de toestemmingsevaluatie voor CUGs wordt toegelaten.

Zoals hierboven verklaard wordt het beleid van de toegangscontrole van de CUG nu altijd opgeslagen in de inhoud maar de evaluatie van de efficiënte toestemmingen die uit dat beleid voortvloeien zal slechts afdwingen als CUG-evaluatie ingeschakeld is ingeschakeld in de systeemconsole van Apache Jackrabbit Oak CUG Configuration. Deze optie is standaard alleen beschikbaar in de uitvoermodus Publiceren.

Verschillen met betrekking tot verificatie differences-with-regards-to-authentication

De verschillen in authenticatie worden hieronder beschreven.

Specifiek mixintype voor verificatievereiste dedicated-mixin-type-for-authentication-requirement

In de vorige implementatie werden zowel de autorisatie- als de authenticatieaspecten van een CUG geactiveerd door één JCR-eigenschap ( cq:cugEnabled). Wat de authentificatie betreft, resulteerde dit in een bijgewerkte lijst van authentificatievereisten zoals die met de implementatie van de Authenticator van Apache Sling wordt opgeslagen. Met de nieuwe implementatie wordt hetzelfde resultaat bereikt door het doelknooppunt te markeren met een speciaal mixintype ( granite:AuthenticationRequired).

Eigenschap voor uitsluiten van aanmeldingspad property-for-excluding-login-path

Het mixintype definieert een enkele, optionele eigenschap, genaamd granite:loginPath, die in wezen overeenkomt met de cq:cugLoginPage eigenschap. In tegenstelling tot de vorige implementatie zal het login wegbezit slechts worden gerespecteerd als zijn verklarend knooptype de vermelde mixin is. Het toevoegen van een eigenschap met die naam zonder het mixintype in te stellen, heeft geen effect en er wordt noch een nieuwe vereiste, noch een uitsluiting voor het aanmeldingspad gerapporteerd aan de authenticator.

Bevoegdheid voor verificatievereiste privilege-for-authentication-requirement

Voor het toevoegen of verwijderen van een mixintype is het vereist jcr:nodeTypeManagement het verlenen van een voorrecht. Bij de vorige uitvoering jcr:modifyProperties wordt gebruikt om de resterende eigenschap te bewerken.

Wat de granite:loginPath heeft betrekking op hetzelfde recht om de eigenschap toe te voegen, te wijzigen of te verwijderen.

Doelknooppunt gedefinieerd door mixintype target-node-defined-by-mixin-type

Er worden verificatievereisten verwacht die worden gemaakt op het JCR-knooppunt dat de subboomstructuur definieert voor gedwongen aanmelding. Dit zal waarschijnlijk een AEM Pagina zijn voor het geval dat de CUG naar verwachting de volledige boom zal beïnvloeden en UI voor de nieuwe implementatie zal bijgevolg het auto-vereiste mixintype op de paginaknooppunt toevoegen.

Het plaatsen van het beleid van de GIDS slechts bij jcr:inhoudsknoop die onder een bepaalde pagina wordt gevestigd zal slechts toegang tot de inhoud beperken, maar zal niet op de paginaknoop zelf noch op om het even welke kindpagina's van invloed zijn.

Dit kan een geldig scenario zijn en is mogelijk met een bewaargegevensverwerker die toestaat om de mixin bij om het even welk knooppunt te plaatsen. Nochtans, contrasteert het gedrag de vroegere implementatie, waar het plaatsen van een bezit cq:cugEnabled of cq:cugLoginPage op jcr:content intern werd opnieuw in kaart gebracht uiteindelijk aan de paginaknooppunt. Deze toewijzing wordt niet meer uitgevoerd.

Ondersteunde paden configureren configured-supported-paths

Beide granite:AuthenticationRequired mixintype en de eigenschap granite:loginPath worden alleen binnen het bereik dat is gedefinieerd door de set Ondersteunde paden configuratieoptie aanwezig met de Adobe Granite-verificatie vereist en Aanmeldingspad-handler. Als er geen paden zijn opgegeven, is de functie voor de vereiste verificatie geheel uitgeschakeld. In dit geval wordt het mixintype en de eigenschap van kracht wanneer het wordt toegevoegd aan of ingesteld op een bepaald JCR-knooppunt.

Toewijzing van JCR-inhoud, OSGi-services en -configuraties mapping-of-jcr-content-osgi-services-and-configurations

Het document hieronder verstrekt een uitvoerige afbeelding van de diensten OSGi, configuraties en bewaarplaats inhoud tussen de oude en nieuwe implementatie.

CUG-toewijzing sinds AEM 6.3

Bestand ophalen

CUG bijwerken upgrade-cug

Bestaande installaties die de afgekeurde CUG gebruiken existing-installations-using-the-deprecated-cug

De oude implementatie van de CUG-ondersteuning is vervangen en wordt in toekomstige versies verwijderd. Het wordt aanbevolen over te schakelen op de nieuwe implementaties wanneer u een upgrade uitvoert van een lagere versie dan AEM 6.3.

Voor bijgewerkte AEM installatie, is het belangrijk om ervoor te zorgen dat slechts één implementatie van CUG wordt toegelaten. De combinatie van de nieuwe en de oude, verouderde ondersteuning van CUG wordt niet getest en kan ongewenste werking veroorzaken:

Bestaande CUG-inhoud migreren migrating-existing-cug-content

Adobe biedt een hulpmiddel voor het migreren naar de nieuwe CUG-implementatie. Voer de volgende stappen uit om het te gebruiken: