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

Introduktion introduction

Sedan AEM 6.3 finns det en ny implementering av en sluten 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 ta med befintliga funktioner samtidigt som man åtgärdar 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 Kombinera CUG-principer och autentiseringskrav -avsnitt.

Översikt 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. Standardkonfigurationen AEM med andra ord en konfiguration för Oak-innehållsdatabas som kombinerar flera auktoriseringsmekanismer. Mer information finns på den här sidan på Apache Oak Documentation.

I den här sammansatta konfigurationen ersätter inte en ny CUG det befintliga åtkomstkontrollsinnehållet som är kopplat till målnoden, utan är utformat som ett tillägg som också kan tas bort senare utan att den ursprungliga åtkomstkontrollen påverkas. Som standard är 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 Hantera CUG-principer -avsnitt.

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

Förutom en dedikerad åtkomstkontrollshantering för användargrupper kan den nya auktoriseringsmodellen villkorligt aktivera behörighetsutvärdering för sina principer. Detta gör att du kan konfigurera CUG-principer i en staging-miljö och endast aktivera utvärdering av de gällande behörigheterna när de har replikerats till produktionsmiljön.

Behörighetsutvärderingen för CUG-regler och interaktionen med standardauktoriseringsmodellen eller någon ytterligare auktoriseringsmodell följer mönstret som utformats för flera auktoriseringsmekanismer i Apache Jackrabbit Oak: en given uppsättning behörigheter beviljas endast om alla modeller beviljar åtkomst. Se den här sidan för mer information.

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 bästa metoder bör beaktas vid definition av begränsad läsåtkomst via användargränssnitten:

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

De autentiseringsrelaterade delarna av CUG-funktionen gör det möjligt att markera träd som kräver autentisering och eventuellt ange en dedikerad inloggningssida. I enlighet med den tidigare versionen tillåter den nya implementeringen att markera träd som kräver autentisering i innehållsdatabasen och som villkorligt aktiverar synkronisering med Sling org.apache.sling.api.auth.Authenticatoransvarar för att slutligen genomdriva kravet och omdirigera till en inloggningsresurs.

Dessa krav registreras hos autentiseraren med hjälp av en OSGi-tjänst som tillhandahåller sling.auth.requirements registration-egenskap. Dessa egenskaper används sedan för att dynamiskt utöka autentiseringskraven. Mer information finns i Sling-dokumentation.

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 blandningstyp som kallas granite:AuthenticationRequired, som definierar en valfri egenskap av typen STRING för inloggningssökvägen granite:loginPath. Endast innehållsändringar som är relaterade till den här mixin-typen kommer att leda 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 en javax.jcr.Session.save() kräva att bli effektiva.

Samma sak gäller för granite:loginPath -egenskap. Den kommer endast att respekteras om den definieras av den autenticeringsrelaterade blandningstypen. 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 den obligatoriska blandningstypen och inloggningssökvägsegenskaperna villkorliga och bundna till en motsvarande konfiguration som definierar de sökvägar som stöds (se Konfigurationsalternativ nedan). Följaktligen kommer endast ändringar inom omfånget för de här sökvägarna som stöds att utlösa en uppdatering av OSGi-registreringen, i andra delar kommer både mixin-typen och egenskapen att ignoreras.

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 om du vill ha mer information om hur Sling uppfyller autentiseringskravet.

Lägga till granite:AuthenticationRequired blandningstypen i de konfigurerade sökvägarna som stöds gör att OSGi-registreringen av den ansvariga hanteraren uppdateras med en ny, extra post med sling.auth.requirements -egenskap. Om ett givet autentiseringskrav anger det valfria granite:loginPath -egenskapen registreras värdet dessutom med autentiseraren med ett '-'-prefix för att undantas från autentiseringskravet.

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

Autentiseringskraven för Apache Sling förväntas ärvas genom 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 för närvarande en implementeringsdetalj i autentiseringshanteraren för Adobe Granite-inloggningsväljaren ( com.day.cq.auth.impl.LoginSelectorHandler), som är en Apache Sling AuthenticationHandler som har konfigurerats med AEM som standard.

Vid samtal AuthenticationHandler.requestCredentials den här hanteraren gör ett försök att avgöra vilken inloggningssida för mappning som användaren ska omdirigeras till. Detta inkluderar följande steg:

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

The LoginPathProvider som implementerats av det nya stödet för krav på autentisering i Granite visar inloggningssökvägar som definieras av granite:loginPath egenskaper, 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

Oak-dokumentationen beskriver hur de nya CUG-profilerna återspeglas i databasinnehållet. Mer information finns i 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 kommer att uteslutas från 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 för att begränsa läsåtkomst för en CUG hanteras med hjälp av JCR-API:t för åtkomstkontroll och följer de mekanismer som beskrivs i JCR 2.0-specifikation.

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

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

Följande steg krävs för att redigera en befintlig CUG-princip. Observera att den ändrade policyn måste skrivas tillbaka och ändringarna måste bevaras 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 metod för bästa förmåga att hämta principer som börjar gälla vid en viss sökväg. På grund av det faktum att utvärderingen av CUG-principer är villkorlig och beror på vilken konfiguration som ska aktiveras, anropar getEffectivePolicies är ett praktiskt sätt att kontrollera 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 Konfigurationsalternativ -avsnitt.

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 som tillåter redigering av åtkomstkontrollprinciper efter huvudnamn inte implementeras med CUG-åtkomstkontrollhantering, eftersom en CUG-profil per definition alltid påverkar alla huvudkonton: de som anges med PrincipalSetPolicy får 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

De nya autentiseringskraven 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 nytt autentiseringskrav beskrivs nedan. Observera att kravet bara registreras med Apache Sling Authenticator 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 nytt autentiseringskrav, inklusive en inloggningssökväg. Observera att kravet och undantaget för inloggningssökvägen endast registreras hos 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 endast med Apache Sling Authenticator om RequirementHandler har konfigurerats för trädet som innehåller målnoden. Det tidigare värdet för inloggningssökvägen 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 "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 på 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.

Behörighet: Installation och konfiguration authorization-setup-and-configuration

De nya, auktoriseringsrelaterade delarna finns i Oak CUG Authorization bundle ( org.apache.jackrabbit.oak-authorization-cug), som ingår i 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

Hur du konfigurerar CUG-auktorisering beskrivs i detalj i relevant Apache-dokumentation. Som standard har AEM CUG-auktorisering distribuerats i alla körningslägen. Steginstruktionerna 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-referensfilter 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

Nyckelkonfigurationsalternativen är:

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

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 huvuduppgifter samt en utökad implementering som tillåter konfigurering av 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 Standardkonfiguration sedan AEM 6.3 nedan.

Exkluderingen av gruppen 'administratörer' kan ändras eller utökas i systemkonsolen i konfigurationsavsnittet i Apache Jackrabbit Oak CUG Exclude List.

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

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

De nya, autentiseringsrelaterade delarna finns i Autentiseringshanterare för Adobe Granite bundle ( com.adobe.granite.auth.authhandler version 5.6.48). Det här paketet ingår i AEM standardinstallation.

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

Egenskaper hos 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 har endast ett konfigurationsalternativ som är kopplat till Adobe Granite-autentiseringskravet och inloggningssökvägshanteraren:

"Autentiseringskrav och inloggningssökvägshanterare"

Standardkonfiguration sedan AEM 6.3 default-configuration-since-aem

Nya installationer av AEM använder som standard de nya implementeringarna för både 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

Publicera 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

Läs CUG-plug dokumentation som innehåller information om hur du tar bort CUG-auktoriseringsmodellen från den sammansatta auktoriseringsinställningen.

Inaktivera autentiseringskravet disable-the-authentication-requirement

För att inaktivera stödet för autentiseringskraven enligt granite.auth.authhandler modul som är associerad med Autentiseringskrav och hanterare för inloggningssökväg för Adobe Granite.

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 jackrabbit-api module definierar ett nytt gränssnitt som kallas org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicysom 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 ovanstående Apache Jackrabbit FileVault -avsnitt.

Adobe Granite-replikering adobe-granite-replication

Replikeringsmodulen har justerats något för att CUG-principerna ska kunna replikeras mellan olika AEM:

Det finns en begränsning för replikering av CUG-principer. Om en viss CUG-princip tas bort utan att motsvarande mixin-nodtyp tas bort rep:CugMixin, borttagningen återspeglas inte vid replikering. 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 Autentiseringshanterare för Adobe Granite HTTP Header levererade med com.adobe.granite.auth.authhandler paket innehåller en referens till CugSupport gränssnitt 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.

Detta har justerats för att referera till CugSupport valfritt för att säkerställa maximal bakåtkompatibilitet om en viss 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 den kommer alltid att visa sfären som den definierats med Autentiseringshanterare för Adobe Granite HTTP Header.

AEM LiveCopy aem-livecopy

Om du konfigurerar CUG:er i kombination med LiveCopy representeras de i databasen av en extra nod och en extra egenskap enligt följande:

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

Därför kan CUG-grupper inte rullas ut till Live-kopior från utkast. Se till att du undviker 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 samt 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 diferences-in-cug-setup-and-configuration

Den borttagna OSGi-komponenten Stöd för CUG (Adobe Granite Closed User Group) ( com.day.cq.auth.impl.cug.CugSupportImpl) har ersatts av nya komponenter för att separat kunna hantera auktoriserings- 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 diferences-with-regards-to-authorization

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

Innehåll för dedikerad åtkomstkontroll 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. Istället anropas en ny typ av princip PrincipalSetPolicy används som extra åtkomstkontrollinnehåll för målnoden. Den här extra principen kommer att placeras som underordnad till målnoden och kommer att vara jämställd med standardprincipnoden om en sådan finns.

Redigera 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 anses vara en ändring av innehållet i kontrollpanelen krävs det jcr:readAccessControl och jcr:modifyAccessControl behörighet för att kunna skrivas 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

CUG-principer förväntas skapas vid 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.

Observera att om du bara placerar CUG-principen vid jcr:content-noden som finns under en viss sida begränsas åtkomsten till innehållet på 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ändningsexempel och det är möjligt att göra detta med en databasredigerare som kan använda detaljerat innehåll för åtkomst. Den kontrasterar emellertid den tidigare implementeringen där placeringen av en cq:cugEnabled-egenskap på jcr:content-noden mappades om internt till sidnoden. Den här 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 Jackrabbits dokumentation, en angiven användare som kan visa CUGcontent beviljas läsåtkomst endast om behörighetsutvärderingen för alla modeller som konfigurerats i Oak-databasen ger läsåtkomst.

Med andra ord, för utvärderingen av de gällande behörigheterna, CUGPolicy och standardposterna för åtkomstkontroll kommer att beaktas och läsåtkomst för CUG-innehållet kommer endast att beviljas om det beviljas av båda typerna av profiler. I en AEM publiceringsinstallation där läsåtkomst till den fullständiga /content Trädet beviljas för alla, effekten av CUG-policyer blir densamma som med den gamla implementeringen.

On Demand-utvärdering

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

I den nya AEM standardutvärderingen av CUG-principer är det bara aktiverat med körläget"publish". Läs mer om standardkonfiguration sedan AEM 6.3 för mer information. 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-åtkomstkontrollprinciper nu alltid i innehållet, men utvärdering av de gällande behörigheterna som följer av dessa principer kommer endast att genomföras om CUG-utvärdering aktiverad är påslagen i systemkonsolen vid Apache Jackrabbit Oak CUG-konfiguration. Som standard aktiveras det endast med körningsläget 'publish'.

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

Skillnaderna när det gäller autentisering beskrivs nedan.

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

I den tidigare implementeringen utlöstes både auktoriserings- 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. I och med den nya implementeringen uppnås samma resultat genom att målnoden markeras med en dedikerad blandningstyp ( granite:AuthenticationRequired).

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

Med mixin-typen definieras en enda valfri egenskap som kallas granite:loginPath, som i stort sett motsvarar cq:cugLoginPage -egenskap. Till skillnad från den tidigare implementeringen kommer egenskapen för inloggningssökväg endast att respekteras om dess deklarerande nodtyp är den ovannämnda mixin. Om du lägger till en egenskap med det namnet utan att ange blandningstypen får 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

Du måste lägga till eller ta bort en blandningstyp jcr:nodeTypeManagement privilegium beviljas. I den tidigare implementeringen är jcr:modifyProperties Privilegium används för att redigera den kvarvarande egenskapen.

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

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

Autentiseringskrav förväntas skapas på JCR-noden som definierar det underträd som ska genomgå 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 kommer därför att lägga till blandningstypen för auth-krav på sidnoden.

Om du bara placerar CUG-principen vid jcr:content-noden som finns under en viss sida begränsas bara åtkomsten till innehållet, men det påverkar inte själva sidnoden eller underordnade sidor.

Detta kan vara ett giltigt scenario och är möjligt med en databasredigerare som tillåter att mixin placeras 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. Den här mappningen utförs inte längre.

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

Båda granite:AuthenticationRequired blandningstyp och egenskapen granite:loginPath respekteras endast inom det omfång som definieras av uppsättningen Banor som stöds konfigurationsalternativ finns med Autentiseringskrav och hanterare för inloggningssökväg för Adobe Granite. Om inga sökvägar anges inaktiveras funktionen för autentiseringskrav 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 som är ä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. Utför följande steg om du vill använda den: