Gesloten gebruikersgroepen in AEM

Laatst bijgewerkt: 5 mei 2025
  • Van toepassing op:
  • Experience Manager 6.5
  • Onderwerpen:

Gemaakt voor:

  • Beheerder

Inleiding

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.

NOTE
Ter wille van de eenvoud wordt in deze documentatie de afkorting CUG gebruikt.

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

  • een duidelijke scheiding tussen authenticatie- en autorisatieelementen, die afzonderlijk of in combinatie kunnen worden gebruikt;
  • Het specifieke vergunningsmodel om op de beperkte leestoegang bij de gevormde bomen van de GG te wijzen zonder andere opstelling en toestemmingsvereisten van de toegangscontrole te storen;
  • Scheiding tussen de opstelling van het toegangsbeheer van beperkte gelezen toegang, die op auteursinstanties, en toestemmingsevaluatie nodig is die slechts bij publiceren is;
  • Bewerken van beperkte leestoegang zonder escalatie met bevoegdheden;
  • Specifieke uitbreiding van knooppunttype om de authenticatievereiste te markeren;
  • Optioneel aanmeldpad dat is gekoppeld aan de verificatievereiste.

De nieuwe implementatie van de aangepaste gebruikersgroep

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

  • Beperk leestoegang op de boom die moet worden beschermd en sta slechts lezen voor hoofden toe die of met een bepaalde instantie van de GG vermeld zijn of van de evaluatie van de GG helemaal worden uitgesloten. Dit wordt genoemd het toestemmings element.
  • Afdwingen van verificatie op een bepaalde structuur en optioneel een specifieke aanmeldingspagina opgeven voor die structuur die vervolgens wordt uitgesloten. Dit wordt genoemd het authentificatie element.

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 de resultaten zijn vermeld in Combinerend Beleid van de GING en de sectie van de Vereiste van de Authentificatie.

Overzicht

Autorisatie: Leestoegang beperken

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

Dit nieuwe type beleid heeft de volgende kenmerken:

  • Toegangscontrolebeleid van het type org.apache.jackrabbit.api.security.authentication.PrincipalSetPolicy (gedefinieerd door de Apache Jackrabbit-API);
  • PrincipalSetPolicy verleent voorrechten aan een wijzigbare reeks principes;
  • De toegekende bevoegdheden en de reikwijdte van het beleid zijn een detail van de uitvoering.

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

  • Het beleid van CUG verleent slechts leestoegang tot regelmatige punten JCR (bijvoorbeeld, wordt de inhoud van de toegangscontrole uitgesloten);
  • Het werkingsgebied wordt bepaald door de toegang-gecontroleerde knoop die het beleid van de GECG houdt;
  • Het beleid van de CUG kan worden genesteld, begint een genestelde KUG een nieuwe KUG zonder de belangrijkste reeks van "ouder"KUG over te nemen;
  • Het effect van het beleid, als de evaluatie wordt toegelaten, wordt geërft aan volledige subtree neer aan volgende genestelde KUG.

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 standaardinstelling AEM een configuratie in de opslagplaats voor Oak-inhoud die meerdere machtigingsmechanismen combineert. Voor meer info, zie deze pagina op de Documentatie van Apache Oak.

In deze samengestelde opstelling, vervangt een nieuwe KUG niet de bestaande inhoud van het toegangsbeheer in bijlage aan de doelknoop. In plaats daarvan, is het een aanvulling 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 CUG 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. Voor meer info, zie het Leiden van het Beleid van de CUGsectie.

Evaluatie van machtigingen voor CUG-beleid

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

De beoordeling van de toestemming voor het beleid van de CUG en de interactie met het gebrek of om het even welk extra vergunningsmodel volgen het patroon dat voor veelvoudige vergunningsmechanismen in Apache Jackrabbit Oak wordt ontworpen. Dat wil zeggen dat een bepaalde set machtigingen alleen wordt verleend als en alleen als alle modellen toegang verlenen. Zie de Documentatie van Jackrabbit Oakvoor meer details.

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 behandelt slechts gelezen toestemmingen voor regelmatige knopen en eigenschappen, maar het lezen van toegangsbeheerinhoud
  • Het behandelt geen schrijftoestemmingen noch om het even welk soort toestemmingen die voor wijziging van beschermde inhoud JCR (toegangsbeheer, knooptypeinformatie, versioning, sluiting, of gebruikersbeheer worden vereist). Deze toestemmingen worden niet beïnvloed door een beleid van de CUG en zullen niet door het bijbehorende vergunningsmodel worden geëvalueerd. Of deze toestemmingen worden verleend hangt van de andere modellen af die in de veiligheidsopstelling worden gevormd.

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

  • Leestoegang wordt ontzegd voor iedereen behalve onderwerpen die uitgesloten hoofden of hoofden bevatten die in het beleid worden vermeld;
  • Het beleid wordt van kracht op de toegang-gecontroleerde knoop die het beleid en zijn eigenschappen houdt;
  • Het effect wordt ook geërft onderaan de hiërarchie - dat wil zeggen, de puntboom die door de toegang-gecontroleerde knoop wordt bepaald;
  • Nochtans, beïnvloedt het noch siblings noch voorouders van de toegang-gecontroleerde knoop;
  • De overerving van een bepaalde CUG houdt bij genestelde KUG tegen.

Aanbevolen procedures

De volgende beste praktijken zouden voor het bepalen van beperkte gelezen toegang door CUGs met rekening moeten brengen:

  • Bespreek bewust of uw behoefte aan een KUUG over het beperken van lees toegang of een authentificatievereiste is. Als het laatste, of als er behoefte aan allebei is, raadpleeg de sectie over Beste praktijken voor details betreffende het vereiste van de Authentificatie

  • Creeer een bedreigingsmodel voor de gegevens of de inhoud die moeten worden beschermd om bedreigingsgrenzen te identificeren en een duidelijk beeld over de gevoeligheid van de gegevens en de rollen te krijgen verbonden aan erkende toegang

  • Model de inhoud van de opslagplaats en CUGs die algemene toestemmingsgerelateerde aspecten en beste praktijken in mening houden:

    • Herinner dat de lees toestemming slechts wordt verleend als bepaalde CUG en de evaluatie van andere modules die in de opstellingssubsidie worden opgesteld een bepaalde onderwerp toestaan om een bepaald bewaarplaatspunt te lezen
    • Vermijd het creëren van overtollige KUGs waar de gelezen toegang reeds door andere vergunningsmodules wordt beperkt
    • Bij buitensporige behoefte aan geneste CUG's kunnen problemen in het inhoudsontwerp mogelijk worden gemarkeerd
    • De bovenmatige behoefte aan CUGs (bijvoorbeeld, op elke pagina) kan op de behoefte aan een model van de douanevergunning wijzen dat potentieel beter geschikt is om de specifieke veiligheidsbehoeften van de toepassing en de inhoud te passen.

  • Beperk de paden die worden ondersteund voor CUG-beleid tot een paar bomen in de opslagplaats, zodat u de prestaties kunt optimaliseren. Bijvoorbeeld, sta slechts CUGs onder de /content knoop toe zoals verscheept als standaardwaarde sinds AEM 6.3.

  • Het beleid van de CUG wordt ontworpen om gelezen toegang tot een kleine reeks principes te verlenen. De behoefte aan een enorm aantal principes kan kwesties in de inhoud of toepassingsontwerp benadrukken en zou moeten worden herzien.

Verificatie: de auteitsvereisten definiëren

De authentificatie-verwante delen van de eigenschap van CUG laten u bomen merken die authentificatie vereisen en naar keuze een specifieke login pagina specificeren. Conform de vorige versie kunt u met de nieuwe implementatie structuren markeren die verificatie vereisen in de opslagplaats voor inhoud. Het laat ook voorwaardelijk synchronisatie met Sling org.apache.sling.api.auth.Authenticator verantwoordelijk voor uiteindelijk het afdwingen van het vereiste en het opnieuw richten aan een login middel toe.

Deze vereisten worden geregistreerd met de Authenticator door de dienst OSGi die het sling.auth.requirements registratiebezit verstrekt. Deze eigenschappen worden dan gebruikt om de authentificatievereisten dynamisch uit te breiden. Voor meer details, raadpleeg de Verschuivende documentatie.

De verificatievereiste definiëren met een specifiek mixertype

Om veiligheidsredenen vervangt de nieuwe implementatie het gebruik van een residuele JCR-eigenschap door een speciaal mixintype met de naam granite:AuthenticationRequired , dat één optionele eigenschap van het type STRING definieert voor het aanmeldingspad granite:loginPath . Alleen wijzigingen in de inhoud met betrekking tot dit type mix leiden tot een update 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() -aanroep om effect te sorteren.

Hetzelfde geldt voor de eigenschap granite:loginPath . 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 toont niet het gewenste effect en het bezit wordt genegeerd door de manager verantwoordelijk voor het bijwerken van de registratie OSGi.

NOTE
Het instellen van de eigenschap voor het aanmeldingspad is optioneel en alleen nodig als de structuur waarvoor verificatie is vereist, niet kan terugvallen op de standaardaanmeldingspagina of een andere overgeërfde aanmeldingspagina. Zie de Evaluatie van Login Weghieronder.

Registreren van de Vereiste van de Authentificatie en Login Weg met de Verschuivende 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, is het gebonden aan een overeenkomstige configuratie die de gesteunde wegen bepaalt (zie de Opties van de Configuratie hieronder). Daarom veroorzaken slechts veranderingen binnen het werkingsgebied van deze gesteunde wegen een update van de registratie OSGi, elders zowel het mixintype als het bezit worden 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 de Verschuivende Authentificatie - de documentatie van het Kadervoor details hoe het Sling het authentificatievereiste afdwingt.

Wanneer u het mixintype granite:AuthenticationRequired toevoegt binnen de geconfigureerde ondersteunde paden, wordt de OSGi-registratie van de verantwoordelijke handler bijgewerkt met een nieuwe, aanvullende vermelding in de eigenschap sling.auth.requirements . Als een bepaalde autorisatieplicht de optionele granite:loginPath -eigenschap opgeeft, wordt de waarde ook geregistreerd bij de Authenticator met een '-'-voorvoegsel dat van autorisatievereiste moet worden uitgesloten.

Evaluatie en overerving van de authenticatievereiste

De verificatievereisten voor Apache Sling worden overgenomen door 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

De evaluatie van de login weg en redirect aan het overeenkomstige middel op authentificatie is een implementatiedetails van de Handler van de Authentificatie van de Selecteur van de Aanmelden van de Adobe Granite ( com.day.cq.auth.impl.LoginSelectorHandler), die een Apache Sling AuthenticationHandler is die met AEM door gebrek wordt gevormd.

Bij het aanroepen van AuthenticationHandler.requestCredentials probeert deze handler de aanmeldingspagina voor toewijzingen te bepalen waarnaar de gebruiker wordt omgeleid. Dit omvat de volgende stappen:

  • Onderscheid tussen verlopen wachtwoord en behoefte aan regelmatige login als reden voor omleiding;

  • Als u zich regelmatig aanmeldt, wordt getest of een aanmeldingspad in de volgende volgorde kan worden verkregen:

    • vanuit de LoginPathProvider, zoals geïmplementeerd door de nieuwe com.adobe.granite.auth.requirement.impl.RequirementService ,
    • van de oude, afgekeurde implementatie van de GOS,
    • op basis van de aanmeldingspagina-toewijzingen, zoals gedefinieerd met de LoginSelectorHandler ,
    • en ten slotte, vallen terug naar de StandaardAanmeldingspagina, zoals die met LoginSelectorHandler wordt bepaald.

  • Wanneer een geldig login weg door de hierboven vermelde vraag werd verkregen, wordt het verzoek van de gebruiker opnieuw gericht aan die pagina.

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

  • Registratie van aanmeldingspaden is afhankelijk van het onderscheid tussen verlopen wachtwoord en de behoefte aan regelmatige aanmelding als reden voor omleiding

  • Als u zich regelmatig aanmeldt, wordt getest of een aanmeldingspad in de volgende volgorde kan worden verkregen:

    • van de LoginPathProvider zoals geïmplementeerd door de nieuwe com.adobe.granite.auth.requirement.impl.RequirementService ,
    • van de oude, afgekeurde implementatie van de GOS,
    • op basis van de aanmeldingspagina-toewijzingen zoals gedefinieerd met de LoginSelectorHandler ,
    • en ten slotte terugvallen naar de standaardaanmeldingspagina zoals gedefinieerd met de LoginSelectorHandler .

  • Wanneer een geldig login weg door de hierboven vermelde vraag werd verkregen, wordt het verzoek van de gebruiker opnieuw gericht aan die pagina.

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

NOTE
De evaluatie wordt slechts uitgevoerd voor verzoeken verbonden aan middelen die met in de gevormde gesteunde wegen worden gevestigd. Voor andere verzoeken zullen de alternatieve manieren om de login weg te bepalen worden geëvalueerd.

Aanbevolen procedures

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

  • Vermijd het nesten authentificatievereisten: het plaatsen van één enkele auth-required teller aan het begin van een boom zou voldoende moeten zijn en aan de volledige subtree worden geërft die door de doelknoop wordt bepaald. Aanvullende verificatievereisten binnen die structuur moeten als overbodig worden beschouwd en kunnen leiden tot prestatieproblemen bij de evaluatie van de verificatievereisten binnen Apache Sling. Met de scheiding van vergunning en authentificatie-verwante gebieden van de GIDS, is het mogelijk om gelezen toegang door GG of andere soorten beleid te beperken terwijl het handhaven van authentificatie voor de volledige boom.

  • Inhoud van een modelopslagplaats zodanig dat de verificatievereisten van toepassing zijn op de gehele boomstructuur zonder dat geneste substructuren opnieuw van de vereiste hoeven te worden uitgesloten.

  • U voorkomt dat u redundante aanmeldingspaden opgeeft en vervolgens registreert:

    • vertrouwen op overerving en vermijd het definiëren van geneste aanmeldingspaden;
    • het optionele aanmeldingspad niet instellen op een waarde die overeenkomt met de standaardwaarde of een overgeërfde waarde,
    • ontwikkelaars van toepassingen moeten vaststellen welke aanmeldingspaden moeten worden geconfigureerd in de algemene configuraties van het aanmeldingspad (zowel de standaardconfiguratie als de toewijzingen) die aan de LoginSelectorHandler zijn gekoppeld.