Stängda användargrupper i AEM closed-user-groups-in-aem

Introduktion introduction

Sedan AEM 6.3 finns det en ny implementering av en stängd användargrupp som är avsedd att åtgärda de problem med prestanda, skalbarhet och säkerhet som den befintliga implementeringen innebär.

Målet med den nya implementeringen är att vid behov täcka befintliga funktioner och samtidigt åtgärda problem och designbegränsningar från äldre versioner. Resultatet blir en ny CUG-design med följande egenskaper:

Implementering av ny anpassad användargrupp the-new-custom-user-group-implementation

En CUG som den är känd i AEM består av följande steg:

Den nya implementeringen har utformats för att skapa en gräns mellan autentiserings- och auktoriseringselementen. Från och med AEM 6.3 är det möjligt att begränsa läsåtkomst utan att explicit lägga till ett autentiseringskrav. Om till exempel en viss instans kräver autentisering helt eller ett visst träd redan finns i ett underträd som redan kräver autentisering.

På samma sätt kan ett visst träd markeras med ett autentiseringskrav utan att ändra den gällande behörighetsinställningen. Kombinationerna och resultaten visas i avsnittet Kombinera CUG-principer och autentiseringskrav.

Ökning overview

Behörighet: Begränsa läsåtkomst authorization-restricting-read-access

Nyckelfunktionen i en CUG-fil är att begränsa läsåtkomst för ett visst träd i innehållsdatabasen för alla utom valda huvuden. I stället för att manipulera standardinnehållet för åtkomstkontroll på direkten har den nya implementeringen en annan metod genom att definiera en dedikerad typ av åtkomstkontrollprincip som representerar en CUG.

Åtkomstkontrollprincip för CUG access-control-policy-for-cug

Den nya typen av policy har följande egenskaper:

Implementeringen av PrincipalSetPolicy som används för att representera CUG:er definierar dessutom följande:

Dessa CUG-principer distribueras till en AEM instans via en separat autentiseringsmodul som kallas ekaauktoriseringskug. Den här modulen har en egen åtkomststyrningshantering och behörighetsutvärdering. Med andra ord, standardkonfigurationen för AEM levereras en konfiguration för Oak innehållsdatabas som kombinerar flera auktoriseringsmekanismer. Mer information finns på den här sidan i dokumentationen för Apache Oak.

I den här sammansatta konfigurationen ersätter inte en ny CUG det befintliga åtkomstkontrollsinnehållet som är kopplat till målnoden. Det är i stället ett tillägg som också kan tas bort senare utan att den ursprungliga åtkomstkontrollen påverkas. Som standard är det i AEM en åtkomstkontrollista.

Till skillnad från den tidigare implementeringen identifieras och behandlas de nya CUG-reglerna alltid som innehåll för åtkomstkontroll. Det innebär att de skapas och redigeras med JCR-API:t för åtkomstkontroll. Mer information finns i avsnittet Hantera CUG-principer.

Behörighetsutvärdering av CUG-principer permission-evaluation-of-cug-policies

Förutom en dedikerad åtkomstkontrollshantering för CUG:er kan du med den nya auktoriseringsmodellen villkorligt aktivera behörighetsutvärdering för dess principer. Detta gör att du kan konfigurera CUG-principer i en staging-miljö, och bara aktiverar utvärdering av de effektiva behörigheterna när de har replikerats till produktionsmiljön.

Behörighetsutvärderingen för CUG-profiler och interaktionen med standardauktoriseringsmodellen eller någon annan auktoriseringsmodell följer mönstret som utformats för flera auktoriseringsmekanismer i Apache Jackrabbit Oak. Det innebär att en viss uppsättning behörigheter beviljas endast om alla modeller beviljar åtkomst. Mer information finns på den här sidan.

Följande egenskaper gäller för behörighetsutvärderingen som är kopplad till behörighetsmodellen som är utformad för att hantera och utvärdera CUG-principer:

Effekten av en enda CUG-princip vid utvärdering av tillstånd kan sammanfattas enligt följande:

Bästa praxis best-practices

Följande metodtips bör omfatta definition av begränsad läsåtkomst via CUG

Autentisering: Definiera autentiseringskrav authentication-defining-the-auth-requirement

De autentiseringsrelaterade delarna av CUG-funktionen gör att du kan markera träd som kräver autentisering och eventuellt ange en dedikerad inloggningssida. I enlighet med den tidigare versionen kan du med den nya implementeringen markera träd som kräver verifiering i innehållsdatabasen. Den aktiverar även villkorligt synkronisering med Sling org.apache.sling.api.auth.Authenticatorsom är ansvarig för att i slutändan verkställa kravet och omdirigera till en inloggningsresurs.

Dessa krav har registrerats med autentiseraren av en OSGi-tjänst som tillhandahåller registreringsegenskapen sling.auth.requirements. Dessa egenskaper används sedan för att dynamiskt utöka autentiseringskraven. Mer information finns i säljdokumentationen.

Definiera autentiseringskravet med en dedikerad blandningstyp defining-the-authentication-requirement-with-a-dedicated-mixin-type

Av säkerhetsskäl ersätter den nya implementeringen användningen av en kvarvarande JCR-egenskap med en dedikerad mixin-typ, granite:AuthenticationRequired, som definierar en valfri egenskap av typen STRING för inloggningssökvägen granite:loginPath. Det är bara innehållsändringar som är relaterade till den här mixin-typen som leder till en uppdatering av de krav som registrerats med Apache Sling Authenticator. Ändringarna spåras vid beständiga tillfälliga ändringar och kräver därför ett javax.jcr.Session.save()-anrop för att börja gälla.

Samma sak gäller för egenskapen granite:loginPath. Den respekteras endast om den definieras av autenticeringskravet för relaterad blandningstyp. Om du lägger till en restegenskap med det här namnet i en ostrukturerad JCR-nod visas inte den önskade effekten och egenskapen ignoreras av hanteraren som ansvarar för uppdateringen av OSGi-registreringen.

Registrerar autentiseringskravet och inloggningssökvägen med SSLING-autentiseraren registering-the-authentication-requirement-and-login-path-with-the-sling-authenticator

Eftersom den här typen av autentiseringskrav förväntas begränsas till vissa körningslägen och till en liten delmängd av träd i innehållsdatabasen, är spårning av kravet på blandningstyp och egenskaper för inloggningssökväg villkorlig. Den är dessutom bunden till en motsvarande konfiguration som definierar de sökvägar som stöds (se Konfigurationsalternativ nedan). Därför utlöser endast ändringar inom omfånget för de här sökvägarna en uppdatering av OSGi-registreringen, någon annanstans ignoreras både mixin-typen och egenskapen.

Standardinställningen för AEM använder nu den här konfigurationen genom att tillåta att mixinen ställs in i författarens körningsläge, men att den endast får effekt vid replikering till publiceringsinstansen. Se den här sidan för mer information om hur Sling verkställer autentiseringskravet.

Om du lägger till blandningstypen granite:AuthenticationRequired i de sökvägar som stöds, uppdateras OSGi-registreringen av den ansvariga hanteraren med en ny, extra post med egenskapen sling.auth.requirements. Om ett givet autentiseringskrav anger den valfria egenskapen granite:loginPath, registreras värdet även med autentiseraren med ett '-'-prefix som ska uteslutas från autentiseringskravet.

Utvärdering och arv av autentiseringskrav evaluation-and-inheritance-of-the-authentication-requirement

Autentiseringskraven för Apache Sling ärvs via sid- eller nodhierarkin. Själva detaljerna om arvet och utvärderingen av autentiseringskrav som ordning och prioritet betraktas som en implementeringsdetalj och kommer inte att dokumenteras i den här artikeln.

Utvärdering av inloggningssökväg evaluation-of-login-path

Utvärderingen av inloggningssökvägen och omdirigeringen till motsvarande resurs vid autentisering är en implementeringsinformation i autentiseringshanteraren för Adobe Granite-inloggningsväljaren ( com.day.cq.auth.impl.LoginSelectorHandler), som är en Apache Sling AuthenticationHandler som är konfigurerad med AEM som standard.

När hanteraren anropar AuthenticationHandler.requestCredentials försöker den avgöra vilken inloggningssida för mappningen som användaren omdirigeras till. Detta inkluderar följande steg:

Målet för den här dokumentationen är utvärderingen av inloggningssökvägen som visas av det interna LoginPathProvider-gränssnittet. Implementeringen som skickats sedan AEM 6.3 fungerar på följande sätt:

LoginPathProvider, som implementeras av det nya stödet för autentiseringskrav i Granite, visar inloggningssökvägar som definieras av granite:loginPath -egenskaperna, som i sin tur definieras av blandningstypen enligt beskrivningen ovan. Mappningen av resurssökvägen som innehåller inloggningssökvägen och egenskapsvärdet behålls i minnet och utvärderas för att hitta en lämplig inloggningssökväg för andra noder i hierarkin.

Bästa praxis best-practices-1

Följande bästa metoder bör beaktas när autentiseringskrav definieras:

Representation i databasen representation-in-the-repository

CUG-principrepresentation i databasen cug-policy-representation-in-the-repository

I Oak-dokumentationen beskrivs hur de nya CUG-profilerna återspeglas i databasinnehållet. Mer information finns på den här sidan.

Autentiseringskrav i databasen authentication-requirement-in-the-repository

Behovet av en separat autentiseringskrav återspeglas i databasinnehållet med en dedikerad mixin-nodtyp som placeras på målnoden. MixIn-typen definierar en valfri egenskap som anger en dedikerad inloggningssida för trädet som definieras av målnoden.

Sidan som är kopplad till inloggningssökvägen kan finnas inuti eller utanför det trädet. Det ingår inte i autentiseringskravet.

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

Hantera CUG-principer och autentiseringskrav managing-cug-policies-and-authentication-requirement

Hantera CUG-principer managing-cug-policies

Den nya typen av åtkomstkontrollprinciper som begränsar läsåtkomst för en CUG hanteras med JCR-åtkomstkontrollsgränssnittet och följer de mekanismer som beskrivs i JCR 2.0-specifikationen.

Ange en ny CUG-princip set-a-new-cug-policy

Kod för att tillämpa en ny CUG-princip på en nod som inte hade en CUG-inställning tidigare. Observera att getApplicablePolicies bara returnerar nya profiler som inte har angetts tidigare. I slutet måste principen skrivas tillbaka och ändringarna måste sparas.

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 (for example,
                                                   // 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();

Redigera en befintlig CUG-princip edit-an-existing-cug-policy

Följande steg krävs för att redigera en befintlig CUG-princip. Den ändrade principen måste skrivas tillbaka och ändringarna måste sparas med 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");
}

Hämta effektiva CUG-principer retrieve-effective-cug-policies

Hanteringen av JCR-åtkomstkontroll definierar en bästa metod för att hämta principer som börjar gälla vid en viss sökväg. Eftersom utvärderingen av CUG-principer är villkorsstyrd och beroende på vilken konfiguration som ska aktiveras, är det bekvämt att anropa getEffectivePolicies för att verifiera om en viss CUG-princip börjar gälla i en viss installation.

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

Hämta ärvda CUG-principer retrieve-inherited-cug-policies

Söker efter alla kapslade CUG:er som har definierats på en viss sökväg oavsett om de börjar gälla eller inte. Mer information finns i avsnittet Konfigurationsalternativ.

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

Hantera CUG-principer efter huvudnamn managing-cug-policies-by-pincipal

De tillägg som definieras av JackrabbitAccessControlManager och som gör att du kan redigera åtkomstkontrollprinciper efter huvudobjekt implementeras inte med CUG-åtkomstkontrollshantering, eftersom en CUG-princip per definition alltid påverkar alla principer: de som anges med PrincipalSetPolicy beviljas läsåtkomst medan alla andra huvudobjekt inte kan läsa innehåll i trädet som definieras av målnoden.

Motsvarande metoder returnerar alltid en tom principarray, men genererar inga undantag.

Hantera autentiseringskrav managing-the-authentication-requirement

Ett nytt autentiseringskrav skapas, ändras eller tas bort genom att målnodens effektiva nodtyp ändras. Egenskapen för den valfria inloggningssökvägen kan sedan skrivas med det vanliga JCR-API:t.

Lägga till ett nytt verifieringskrav adding-a-new-auth-requirement

Steg för att skapa ett autentiseringskrav beskrivs nedan. Kravet registreras endast med Apache Sling-autentiseraren om RequirementHandler har konfigurerats för trädet som innehåller målnoden.

Node targetNode = [...]

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

Lägg till ett nytt autentiseringskrav med inloggningssökväg add-a-new-auth-requirement-with-login-path

Steg för att skapa ett autentiseringskrav, inklusive en inloggningssökväg. Kravet och undantaget för inloggningssökvägen registreras bara med Apache Sling Authenticator om RequirementHandler har konfigurerats för trädet som innehåller målnoden.

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

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

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

Ändra en befintlig inloggningssökväg modify-an-existing-login-path

Stegen för att ändra en befintlig inloggningssökväg beskrivs nedan. Ändringen registreras bara med Apache Sling Authenticator om RequirementHandler har konfigurerats för trädet som innehåller målnoden. Tidigare värde för inloggningssökväg tas bort från registreringen. Autentiseringskravet som är associerat med målnoden påverkas inte av den här ändringen.

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

Ta bort en befintlig inloggningssökväg remove-an-existing-login-path

Steg för att ta bort en befintlig inloggningssökväg. Inloggningssökvägsposten avregistreras endast från Apache Sling Authenticator om RequirementHandler har konfigurerats för trädet som innehåller målnoden. Autentiseringskravet som är associerat med målnoden påverkas inte.

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

Du kan också använda metoden nedan för att uppnå samma syfte:

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

Ta bort ett autenticeringskrav remove-an-auth-requirement

Steg för att ta bort ett befintligt autentiseringskrav. Kravet avregistreras endast från Apache Sling Authenticator om RequirementHandler har konfigurerats för trädet som innehåller målnoden.

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

session.save();

Hämta effektiva autentiseringskrav retrieve-effective-auth-requirements

Det finns inget dedikerat offentligt API för att läsa alla effektiva autentiseringskrav som registrerats med Apache Sling Authenticator. Listan visas dock i systemkonsolen på https://<serveraddress>:<serverport>/system/console/slingauth under avsnittet Konfiguration av autentiseringskrav.

Följande bild visar autentiseringskraven för en AEM publiceringsinstans med demoinnehåll. Den markerade sökvägen på communitysidan visar hur ett krav som lagts till av implementeringen som beskrivs i det här dokumentet återspeglas i Apache Sling Authenticator.

Hämta den effektiva inloggningssökvägen retrieve-the-effective-login-path

Det finns för närvarande inget offentligt API för att hämta inloggningssökvägen som börjar gälla anonymt när en resurs som kräver autentisering används. Se avsnittet Utvärdering av inloggningssökväg för implementeringsinformation om hur inloggningssökvägen hämtas.

Observera dock att utöver inloggningssökvägarna som definieras med den här funktionen finns det andra sätt att ange omdirigering till inloggningen, vilket bör beaktas när innehållsmodellen och autentiseringskraven för en viss AEM designas.

Hämta det ärvda autentiseringsbehovet retrieve-the-inherited-auth-requirement

Precis som med inloggningssökvägen finns det inget offentligt API för att hämta de ärvda autentiseringskrav som definierats i innehållet. Följande exempel visar hur du listar alla autentiseringskrav som har definierats med en viss hierarki oavsett om de börjar gälla eller inte. Mer information finns i Konfigurationsalternativ.

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

Kombinera CUG-principer och autentiseringskrav combining-cug-policies-and-the-authentication-requirement

I följande tabell visas giltiga kombinationer av CUG-principer och autentiseringskrav i en AEM som har båda modulerna aktiverade via konfigurationen.

OSGi-komponenter och konfiguration osgi-components-and-configuration

I det här avsnittet finns en översikt över OSGi-komponenterna och de enskilda konfigurationsalternativen som introducerades i den nya CUG-implementeringen.

Se även dokumentationen för CUG-mappning för en omfattande mappning av konfigurationsalternativen mellan den gamla och den nya implementeringen.

Auktorisering: Installation och konfiguration authorization-setup-and-configuration

De nya, auktoriseringsrelaterade delarna finns i Oak CUG Authorization-paketet ( org.apache.jackrabbit.oak-authorization-cug), som är en del av AEM standardinstallation. Paketet definierar en separat auktoriseringsmodell som ska användas som ett ytterligare sätt att hantera läsåtkomst.

Konfigurera CUG-auktorisering setting-up-cug-authorization

Konfigureringen av CUG-auktorisering beskrivs i detalj i relevant Apache-dokumentation. AEM har som standard CUG-auktorisering i alla körningslägen. Stegvisa instruktioner kan också användas för att inaktivera CUG-auktorisering i de installationer som kräver en annan auktoriseringsinställning.

Konfigurera referensfiltret configuring-the-referrer-filter

Du måste också konfigurera Sling Referrer-filtret med alla värdnamn som kan användas för att komma åt AEM, till exempel via CDN, belastningsutjämnare och andra.

Om referensfiltret inte är konfigurerat visas fel, som följande, när en användare försöker logga in på en CUG-plats:

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

Egenskaper hos OSGi-komponenter characteristics-of-osgi-components

Följande två OSGi-komponenter har introducerats för att definiera autentiseringskrav och ange dedikerade inloggningssökvägar:

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

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

Konfigurationsalternativ configuration-options

Konfigurationsalternativen är:

De tillgängliga konfigurationsalternativen som är kopplade till modulen CUG-auktorisering listas och beskrivs mer ingående i dokumentationen för Apache Oak.

Utesluta huvudkonton från CUG-utvärderingen excluding-principals-from-cug-evaluation

Undantaget av enskilda huvudkonton från CUG-utvärderingen har antagits från den tidigare tillämpningen. Den nya CUG-auktoriseringen täcker detta med ett dedikerat gränssnitt som heter CugExclude. Apache Jackrabbit Oak 1.4 levereras med en standardimplementering som utesluter en fast uppsättning huvudnamn och en utökad implementering som låter dig konfigurera enskilda huvudnamn. Den senare konfigureras i AEM publiceringsinstanser.

Standardvärdet eftersom AEM 6.3 förhindrar att följande objekt påverkas av CUG-principer:

Mer information finns i tabellen i avsnittet Standardkonfiguration sedan AEM 6.3 nedan.

Exkluderingen av gruppen "administratörer" kan ändras eller utökas i systemkonsolen i konfigurationsavsnittet i Exkluderingslistan för Apache Jackrabbit Oak CUG.

Det går också att tillhandahålla och distribuera en anpassad implementering av gränssnittet CugExclude för att justera uppsättningen med undantagna principer om det finns särskilda behov. Mer information och ett exempel på implementering finns i dokumentationen för CUG-plug-inen.

Autentisering: Installation och konfiguration authentication-setup-and-configuration

De nya autentiseringsrelaterade delarna finns i paketet Adobe Granite Authentication Handler ( com.adobe.granite.auth.authhandler version 5.6.48). Det här paketet ingår i AEM standardinstallation.

För att ställa in autentiseringskravsersättning för det inaktuella CUG-stödet måste vissa OSGi-komponenter finnas och vara aktiva i en viss AEM. Mer information finns i Egenskaper för OSGi-komponenter nedan.

Egenskaper för OSGi-komponenter

Följande två OSGi-komponenter har introducerats för att definiera autentiseringskrav och ange dedikerade inloggningssökvägar:

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

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

Konfigurationsalternativ configuration-options-1

De autentiseringsrelaterade delarna av CUG-omskrivningen levereras endast med ett konfigurationsalternativ som är kopplat till Adobe Granite-autentiseringskravet och inloggningssökvägshanteraren:

"Autentiseringskrav och hanterare för inloggningssökväg"

Standardkonfiguration sedan AEM 6.3 default-configuration-since-aem

Nya installationer av AEM använder som standard de nya implementeringarna både för auktoriserings- och autentiseringsrelaterade delar av CUG-funktionen. Den gamla implementeringen "Adobe Granite Closed User Group (CUG) Support" har tagits bort och kommer som standard att inaktiveras i alla AEM installationer. De nya implementeringarna aktiveras i stället enligt följande:

Författarinstanser author-instances

Publish-instanser publish-instances

Inaktiverar CUG-auktoriserings- och autentiseringskrav disabling-cug-authorization-and-authentication-requirement

Den nya implementeringen kan inaktiveras helt om en viss installation inte använder användargränssnitten eller använder olika metoder för autentisering och auktorisering.

Inaktivera CUG-auktorisering disable-cug-authorization

Mer information om hur du tar bort CUG-auktoriseringsmodellen från den sammansatta auktoriseringsinställningen finns i dokumentationen för CUG-plug-ability .

Inaktivera autentiseringskravet disable-the-authentication-requirement

Om du vill inaktivera stöd för autentiseringskravet som tillhandahålls av modulen granite.auth.authhandler räcker det att ta bort konfigurationen som är kopplad till Adobe Granite-autentiseringskrav och inloggningssökvägshanteraren.

Interaktion med andra moduler interaction-with-other-modules

Apache Jackrabbit API apache-jackrabbit-api

För att återspegla den nya typen av åtkomstkontrollprincip som används av CUG-auktoriseringsmodellen har API:t som definieras av Apache Jackrabbit utökats. Sedan version 2.11.0 av modulen jackrabbit-api definieras ett nytt gränssnitt som heter org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy och som sträcker sig från javax.jcr.security.AccessControlPolicy.

Apache Jackrabbit FileVault apache-jackrabbit-filevault

Importmekanismen för Apache Jackrabbit FileVault har justerats för att hantera åtkomstkontrollprinciper av typen PrincipalSetPolicy.

Distribution av Apache Sling-innehåll apache-sling-content-distribution

Se avsnittet Apache Jackrabbit FileVault ovan.

Adobe Granite-replikering adobe-granite-replication

Replikeringsmodulen har justerats något för att kunna replikera CUG-principer mellan olika AEM instanser:

Det finns en begränsning för replikering av CUG-principer. Om en angiven CUG-princip tas bort utan att motsvarande mixin-nodtyp rep:CugMixin, tas bort återspeglas inte borttagningen vid replikeringen. Detta har åtgärdats genom att man alltid har tagit bort blandningen när man har tagit bort policyn. Begränsningen kan dock visa sig om blandningstypen läggs till manuellt.

Autentiseringshanterare för Adobe Granite adobe-granite-authentication-handler

Autentiseringshanteraren Adobe Granite HTTP Header Authentication Handler som levereras med paketet com.adobe.granite.auth.authhandler innehåller en referens till gränssnittet CugSupport som definieras av samma modul. Den används för att beräkna "sfären" under vissa omständigheter och återgår till sfären som konfigurerats med hanteraren.

Den här inställningen har justerats så att referensen till CugSupport är valfri för att säkerställa maximal bakåtkompatibilitet om en given konfiguration beslutar att återaktivera den borttagna implementeringen. Installationer som använder implementeringen kommer inte längre att få den sfär som extraheras från CUG-implementeringen, men de kommer alltid att visa sfären som definierats med Adobe Granite HTTP Header Authentication Handler.

AEM LiveCopy aem-livecopy

När du konfigurerar CUG-grupper med LiveCopy visas en extra nod och en extra egenskap i databasen enligt följande:

Båda dessa element skapas under cq:Page. Med den aktuella designen hanterar MSM bara noder och egenskaper som finns under noden cq:PageContent (jcr:content).

Därför kan CUG-grupper inte rullas ut till Live-kopior från utkast. Planera runt detta när du konfigurerar Live Copy.

Ändringar i den nya CUG-implementeringen changes-with-the-new-cug-implementation

Syftet med detta avsnitt är att ge en översikt över de ändringar som gjorts i CUG-funktionen och en jämförelse mellan den gamla och den nya implementeringen. Här listas de ändringar som påverkar hur CUG-stöd konfigureras och hur och av vilka CUG-grupper hanteras i databasinnehållet.

Skillnader i CUG-inställningar och konfiguration differences-in-cug-setup-and-configuration

Den inaktuella OSGi-komponenten Adobe Granite Closed User Group (CUG) Support ( com.day.cq.auth.impl.cug.CugSupportImpl) har ersatts av nya komponenter för att separat kunna hantera autentiserings- och autentiseringsrelaterade delar av den tidigare CUG-funktionen.

Skillnader i hantering av kundupplevelser i databasinnehållet differences-in-managing-cugs-in-the-repository-content

I följande avsnitt beskrivs skillnaderna mellan den gamla och den nya implementeringen i implementerings- och säkerhetsperspektiven. Den nya implementeringen har samma funktionalitet, men det finns små förändringar som är viktiga att känna till när den nya CUG-filen används.

Skillnader i fråga om tillstånd differences-with-regards-to-authorization

De viktigaste skillnaderna från ett auktoriseringsperspektiv sammanfattas i listan nedan:

Dedikerat åtkomstkontrollinnehåll för användargränssnitten

I den gamla implementeringen användes standardauktoriseringsmodellen för att ändra åtkomstkontrollistans principer vid publicering och ersätta befintliga ACE:n med de inställningar som krävs av CUG:n. Detta utlöstes av att vanliga, kvarvarande JCR-egenskaper som tolkades vid publicering skrevs.

I och med den nya implementeringen påverkas inte åtkomstkontrollinställningen för standardauktoriseringsmodellen av någon CUG som skapas, ändras eller tas bort. I stället tillämpas en ny typ av princip med namnet PrincipalSetPolicy som extra åtkomstkontrollinnehåll på målnoden. Den här extra principen finns som underordnad till målnoden och skulle vara en jämställd principnod om sådan finns.

Redigerar CUG-principer i åtkomstkontrollhantering

Den här förändringen från kvarvarande JCR-egenskaper till en dedikerad åtkomstkontrollprincip påverkar behörigheten som behövs för att skapa eller ändra auktoriseringsdelen av CUG-funktionen. Eftersom detta betraktas som en ändring av åtkomstkontrollinnehåll, krävs det att jcr:readAccessControl- och jcr:modifyAccessControl-behörighet skrivs till databasen. Därför kan bara innehållsförfattare som har behörighet att ändra innehållet i åtkomstkontrollen på en sida konfigurera eller ändra det här innehållet. Detta står i kontrast till den gamla implementeringen där möjligheten att skriva vanliga JCR-egenskaper var tillräcklig, vilket resulterar i eskalering av behörigheter.

Målnod definierad av princip

Skapa CUG-principer på JCR-noden som definierar det underträd som ska ha begränsad läsåtkomst. Detta är sannolikt en AEM sida om CUG förväntas påverka hela trädet.

Om du placerar CUG-principen endast vid jcr:content-noden under en viss sida, begränsas endast åtkomsten till innehållet s.str för en viss sida, men det kommer inte att gälla för några jämställda eller underordnade sidor. Detta kan vara ett giltigt användningssätt och det är möjligt att göra detta med en databasredigerare där du kan använda detaljerat åtkomstinnehåll. Den kontrasterar emellertid den tidigare implementeringen där placeringen av en cq:cugEnabled-egenskap på jcr:content-noden mappades om internt till sidnoden. Mappningen utförs inte längre.

Behörighetsutvärdering med CUG-principer

Genom att gå från det gamla CUG-stödet till en ytterligare behörighetsmodell ändras det sätt på vilket effektiva läsbehörigheter utvärderas. Enligt beskrivningen i Jackrabbit-dokumentationen beviljas läsåtkomst endast för ett givet huvudobjekt som har behörighet att visa CUGcontent om behörighetsutvärderingen för alla modeller som har konfigurerats i Oak-databasen ger läsåtkomst.

För utvärderingen av de gällande behörigheterna beaktas alltså både CUGPolicy- och standardåtkomstkontrollposterna, och läsåtkomst för CUG-innehållet beviljas bara om det har beviljats av båda typerna av principer. I en AEM publiceringsinstallation där läsåtkomst till det fullständiga /content-trädet beviljas för alla, är effekten av CUG-principerna densamma som för den gamla implementeringen.

On-Demand Evaluation

Med CUG-auktoriseringsmodellen kan du aktivera åtkomstkontroll och behörighetsutvärdering separat:

I den nya AEM standardutvärderingen av CUG-principer är den bara aktiverad med körläget"publish". Mer information finns i informationen om standardkonfigurationen sedan AEM 6.3. Detta kan verifieras genom att man jämför effektiva profiler för en viss sökväg med de profiler som lagras i innehållet. Effektiva profiler visas bara om behörighetsutvärdering för användargränssnitten är aktiverat.

Som förklaras ovan lagras CUG-åtkomstkontrollprinciperna nu alltid i innehållet, men utvärdering av de gällande behörigheterna som följer av dessa principer kommer endast att tillämpas om CUG Evaluation Enabled aktiveras i systemkonsolen på Apache Jackrabbit Oak CUG Configuration. Som standard är det bara aktiverat med körläget "publish".

Skillnader i fråga om autentisering differences-with-regards-to-authentication

Skillnaderna gällande autentisering beskrivs nedan.

Dedikerad blandningstyp för autentiseringskrav dedicated-mixin-type-for-authentication-requirement

I den tidigare implementeringen utlöstes både autentiserings- och autentiseringsaspekterna för en CUG av en enda JCR-egenskap ( cq:cugEnabled). När det gäller autentisering resulterade detta i en uppdaterad lista över autentiseringskrav som lagrats med implementeringen av Apache Sling Authenticator. Med den nya implementeringen uppnås samma resultat genom att målnoden markeras med en dedikerad mixin-typ ( granite:AuthenticationRequired).

Egenskap för att exkludera inloggningssökväg property-for-excluding-login-path

Med blandningstypen definieras en enda valfri egenskap med namnet granite:loginPath, som i princip motsvarar egenskapen cq:cugLoginPage. Till skillnad från den tidigare implementeringen respekteras bara egenskapen för inloggningssökväg om dess deklarerande nodtyp är den ovannämnda mixin. Om du lägger till en egenskap med det namnet utan att ange blandningstypen har det ingen effekt och varken ett nytt krav eller ett undantag för inloggningssökvägen rapporteras till autentiseraren.

Privilegium för autentiseringskrav privilege-for-authentication-requirement

Om du lägger till eller tar bort en blandningstyp måste du ha jcr:nodeTypeManagement-behörighet. I den tidigare implementeringen används privilegiet jcr:modifyProperties för att redigera den kvarvarande egenskapen.

För granite:loginPath krävs samma behörighet för att lägga till, ändra eller ta bort egenskapen.

Målnod definierad av blandningstyp target-node-defined-by-mixin-type

Skapa autentiseringskrav på JCR-noden som definierar det underträd som ska underställas obligatorisk inloggning. Detta är sannolikt en AEM sida om CUG förväntas påverka hela trädet och användargränssnittet för den nya implementeringen lägger därför till den obligatoriska mixin-typen på sidnoden.

Om du bara placerar CUG-principen vid jcr:content-noden som finns under en viss sida begränsas endast åtkomsten till innehållet. Däremot påverkas inte sidnoden och inte heller underordnade sidor.

Detta kan vara ett giltigt scenario och är möjligt med en databasredigerare där du kan placera mixinen på valfri nod. Beteendet står dock i kontrast till den tidigare implementeringen, där en cq:cugEnabled- eller cq:cugLoginPage-egenskap placerades internt på jcr:content-noden. Mappningen utförs inte längre.

Konfigurerade sökvägar som stöds configured-supported-paths

Både blandningstypen granite:AuthenticationRequired och egenskapen granite:loginPath respekteras endast inom det omfång som definieras av konfigurationsalternativet Supported Paths som finns med Adobe Granite Authentication Requirement och Login Path Handler. Om inga sökvägar anges är funktionen för autentiseringskrav inaktiverad helt. I det här fallet börjar blandningstyp eller -egenskap gälla när den läggs till eller ställs in på en viss JCR-nod.

Mappning av JCR-innehåll, OSGi-tjänster och konfigurationer mapping-of-jcr-content-osgi-services-and-configurations

Dokumentet nedan innehåller en omfattande mappning av OSGi-tjänster, konfigurationer och databasinnehåll mellan den gamla och den nya implementeringen.

CUG-mappning sedan AEM 6.3

Hämta fil

Uppgradera CUG upgrade-cug

Befintliga installationer som använder den inaktuella CUG-filen existing-installations-using-the-deprecated-cug

Den gamla CUG-supportimplementeringen har tagits bort och kommer att tas bort i framtida versioner. Vi rekommenderar att du går över till de nya implementeringarna när du uppgraderar från versioner äldre än AEM 6.3.

Vid uppgradering AEM installation är det viktigt att se till att endast en CUG-implementering är aktiverad. Kombinationen av det nya och det gamla, föråldrade CUG-stödet testas inte och kommer troligen att orsaka oönskat beteende:

Migrerar befintligt CUG-innehåll migrating-existing-cug-content

Adobe tillhandahåller ett verktyg för migrering till den nya CUG-implementeringen. Så här använder du den: