Utenti del servizio in Adobe Experience Manager (AEM) service-users-in-aem

Panoramica overview

Il modo principale per ottenere una sessione amministrativa o un risolutore risorse in AEM era utilizzare SlingRepository.loginAdministrative() e ResourceResolverFactory.getAdministrativeResourceResolver() metodi forniti da Sling.

Tuttavia, nessuno di questi metodi è stato progettato intorno al principio del privilegio minimo. In questo modo è troppo semplice per uno sviluppatore non pianificare in anticipo una struttura appropriata e i corrispondenti livelli di controllo di accesso (ACL, Access Control Levels) per il contenuto. Se in un servizio di questo tipo è presente una vulnerabilità, spesso si verificano escalation di privilegi admin anche se il codice stesso non necessita di privilegi amministrativi per funzionare.

Come eliminare gradualmente le sessioni di amministrazione how-to-phase-out-admin-sessions

Priorità 0: la funzione è attiva/necessaria/obsoleta? priority-is-the-feature-active-needed-derelict

In alcuni casi, la sessione di amministrazione non viene utilizzata oppure la funzione viene completamente disabilitata. In tal caso, assicurati di rimuovere completamente la funzione o di adattarla a Codice NOP.

Priorità 1: Utilizzare La Sessione Di Richiesta priority-use-the-request-session

Quando possibile, effettua il refactoring della funzione in modo che la sessione di richiesta autenticata specificata possa essere utilizzata per la lettura o la scrittura di contenuti. Se ciò non è fattibile, spesso è possibile realizzarlo applicando le priorità seguenti.

Priorità 2: Ristrutturazione del contenuto priority-restructure-content

Molti problemi possono essere risolti ristrutturando il contenuto. Durante la ristrutturazione, considera queste semplici regole:

Inoltre, assicurati che tutte le nuove funzioni sviluppate siano conformi ai seguenti principi:

Controllo accesso rigoroso strict-access-control

Sia che si applichi il controllo degli accessi durante la ristrutturazione dei contenuti o quando lo si fa per un nuovo utente del servizio, è necessario applicare gli ACL più severi possibili. Usare tutte le possibilità di controllo degli accessi:

Utenti e mappature dei servizi service-users-and-mappings

Se quanto sopra non va a buon fine, Sling 7 offre un servizio di mappatura degli utenti del servizio, che consente di configurare una mappatura bundle-to-user e due metodi API corrispondenti:

I metodi restituiscono un risolutore sessione/risorsa con i privilegi solo di un utente configurato. Questi metodi presentano le seguenti caratteristiche:

Altro Recommendations other-recommendations

Sostituzione della sessione di amministrazione con un utente del servizio replacing-the-admin-session-with-a-service-user

Un utente del servizio è un utente JCR senza password impostata e con un set minimo di privilegi necessari per eseguire un’attività specifica. Se non viene impostata alcuna password, non è possibile effettuare l'accesso con un utente del servizio.

Un modo per rendere obsoleta una sessione amministrativa consiste nel sostituirla con sessioni utente di servizio. Se necessario, può anche essere sostituito da più utenti del servizio secondario.

Per sostituire la sessione di amministrazione con un utente del servizio, è necessario effettuare le seguenti operazioni:

Creazione di un utente del servizio creating-a-new-service-user

Dopo aver verificato che nessun utente nell’elenco degli utenti del servizio AEM è applicabile al tuo caso d’uso e che i corrispondenti problemi RTC sono stati approvati, aggiungi il nuovo utente al contenuto predefinito.

L’approccio consigliato consiste nel creare un utente del servizio che possa utilizzare Esplora archivio all’indirizzo https://<server>:<port>/crx/explorer/index.jsp

L’obiettivo è ottenere un jcr:uuid che è obbligatoria per creare l’utente tramite un’installazione del pacchetto di contenuti.

Per creare utenti del servizio, segui questi passaggi:

Quando aggiungi il file .content.xml corrispondente al contenuto del bundle, assicurati di aver impostato rep:authorizableId e che il tipo principale sia rep:SystemUser. Dovrebbe essere simile al seguente:

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

Aggiunta di una modifica alla configurazione ServiceUserMapper adding-a-configuration-amendment-to-the-serviceusermapper-configuration

Per aggiungere una mappatura dal servizio agli utenti di sistema corrispondenti, creare una configurazione di fabbrica per ServiceUserMapper servizio. Per mantenere modulare questa configurazione, è possibile fornire utilizzando Meccanismo di correzione Sling. Il modo consigliato per installare tali configurazioni con il bundle è utilizzare Caricamento iniziale del contenuto Sling:

Gestione delle sessioni condivise nei servizi dealing-with-shared-sessions-in-services

Chiamate a loginAdministrative() vengono spesso visualizzate insieme alle sessioni condivise. Queste sessioni vengono acquisite al momento dell’attivazione del servizio e vengono disconnesse solo dopo che il servizio è stato arrestato. Anche se si tratta di una pratica comune, ciò comporta due problemi:

La soluzione più ovvia per il rischio di sicurezza è semplicemente sostituire il loginAdministrative() chiama con un loginService() uno a un utente con privilegi limitati. Tuttavia, questo non ha alcun impatto sul potenziale deterioramento delle prestazioni. Una possibilità per mitigare questo consiste nel racchiudere tutte le informazioni richieste in un oggetto che non ha alcuna associazione con la sessione. Quindi, crea (o elimina) la sessione su richiesta.

L’approccio consigliato consiste nel refactoring dell’API del servizio per dare al chiamante il controllo sulla creazione/distruzione della sessione.

Sessioni amministrative in JSP administrative-sessions-in-jsps

Le JSP non possono utilizzare loginService(), perché non è associato alcun servizio. Tuttavia, le sessioni amministrative nelle JSP sono di solito un segno di violazione del paradigma MVC.

Questo problema può essere risolto in due modi:

Il primo metodo è quello preferito.

Elaborazione di eventi, preprocessori di replica e processi processing-events-replication-preprocessors-and-jobs

Durante l’elaborazione di eventi o processi e talvolta di flussi di lavoro, la sessione corrispondente che ha attivato l’evento viene persa. Questo porta i gestori di eventi e gli elaboratori di processi a utilizzare spesso sessioni amministrative per svolgere il proprio lavoro. Esistono diversi approcci possibili per risolvere questo problema, ciascuno con i suoi vantaggi e svantaggi:

Il terzo approccio è la tecnica di elaborazione preferita.

Processi flusso di lavoro workflow-processes

All’interno delle implementazioni dei processi di flusso di lavoro, viene persa la sessione utente corrispondente che ha attivato il flusso di lavoro. Questo porta a processi di flusso di lavoro che spesso utilizzano sessioni amministrative per eseguire il proprio lavoro.

Per risolvere questi problemi, si consiglia di utilizzare gli stessi approcci indicati in Elaborazione di eventi, preprocessori di replica e processi essere utilizzati.

Processori Sling POST e pagine eliminate sling-post-processors-and-deleted-pages

Esistono un paio di sessioni amministrative utilizzate nelle implementazioni del processore sling POST. In genere, le sessioni amministrative vengono utilizzate per accedere ai nodi in attesa di eliminazione all’interno del POST in fase di elaborazione. Di conseguenza, non sono più disponibili tramite la sessione di richiesta. È possibile accedere a un nodo in attesa di eliminazione per divulgare metadati che altrimenti non dovrebbero essere accessibili.