Gebruikers van de service in AEM

Overzicht

De belangrijkste manier om een administratieve zitting of middeloplosser in AEM te krijgen was het gebruiken van SlingRepository.loginAdministrative() en ResourceResolverFactory.getAdministrativeResourceResolver() door Sling verschafte methoden.

Geen van deze methoden was echter ontworpen rond de beginsel van de minste voorrechten en maken het voor een ontwikkelaar te gemakkelijk om niet voor een juiste structuur en overeenkomstige Niveaus van het Toegangsbeheer (ACLs) voor hun inhoud vroegtijdig te plannen. Als een kwetsbaarheid in zo'n dienst aanwezig is, leidt het vaak tot voorrechtescalaties aan admin gebruiker, zelfs als de code zelf geen administratieve voorrechten zou vereisen om te werken.

Admin-sessies uitfaseren

Prioriteit 0: Is de functie actief/nodig/verwijderd?

Er kunnen zich gevallen voordoen waarin de beheersessie niet wordt gebruikt of de functie volledig is uitgeschakeld. Als dit het geval is met uw implementatie, zorg ervoor u de eigenschap volledig verwijdert of het met past NOP-code.

Prioriteit 1: De aanvraagsessie gebruiken

Wijzig indien mogelijk uw functie, zodat de opgegeven, geverifieerde aanvraagsessie kan worden gebruikt voor het lezen of schrijven van inhoud. Als dit niet mogelijk is, kan het vaak worden bereikt door de onderstaande prioriteiten toe te passen.

Prioriteit 2: Inhoud herstructureren

Veel problemen kunnen worden opgelost door de inhoud te herstructureren. Houd rekening met de volgende eenvoudige regels wanneer u de herstructurering uitvoert:

• Toegangsbeheer wijzigen

  • Zorg ervoor dat de gebruikers of de groepen die werkelijk toegang nodig hebben daadwerkelijk toegang hebben;

• Inhoudsstructuur verfijnen

  • Verplaats het naar andere locaties, bijvoorbeeld waar toegangsbeheer overeenkomt met de beschikbare aanvraagsessies.
  • Wijzig de granulariteit van de inhoud.

• Vernieuw uw code om een juiste service te zijn

  • Verplaats de bedrijfslogica van code JSP naar de dienst. Dit maakt verschillende inhoudmodellen mogelijk.

Ook, zorg ervoor dat om het even welke nieuwe eigenschappen u ontwikkelt zich aan deze principes houdt:

• Beveiligingsvereisten moeten de inhoudstructuur bepalen

  • Het beheer van toegangsbeheer moet natuurlijk zijn
  • Toegangscontrole moet worden afgedwongen door de gegevensopslagplaats, niet door de toepassing

• Gebruik van knooppunten maken

  • De set eigenschappen beperken die kan worden ingesteld

• Privacy-instellingen respecteren

  • In het geval van privéprofielen kunt u bijvoorbeeld de profielafbeelding, e-mail of volledige naam die op de privécomputer is gevonden, niet weergeven /profile knooppunt.

Strikte toegangscontrole

Of u toegangsbeheer terwijl het herstructureren van inhoud toepast of wanneer u het voor een nieuwe de dienstgebruiker doet, moet u strikt mogelijke ACLs toepassen. Gebruik alle mogelijke toegangsbeheerfaciliteiten:

• Bijvoorbeeld in plaats van jcr:read op /appsalleen toepassen op /apps/*/components/*/analytics

• Gebruiken beperkingen

• ACLs voor knooptypes toepassen

• Machtigingen beperken

  • Als u bijvoorbeeld alleen eigenschappen wilt schrijven, moet u de opdracht jcr:write toestemming; gebruiken jcr:modifyProperties in

Gebruikers en toewijzingen van services

Als het bovenstaande ontbreekt, biedt Sling 7 de dienst van de Toewijzing van de Gebruiker van de Dienst aan, die toestaat om een bundel-aan-gebruiker afbeelding en twee overeenkomstige API methodes te vormen: [SlingRepository.loginService()](https://sling.apache.org/apidocs/sling7/org/apache/sling/jcr/api/SlingRepository.html#loginService-java.lang.String-java.lang.String-) en [ResourceResolverFactory.getServiceResourceResolver()](https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceResolverFactory.html#getServiceResourceResolver-java.util.Map-) die een zitting/middeloplosser met de voorrechten van een gevormde slechts gebruiker terugkeren. Deze methoden hebben de volgende kenmerken:

• Zij staan kaartdiensten aan gebruikers toe

• Zij maken het mogelijk om subservicegebruikers te definiëren

• Het centrale configuratiepunt is: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl

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

• service-id is toegewezen aan een resourceoplosser en/of JCR-opslaggebruikers-id voor verificatie

• service-name is de symbolische naam van de bundel die de dienst verleent

Overige Recommendations

De admin-sessie vervangen door een service-gebruiker

Een servicegebruiker is een JCR-gebruiker zonder wachtwoord en met een minimale set rechten die nodig zijn om een bepaalde taak uit te voeren. Als er geen wachtwoord is ingesteld, kan u zich niet aanmelden bij een servicegebruiker.

Een manier om een administratieve zitting te verwerpen is het door de zittingen van de de dienstgebruiker te vervangen. Indien nodig kan de subservice ook door meerdere gebruikers worden vervangen.

Als u de beheersessie wilt vervangen door een servicegebruiker, moet u de volgende stappen uitvoeren:

1. Identificeer de noodzakelijke toestemmingen voor uw dienst, die het beginsel van minste toestemming in mening houden.

2. Controleer of er al een gebruiker beschikbaar is met exact de juiste instellingen voor machtigingen. Maak een nieuwe gebruiker van de systeemservice als geen bestaande gebruiker aan uw wensen voldoet. RTC is vereist om een nieuwe de dienstgebruiker tot stand te brengen. Soms is het handig om meerdere gebruikers van subservices te maken (bijvoorbeeld een voor schrijven en een voor lezen) om de toegang nog verder te compartimenteren.

3. Opstelling en test ACEs voor uw gebruiker.

4. Voeg een service-user toewijzing voor uw dienst en voor user/sub-users

5. Maak de verkoopfunctie van de de dienstgebruiker beschikbaar aan uw bundel: bijwerken naar de meest recente versie van org.apache.sling.api.

6. Vervang de admin-session in uw code met de loginService of getServiceResourceResolver API's.

Een nieuwe servicegebruiker maken

Nadat u hebt gecontroleerd dat geen gebruiker in de lijst met AEM gebruikers van toepassing is voor uw gebruiksscenario en de bijbehorende RTC-problemen zijn goedgekeurd, kunt u doorgaan en de nieuwe gebruiker toevoegen aan de standaardinhoud.

De aanbevolen aanpak is om een servicegebruiker te maken die de verkenner van de repository kan gebruiken op https://<server>:<port>/crx/explorer/index.jsp

Het doel is een geldige jcr:uuid eigenschap die verplicht is om de gebruiker te maken via een installatie van een inhoudspakket.

U kunt servicegebruikers maken door:

1. Ga naar de verkenner van de repository op https://<server>:<port>/crx/explorer/index.jsp

2. Aanmelden als beheerder door op de knop Aanmelden in de linkerbovenhoek van het scherm.

3. Maak vervolgens een systeemgebruiker en geef deze een naam. Als u de gebruiker als systeem wilt maken, stelt u het tussentijdse pad in als system en voeg optionele submappen toe, afhankelijk van uw behoeften:

   

4. Controleer of het systeemgebruikersknooppunt er als volgt uitziet:

   

   OPMERKING

   Merk op dat er geen mixintypes verbonden aan de dienstgebruikers zijn. Dit betekent dat er geen beleid voor toegangsbeheer voor systeemgebruikers zal zijn.

Wanneer u het corresponderende .content.xml toevoegt aan de inhoud van uw bundel, moet u ervoor zorgen dat u de optie rep:authorizableId en dat het primaire type rep:SystemUser. Het moet er als volgt uitzien:

<?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"/>

Het toevoegen van een configuratieamendement aan de configuratie ServiceUserMapper

Om een afbeelding van uw dienst aan de overeenkomstige Gebruikers van het Systeem toe te voegen moet u een fabrieksconfiguratie voor creëren [ServiceUserMapper](https://sling.apache.org/apidocs/sling7/org/apache/sling/serviceusermapping/ServiceUserMapper.html) service. Om deze modulaire configuratie te houden kunnen dergelijke configuraties worden verstrekt gebruikend Sling-wijzigingsmechanisme. U wordt aangeraden dergelijke configuraties met uw bundel te installeren door Eerste inhoud bij verkoop laden:

1. Een submap SLING-INF/content maken onder de map src/main/resources van uw bundel

2. In deze map maakt u een bestand met de naam org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.modified-<some unique="" name="" for="" your="" factory="" configuration="">.xml met de inhoud van uw fabrieksconfiguratie (met inbegrip van alle subservice gebruikerstoewijzingen). Voorbeeld:

3. Een SLING-INF/content map onder de src/main/resources map van de bundel;

4. Maak in deze map een bestand named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml met de inhoud van uw fabrieksconfiguratie, met inbegrip van alle subservice gebruikerstoewijzingen.

   Voor illustratiedoeleinden gebruikt u een bestand dat 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. Verwijs de het Verkopen aanvankelijke inhoud in de configuratie van maven-bundle-plugin in de pom.xml van uw bundel. Voorbeeld:

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

6. Installeer de bundel en zorg ervoor de fabrieksconfiguratie is geïnstalleerd. U kunt dit doen door:

   • Ga naar de webconsole op https://serverhost:serveraddress/system/console/configMgr
   • Zoeken naar Wijziging van de Gebruikerstoewijzingsservice Apache Sling Service
   • Klik op de koppeling om te zien of de juiste configuratie is geïnstalleerd.

Werken met gedeelde sessies in services

verzoekt loginAdministrative() worden vaak samen met gedeelde sessies weergegeven. Deze zittingen worden verworven bij de dienstactivering en slechts het programma geopend nadat de dienst wordt tegengehouden. Hoewel dit gebruikelijk is, leidt het tot twee problemen:

• Beveiliging: Dergelijke beheersessies worden gebruikt om bronnen of andere objecten die aan de gedeelde sessie zijn gebonden, in cache te plaatsen en terug te sturen. Later in de vraagstapel konden deze voorwerpen aan zittingen of middeloplossers met opgeheven voorrechten worden aangepast, en het is vaak niet duidelijk aan de bezoeker dat het een adminzitting is zij met werken.
• Prestaties: Bij gedeelde sessies met eikel kunnen prestatieproblemen optreden en het wordt momenteel afgeraden deze te gebruiken.

De meest voor de hand liggende oplossing voor het veiligheidsrisico is eenvoudigweg de vervanging van de loginAdministrative() bellen met een loginService() een voor een gebruiker met beperkte rechten. Dit heeft echter geen invloed op een mogelijke verslechtering van de prestaties. Een mogelijkheid om dat te beperken is alle gevraagde informatie te verpakken in een object dat geen koppeling heeft met de sessie. Maak vervolgens de sessie op verzoek (of vernietigt deze).

De aanbevolen aanpak bestaat erin de API van de service te herordenen om de beller controle te geven over het maken/vernietigen van de sessie.

Administratieve sessies in JSPs

JSPs kan niet gebruiken loginService(), omdat er geen bijbehorende service is. Administratieve sessies in JSP's zijn echter doorgaans een teken van een schending van het MVC-paradigma.

Dit kan op twee manieren worden opgelost:

1. De inhoud zodanig herstructureren dat de inhoud met de gebruikerssessie kan worden gemanipuleerd;
2. Het halen van de logica aan de dienst die API verstrekt die dan door JSP kan worden gebruikt.

De eerste methode heeft de voorkeur.

Verwerkingsgebeurtenissen, replicatievoorprocessoren en taken

Bij het verwerken van gebeurtenissen of taken en in sommige gevallen van workflows gaat de bijbehorende sessie die de gebeurtenis heeft geactiveerd, meestal verloren. Dit leidt ertoe dat gebeurtenismanagers en baanbewerkers vaak administratieve zittingen gebruiken om hun werk te doen. Er zijn verschillende denkbare benaderingen om dit probleem op te lossen, elk met hun voor- en nadelen:

1. Geef de user-id in de gebeurtenislading en gebruik imitatie.

   Voordelen: Eenvoudig in gebruik.

   Nadelen: Stilstaand gebruik loginAdministrative(). Een aanvraag die al is geverifieerd, wordt opnieuw geverifieerd.

2. Creeer of hergebruik een de dienstgebruiker die toegang tot de gegevens heeft.

   Voordelen: In overeenstemming met het huidige ontwerp. Moet minimaal worden gewijzigd.

   Nadelen: Vereist zeer krachtige de dienstgebruikers om flexibel te zijn, wat tot voorrechtescalaties kan gemakkelijk leiden. Hiermee wordt het beveiligingsmodel omzeild.

3. Geef een serialisatie van de Subject in de gebeurtenislading, en creeer ResourceResolver op basis van dat onderwerp. Een voorbeeld hiervan is het gebruik van de JAAS doAsPrivileged in de ResourceResolverFactory.

   Voordelen: Schone implementatie vanuit veiligheidsoogpunt. Het vermijdt re-authentificatie en het werkt met de originele voorrechten. Beveiligingsrelevante code is transparant voor de consument van het evenement.

   Nadelen: Needs refactoring. Het feit dat de veiligheidsrelevante code transparant is voor de consument van het evenement kan ook tot problemen leiden.

De derde aanpak is momenteel de voorkeurstechniek.

Workflowprocessen

Binnen de implementaties van het werkschemaproces wordt de overeenkomstige gebruikerszitting die het werkschema teweegbracht gewoonlijk verloren. Dit leidt tot werkschemaprocessen vaak gebruikend administratieve zittingen om hun werk uit te voeren.

Om deze problemen op te lossen wordt aanbevolen om dezelfde aanpak te volgen als in Verwerkingsgebeurtenissen, replicatievoorprocessoren en taken worden gebruikt.

Verkoopprocessors en verwijderde POSTEN

Er zijn een paar administratieve zittingen die in de implementatie van de bewerker van de POST worden gebruikt. Meestal worden beheersessies gebruikt om toegang te krijgen tot knooppunten die in afwachting zijn van verwijdering binnen de POST die wordt verwerkt. Daarom zijn ze niet meer beschikbaar via de aanvraagsessie. Een knoop in afwachting van schrapping kan worden betreden om metada vrij te geven die anders niet toegankelijk zou moeten zijn.

Business.Adobe.com-bronnen

Multichannel Communication Ecommerce Integrations Personalized Experiences Customer Communications Asset Collections Content Management System