Tjänstanvändare i Adobe Experience Manager (AEM)

Översikt

Huvudsättet att få en administrativ session eller resurslösare i AEM var att använda SlingRepository.loginAdministrative() och ResourceResolverFactory.getAdministrativeResourceResolver() metoder från Sling.

Ingen av dessa metoder har dock utformats runt princip om minst privilegium och gör det för enkelt för en utvecklare att inte planera för en lämplig struktur och motsvarande åtkomstkontrollnivåer (ACL) för sitt innehåll tidigt. Om det finns en säkerhetslucka i en sådan tjänst leder det ofta till eskalering av behörigheter till admin -användare, även om själva koden inte behöver administratörsbehörighet för att fungera.

Så här fasar du ut administratörssessioner

Prioritet 0: Är funktionen aktiv/nödvändig/borttagen?

Det kan finnas fall där adminsessionen inte används eller där funktionen är helt inaktiverad. Om så är fallet med implementeringen, se till att du tar bort funktionen helt eller passar in den med NOP-kod.

Prioritet 1: Använd begärandesessionen

När det är möjligt kan du ändra funktionen så att den angivna autentiserade begärandesessionen kan användas för att läsa eller skriva innehåll. Om detta inte är möjligt kan det ofta uppnås genom att man tillämpar de prioriteringar som anges nedan.

Prioritet 2: Strukturera om innehåll

Många problem kan lösas genom att innehållet struktureras om. Tänk på följande enkla regler när du omstrukturerar:

• Ändra åtkomstkontroll

  • Se till att de användare eller grupper som verkligen behöver åtkomst faktiskt har åtkomst.

• Förfina innehållsstruktur

  • Flytta den till andra platser, t.ex. där åtkomstkontrollen matchar de tillgängliga begärandesessionerna.
  • Ändra innehållets granularitet,

• Reaktera koden så att den fungerar som den ska

  • Flytta affärslogiken från JSP-kod till service. Detta möjliggör olika innehållsmodellering.

Se även till att alla nya funktioner du utvecklar följer dessa principer:

• Säkerhetskrav bör leda till innehållsstrukturen

  • Åtkomstkontroll ska kännas naturlig
  • Åtkomstkontrollen måste verkställas av databasen, inte av programmet

• Använd nodtyper

  • Begränsa uppsättningen egenskaper som kan anges

• Respektera sekretessinställningar

  • Om det finns privata profiler är ett exempel att inte visa profilbilden, e-postadressen eller det fullständiga namnet som finns på den privata /profile nod.

Strikta åtkomstkontroll

Vare sig du tillämpar åtkomstkontroll vid innehållsomstrukturering eller när du gör det för en ny användare måste du tillämpa striktaste åtkomstkontrollistor. Använd alla möjliga hjälpmedel för åtkomstkontroll:

• I stället för att använda jcr:read på /apps, använd det bara på /apps/*/components/*/analytics

• Använd begränsningar

• Använd åtkomstkontrollistor för nodtyper

• Begränsa behörigheter

  • Om du till exempel bara behöver skriva egenskaper ska du inte ge jcr:write behörighet, använda jcr:modifyProperties i stället

Tjänstanvändare och mappningar

Om ovanstående misslyckas erbjuder Sling 7 en tjänst för Mappning av tjänstanvändare, som gör det möjligt att konfigurera en mappning från paket till användare och två motsvarande API-metoder:

• SlingRepository.loginService()
• ResourceResolverFactory.getServiceResourceResolver()

Metoderna returnerar en session-/resurslösare med endast behörighet för en konfigurerad användare. Dessa metoder har följande egenskaper:

• De tillåter att användare mappar tjänster

• De gör det möjligt att definiera undertjänstanvändare

• Den centrala konfigurationspunkten är: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl

• service-id = service-name [":" subservice-namn]

• service-id mappas till en resurslösare och/eller JCR-databasens användar-ID för autentisering

• service-name är det symboliska namnet på det paket som tillhandahåller tjänsten

Andra Recommendations

Ersätta administratörssessionen med en tjänstanvändare

En tjänstanvändare är en JCR-användare utan lösenord och med en minimiuppsättning behörigheter som krävs för att utföra en viss uppgift. Om du inte anger något lösenord går det inte att logga in med en tjänstanvändare.

Ett sätt att ersätta en administrativ session är att ersätta den med tjänstanvändarsessioner. Den kan också ersättas av flera undertjänstanvändare vid behov.

Om du vill ersätta administratörssessionen med en tjänstanvändare utför du följande steg:

1. Identifiera de behörigheter som krävs för tjänsten, med tanke på principen om minsta behörighet.

2. Kontrollera om det redan finns en användare med exakt den behörighetsinställning du behöver. Skapa en systemtjänstanvändare om ingen befintlig användare matchar dina behov. RTC krävs för att skapa en tjänstanvändare. Ibland kan det vara bra att skapa flera undertjänstanvändare (t.ex. en för att skriva och en för att läsa) för att dela upp åtkomsten ännu mer.

3. Konfigurera och testa ACE:n för din användare.

4. Lägg till en service-user mappning för din tjänst och för user/sub-users

5. Gör tjänsteanvändarens säljfunktion tillgänglig för ditt paket: uppdatera till den senaste versionen av org.apache.sling.api.

6. Ersätt admin-session i koden med loginService eller getServiceResourceResolver API.

Skapa en tjänstanvändare

När du har verifierat att ingen användare i listan över AEM användare kan användas för ditt användningsfall och att motsvarande RTC-problem har godkänts, kan du lägga till den nya användaren i standardinnehållet.

Rekommenderad metod är att skapa en tjänstanvändare som ska använda databasutforskaren på https://<server>:<port>/crx/explorer/index.jsp

Målet är att få en giltig jcr:uuid -egenskap som är obligatorisk för att skapa användaren via en installation av innehållspaket.

Du kan skapa tjänstanvändare genom att:

1. Gå till databasutforskaren på https://<server>:<port>/crx/explorer/index.jsp

2. Logga in som administratör genom att trycka på Logga in i skärmens övre vänstra hörn.

3. Skapa och namnge sedan systemanvändaren. Om du vill skapa användaren som ett system anger du den mellanliggande sökvägen som system och lägg till valfria undermappar efter behov:

   

4. Kontrollera att din systemanvändarnod ser ut så här:

   

   OBSERVERA

   Det finns inga blandningstyper som är associerade med tjänstanvändare. Det innebär att det inte finns några åtkomstkontrollprinciper för systemanvändare.

När du lägger till motsvarande .content.xml i innehållet i ditt paket måste du se till att du har ställt in rep:authorizableId och att den primära typen är rep:SystemUser. Det borde se ut så här:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:rep="internal"
    jcr:primaryType="rep:SystemUser"
    jcr:uuid="4917dd68-a0c1-3021-b5b7-435d0044b0dd"
    rep:principalName="authentication-service"
    rep:authorizableId="authentication-service"/>

Lägga till en konfigurationsändring i ServiceUserMapper-konfigurationen

Om du vill lägga till en mappning från tjänsten till motsvarande systemanvändare skapar du en fabrikskonfiguration för ServiceUserMapper service. För att behålla denna modulära konfiguration kan sådan konfiguration tillhandahållas med Ändringsmekanism för Sling. Det rekommenderade sättet att installera sådana konfigurationer med ditt paket är att använda Inläsning av första innehåll vid försäljning:

1. Skapa en undermapp SLING-INF/innehåll under mappen src/main/resources i paketet

2. I den här mappen skapar du en fil med namnet org.apache.sling.servicusermapping.impl.ServiceUserMapperImpl.changed-<some unique="" name="" for="" your="" factory="" configuration="">.xml med innehållet i din fabrikskonfiguration (inklusive alla användarmappningar för undertjänster). Exempel:

3. Skapa en SLING-INF/content mappen nedanför src/main/resources mapp i ditt paket;

4. Skapa en fil i den här mappen named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml med innehållet i fabrikskonfigurationen, inklusive alla användarmappningar för undertjänster.

   I illustrationssyfte tar du filen med namnet org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-com.adobe.granite.auth.saml.xml:

   <?xml version="1.0" encoding="UTF-8"?>
   <node>
       <primaryNodeType>sling:OsgiConfig</primaryNodeType>
       <property>
           <name>user.default</name>
           <value></value>
       </property>
       <property>
           <name>user.mapping</name>
           <values>
               <value>com.adobe.granite.auth.saml=authentication-service</value>
           </values>
       </property>
   </node>
   

5. Referera det inledande Sling-innehållet i konfigurationen av maven-bundle-plugin i pom.xml av ditt paket. Exempel:

   <Sling-Initial-Content>
      SLING-INF/content;path:=/libs/system/config;overwrite:=true;
   </Sling-Initial-Content>
   

6. Installera paketet och kontrollera att fabrikskonfigurationen är installerad. Du kan göra detta genom att:

   • Gå till webbkonsolen på https://serverhost:serveraddress/system/console/configMgr
   • Sök efter Tillägg till användarmappningstjänsten för Apache Sling-tjänsten
   • Klicka på länken för att se om rätt konfiguration finns på plats.

Hantera delade sessioner i tjänster

Samtal till loginAdministrative() visas ofta tillsammans med delade sessioner. Dessa sessioner hämtas vid aktivering av tjänsten och loggas bara ut när tjänsten har stoppats. Även om detta är vanligt leder det till två problem:

• Säkerhet: Sådana administratörssessioner används för att cachelagra och returnera resurser eller andra objekt som är bundna till den delade sessionen. Senare i anropsstacken kan dessa objekt anpassas till sessioner eller resurslösare med utökad behörighet, och ofta är det inte tydligt för anroparen att det är en administratörssession som de arbetar med.
• Prestanda: I Oak kan delade sessioner orsaka prestandaproblem och du bör inte använda dem.

Den mest uppenbara lösningen för säkerhetsrisken är att helt enkelt ersätta loginAdministrative() ring med loginService() en till en användare med begränsad behörighet. Detta påverkar dock inte eventuella prestandaförsämringar. En möjlighet att begränsa detta är att kapsla in all begärd information i ett objekt som inte har någon koppling till sessionen. Skapa sedan (eller förstör) sessionen på begäran.

Rekommenderad metod är att ändra funktionens API för att ge anroparen kontroll över skapandet/destruktionen av sessionen.

Administrativa sessioner i JSP:er

JSP:er kan inte använda loginService(), eftersom det inte finns någon associerad tjänst. Administrativa sessioner i JSP:er är dock vanligtvis ett tecken på överträdelse av MVC-paradigmen.

Detta kan åtgärdas på två sätt:

1. Omstrukturera innehållet på ett sätt som gör det möjligt att ändra det med användarsessionen.
2. Extraherar logiken till en tjänst som tillhandahåller ett API som sedan kan användas av JSP:n.

Den första metoden är den önskade.

Bearbetningshändelser, replikeringsförprocessorer och jobb

När händelser eller jobb bearbetas, och ibland arbetsflöden, går motsvarande session som utlöste händelsen förlorad. Detta leder till händelsehanterare och jobbbehandlare som ofta använder administrativa sessioner för att utföra sitt arbete. Det finns olika möjliga strategier för att lösa detta problem, vart och ett med sina för- och nackdelar:

1. Skicka user-id i händelsens nyttolast och använd personifiering.

   Fördelar: Lätt att använda.

   Nackdelar: Använder fortfarande loginAdministrative(). Den autentiserar en begäran som redan har autentiserats.

2. Skapa eller återanvänd en tjänstanvändare som har åtkomst till data.

   Fördelar: Enhetlig med den aktuella designen. Behöver minimala förändringar.

   Nackdelar: Behöver kraftfulla tjänstanvändare vara flexibla, vilket enkelt kan leda till eskalering av behörigheter. Omvandlar säkerhetsmodellen.

3. Skicka en serialisering av Subject i händelsens nyttolast och skapa en ResourceResolver baserat på det motivet. Ett exempel är JAAS doAsPrivileged i ResourceResolverFactory.

   Fördelar: Ren implementering ur säkerhetssynpunkt. Det undviker återautentisering och fungerar med de ursprungliga behörigheterna. Kod som är relevant för säkerheten är transparent för händelsens konsument.

   Nackdelar: behöver omfaktorisering. Det faktum att den säkerhetsrelaterade koden som är genomskinlig för händelsekonsumenten också kan leda till problem.

Den tredje metoden är att föredra framför behandlingsteknik.

Arbetsflödesprocesser

I implementeringar av arbetsflödesprocesser förloras motsvarande användarsession som utlöste arbetsflödet. Detta leder till arbetsflödesprocesser som ofta använder administrativa sessioner för att utföra sitt arbete.

För att åtgärda dessa problem rekommenderar vi att samma metoder som anges i Bearbetningshändelser, replikeringsförprocessorer och jobb användas.

Bearbetningsprogram för Sling-POST och borttagna sidor

Det finns några administrativa sessioner som används för att skicka POST-processorimplementeringar. Vanligtvis används administrativa sessioner för att komma åt noder som väntar på att tas bort inom den POST som bearbetas. De är därför inte längre tillgängliga via begärandesessionen. En nod som väntar på att tas bort kan nås för att visa metadata som annars inte ska vara tillgängliga.