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 e rendere troppo semplice per uno sviluppatore non pianificare per tempo una struttura appropriata e i corrispondenti livelli di controllo di accesso (ACL) per i propri contenuti. 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.
In alcuni casi, la sessione di amministrazione non viene utilizzata oppure la funzione viene completamente disabilitata. In questo caso, assicurati di rimuovere completamente la funzione o di adattarla a Codice NOP.
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.
Molti problemi possono essere risolti ristrutturando il contenuto. Durante la ristrutturazione, considera queste semplici regole:
Cambia il controllo dell'accesso
Ottimizzare la struttura del contenuto
Effettua il refactoring del codice per renderlo un servizio appropriato
Inoltre, assicurati che tutte le nuove funzioni sviluppate siano conformi ai seguenti principi:
I requisiti di sicurezza sono alla base della struttura dei contenuti
Utilizzare i tipi di nodo
Rispetta le impostazioni di privacy
/profile
nodo.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:
Ad esempio, invece di applicare jcr:read
il /apps
, applicarlo solo a /apps/*/components/*/analytics
Utilizzare restrizioni
Applica ACL per i tipi di nodo
Limita autorizzazioni
jcr:write
autorizzazione; utilizzare jcr:modifyProperties
inveceSe 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:
Consentono di mappare i servizi agli utenti
Consentono di definire gli utenti dei servizi secondari
Il punto di configurazione centrale è: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl
service-id
= service-name
[":" nome-servizio-secondario]
service-id
è mappato a un risolutore risorse e/o a un ID utente dell’archivio JCR per l’autenticazione
service-name
è il nome simbolico del bundle che fornisce il servizio
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 sarà 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:
Identifica le autorizzazioni necessarie per il servizio, tenendo presente il principio delle autorizzazioni minime.
Controlla se è già disponibile un utente con esattamente la configurazione delle autorizzazioni necessaria. Crea un utente del servizio di sistema se nessun utente esistente soddisfa le tue esigenze. RTC è necessario per creare un utente di servizio. A volte, ha senso creare più utenti di servizi secondari (ad esempio, uno per la scrittura e uno per la lettura) per suddividere ulteriormente l’accesso.
Configurare e testare le ACE per l'utente.
Aggiungi un service-user
mappatura per il servizio e per user/sub-users
Rendi la funzione sling dell’utente del servizio disponibile per il bundle: aggiorna alla versione più recente di org.apache.sling.api
.
Sostituisci il admin-session
nel codice con loginService
o getServiceResourceResolver
API.
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, puoi procedere e aggiungere 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:
Passare a Esplora archivio all'indirizzo https://<server>:<port>/crx/explorer/index.jsp
Accesso come amministratore premendo il tasto Accedi nell’angolo in alto a sinistra dello schermo.
Quindi, crea e assegna un nome all’utente del sistema. Per creare l'utente come utente di sistema, impostare il percorso intermedio come system
e aggiungi sottocartelle facoltative in base alle tue esigenze:
Verifica che il nodo utente del sistema sia visualizzato come segue:
Nessun tipo mixin associato agli utenti del servizio. Ciò significa che non ci saranno criteri di controllo di accesso per gli utenti del sistema.
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"/>
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:
Crea una sottocartella SLING-INF/content sotto la cartella src/main/resources del bundle
In questa cartella, crea un file denominato org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.modified-<some unique="" name="" for="" your="" factory="" configuration="">.xml con il contenuto della configurazione di fabbrica (incluse tutte le mappature utente dei servizi secondari). Esempio:
Creare un SLING-INF/content
cartella sotto il src/main/resources
cartella del bundle;
Crea un file in questa cartella named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml
con il contenuto della configurazione di fabbrica, incluse tutte le mappature utente dei servizi secondari.
A scopo illustrativo, prendere il file denominato 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>
Fai riferimento al contenuto iniziale di Sling nella configurazione di maven-bundle-plugin
nel pom.xml
del pacchetto. Esempio:
<Sling-Initial-Content>
SLING-INF/content;path:=/libs/system/config;overwrite:=true;
</Sling-Initial-Content>
Installa il bundle e assicurati che la configurazione di fabbrica sia installata. Per farlo, segui questi passaggi:
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 avrà 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.
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.
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:
Passa il user-id
nel payload dell’evento e utilizza la rappresentazione.
Vantaggi: Facile da usare.
Svantaggi: Utilizzi ancora loginAdministrative()
. Autentica nuovamente una richiesta già autenticata.
Crea o riutilizza un utente del servizio che ha accesso ai dati.
Vantaggi: Coerente con il progetto corrente. Richiede modifiche minime.
Svantaggi: Necessita di utenti di servizi potenti per essere flessibili, il che può facilmente portare a escalation di privilegi. Evita il modello di protezione.
Passa una serializzazione del Subject
nel payload dell’evento e crea un ResourceResolver
in base a tale argomento. Un esempio potrebbe essere l’utilizzo di JAAS doAsPrivileged
nel ResourceResolverFactory
.
Vantaggi: Pulizia dell'implementazione dal punto di vista della sicurezza. Evita la riautenticazione e funziona con i privilegi originali. Il codice pertinente per la sicurezza è trasparente per il consumatore dell’evento.
Svantaggi: Necessita del refactoring. Anche il fatto che il codice pertinente in materia di sicurezza sia trasparente per il consumatore dell’evento potrebbe causare problemi.
Il terzo approccio è la tecnica di elaborazione preferita.
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.
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.