Utenti del servizio in AEM

Panoramica

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

Tuttavia, nessuno di questi metodi è stato progettato in base al principio del privilegio minimo e rende troppo semplice per uno sviluppatore non pianificare una struttura adeguata e i corrispondenti livelli di controllo degli accessi per il contenuto fin dall'inizio. Se una vulnerabilità è presente in un servizio di questo tipo, porta spesso ad escalation di privilegi per l' admin utente, anche se il codice stesso non avrebbe bisogno di privilegi amministrativi per funzionare.

Modalità di eliminazione delle sessioni di amministrazione

Priorità 0: La funzione è attiva/necessaria/non disponibile?

In alcuni casi la sessione di amministrazione non viene utilizzata, oppure la funzione viene disattivata completamente. Se questo è il caso dell’implementazione, accertatevi di rimuovere completamente la funzione o di adattarla al codice NOP.

Priorità 1: Usa sessione di richiesta

Ogni volta che è possibile, potete reimpostare la funzione in modo che la specifica sessione di richiesta autenticata possa essere utilizzata per leggere o scrivere contenuti. Se ciò non è fattibile, spesso può essere raggiunto applicando le priorità seguenti.

Priorità 2: Contenuto ristrutturazione

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

  • Modifica controllo accesso

    • Assicuratevi che gli utenti o i gruppi che hanno veramente bisogno di accesso abbiano effettivamente accesso;
  • Ottimizzare la struttura del contenuto

    • Spostatela in altre posizioni, ad esempio dove il controllo di accesso corrisponde alle sessioni di richiesta disponibili;
    • Modificare la granularità del contenuto;
  • Ridefinizione del codice in modo che sia un servizio appropriato

    • Sposta la logica aziendale dal codice JSP al servizio. Questo consente di creare diversi modelli di contenuto.

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

  • I requisiti di sicurezza dovrebbero guidare la struttura del contenuto

    • Gestione del controllo dell'accesso
    • Il controllo di accesso deve essere imposto dal repository, non dall'applicazione
  • Utilizzare i tipi di nodo

    • Limita il set di proprietà che è possibile impostare
  • Rispetta le impostazioni di privacy

    • Nel caso dei profili privati, un esempio potrebbe consistere nel non esporre l'immagine del profilo, l'e-mail o il nome completo trovato sul /profile nodo privato.

Controllo severo degli accessi

Sia che si applichi il controllo di accesso durante la ristrutturazione del contenuto, sia che lo si faccia per un nuovo utente di servizi, è necessario applicare gli ACL più restrittivi possibili. Utilizzare tutte le possibili strutture di controllo di accesso:

  • Ad esempio, invece di applicare jcr:read su /apps, applicatelo solo a /apps/*/components/*/analytics

  • Use restrictions

  • Applicazione di ACL per i tipi di nodo

  • Limite autorizzazioni

    • ad esempio, quando è solo necessario scrivere proprietà, non concedere l' jcr:write autorizzazione; use jcr:modifyProperties anziché

Utenti e mappature dei servizi

In caso di errore, Sling 7 offre un servizio di mappatura utenti servizi che consente di configurare una mappatura bundle-utente e due metodi API corrispondenti: e [SlingRepository.loginService()](https://sling.apache.org/apidocs/sling7/org/apache/sling/jcr/api/SlingRepository.html#loginService-java.lang.String-java.lang.String-) [ResourceResolverFactory.getServiceResourceResolver()](https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceResolverFactory.html#getServiceResourceResolver-java.util.Map-) che restituiscono una sessione/risolutore di risorse con i privilegi di un solo utente configurato. Tali metodi hanno le seguenti caratteristiche:

  • Consentono agli utenti di mappare i servizi

  • Consentono di definire utenti di servizi secondari

  • Il punto di configurazione centrale è: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl

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

  • service-id viene 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

Altre raccomandazioni

Sostituzione della sessione di amministrazione con un service-user

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

Un modo per rendere obsoleta una sessione amministrativa consiste nel sostituirla con sessioni utente di servizio. Se necessario, potrebbe essere sostituito da più utenti di servizi secondari.

Per sostituire la sessione di amministrazione con un utente di servizio, è necessario eseguire i seguenti passaggi:

  1. Identificate le autorizzazioni necessarie per il vostro servizio, tenendo presente il principio di meno autorizzazione.

  2. Verificate che sia già disponibile un utente con esattamente la configurazione dell'autorizzazione necessaria. Crea un nuovo utente del servizio di sistema se nessun utente esistente soddisfa le tue esigenze. RTC è necessario per creare un nuovo 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 compartimentare ulteriormente l'accesso.

  3. Configurazione e test di ACE per l’utente.

  4. Aggiungi una service-user mappatura per il servizio e user/sub-users

  5. Rendi disponibile la funzionalità di sling dell'utente del servizio nel pacchetto: aggiornamento alla versione più recente di org.apache.sling.api.

  6. Sostituisci il admin-session codice con le loginService o getServiceResourceResolver le API.

Creazione di un nuovo utente di servizio

Dopo aver verificato che nessun utente nell’elenco degli utenti del servizio AEM sia applicabile al caso d’uso e che i problemi RTC corrispondenti siano stati approvati, potete continuare ad aggiungere il nuovo utente al contenuto predefinito.

L'approccio consigliato consiste nel creare un utente del servizio che utilizzi l'utilità di esplorazione dell'archivio all'indirizzo https://<server>:<porta>/crx/explorer/index.jsp

L'obiettivo è ottenere una jcr:uuid proprietà valida obbligatoria per creare l'utente tramite un'installazione di pacchetti di contenuto.

Puoi creare utenti di servizi:

  1. Per accedere all'archivio delle cartelle all'indirizzo https://<server>:<porta>/crx/explorer/index.jsp

  2. Accesso come amministratore premendo il collegamento Accesso nell’angolo in alto a sinistra dello schermo.

  3. Quindi, create e denominate l'utente del sistema. Per creare l’utente come sistema uno, impostate il percorso intermedio come system e aggiungete sottocartelle facoltative in base alle vostre esigenze:

    chlimage_1-102

  4. Verificare che il nodo utente del sistema sia nel modo seguente:

    chlimage_1-103

    Nota

    Non esistono tipi di mixin associati agli utenti del servizio. Ciò significa che non saranno presenti criteri di controllo degli accessi per gli utenti del sistema.

Quando aggiungete il file .content.xml corrispondente al contenuto del pacchetto, accertatevi di aver impostato il file rep:authorizableId e che il tipo principale sia rep:SystemUser. Dovrebbe essere così:

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

Per aggiungere una mappatura dal servizio agli utenti di sistema corrispondenti, è necessario creare una configurazione di fabbrica per il [ServiceUserMapper](https://sling.apache.org/apidocs/sling7/org/apache/sling/serviceusermapping/ServiceUserMapper.html) servizio. Per mantenere questo modulare tali configurazioni possono essere fornite utilizzando il meccanismo di modificaSling. Il modo consigliato per installare tali configurazioni con il pacchetto consiste nell'utilizzare Sling Initial Content Loading:

  1. Creare una sottocartella SLING-INF/content sotto la cartella src/main/resources del bundle

  2. In questa cartella create un file denominato org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.modified-<un nome univoco per la configurazione di fabbrica>.xml con il contenuto della configurazione di fabbrica (inclusi tutti i mapping utente dei servizi secondari). Esempio:

  3. Create una SLING-INF/content cartella sotto la src/main/resources cartella del pacchetto;

  4. In questa cartella create un file 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, eseguite un 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>
    
  5. Fate riferimento al contenuto iniziale Sling nella configurazione dell’ maven-bundle-plugin elemento nel pom.xml pacchetto. Esempio:

    <Sling-Initial-Content>
       SLING-INF/content;path:=/libs/system/config;overwrite:=true;
    </Sling-Initial-Content>
    
  6. Installate il bundle e accertatevi che la configurazione di fabbrica sia stata installata. È possibile eseguire questa operazione tramite:

    • Passate alla console Web all'indirizzo https://serverhost:serveraddress/system/console/configMgr
    • Ricerca Apache Sling Service User Mapper Service Modifica
    • Fai clic sul collegamento per verificare se è già attiva la configurazione corretta.

Gestione delle sessioni condivise nei servizi

Le chiamate da visualizzare loginAdministrative() spesso vengono visualizzate insieme alle sessioni condivise. Queste sessioni vengono acquisite all'attivazione del servizio e vengono disconnesse solo dopo l'arresto del servizio. Sebbene questa sia una pratica comune, comporta due problemi:

  • ​Sicurezza: Tali sessioni di amministrazione vengono utilizzate per memorizzare nella cache e restituire risorse o altri oggetti associati alla sessione condivisa. Successivamente nello stack di chiamate questi oggetti potrebbero essere adattati alle sessioni o ai risolutori di risorse con privilegi elevati, e spesso non è chiaro al chiamante che si tratta di una sessione di amministrazione con cui stanno operando.
  • ​Prestazioni: Nelle sessioni condivise di Oak possono verificarsi problemi di prestazioni, e attualmente non è consigliato utilizzarli.

La soluzione più ovvia per il rischio di sicurezza è semplicemente sostituire la loginAdministrative() chiamata con loginService() una per un utente con privilegi limitati. Tuttavia, ciò non avrà alcun impatto su eventuali degrado delle prestazioni. Una possibilità di attenuare tale situazione consiste nel racchiudere tutte le informazioni richieste in un oggetto che non ha alcuna associazione con la sessione. Quindi create (o eliminate) la sessione su richiesta.

L'approccio consigliato consiste nel reimpostare l'API del servizio in modo da fornire al chiamante il controllo sulla creazione/distruzione della sessione.

Sessioni amministrative in JSP

JSP non può essere utilizzato loginService(). Nessun servizio associato. Tuttavia, le sessioni amministrative in JSP solitamente sono un segno di una violazione del paradigma MVC.

Questo problema può essere risolto in due modi:

  1. Ristrutturazione del contenuto in modo da consentirne la manipolazione con la sessione utente;
  2. Estrazione della logica in un servizio che fornisce un'API che può quindi essere utilizzata dalla JSP.

Il primo metodo è quello preferito.

Eventi di elaborazione, preprocessori di replica e processi

Quando si elaborano eventi o processi e, in alcuni casi, flussi di lavoro, la sessione corrispondente che ha attivato l’evento in genere viene persa. Ciò comporta che i gestori di eventi e i processori di processo spesso utilizzano sessioni amministrative per svolgere il proprio lavoro. Esistono diversi approcci concepibili per risolvere questo problema, ciascuno con i suoi vantaggi e svantaggi:

  1. Passate il messaggio user-id nel payload dell’evento e utilizzate la rappresentazione.

    ​Vantaggi: Facile da usare.

    ​Svantaggi: Utilizzi ancora loginAdministrative(). autentica di nuovo una richiesta già autenticata.

  2. Creare o riutilizzare un utente del servizio che ha accesso ai dati.

    ​Vantaggi: Coerenza con la progettazione corrente. Ha bisogno di modifiche minime.

    ​Svantaggi: Ha bisogno di utenti di servizi molto potenti per essere flessibili, che possono facilmente portare ad escalation di privilegi. Circola il modello di sicurezza.

  3. Passate una serializzazione dell'evento Subject nel payload dell'evento e create un ResourceResolver elemento basato su tale oggetto. Un esempio potrebbe essere l'utilizzo del JAAS doAsPrivileged nel ResourceResolverFactory.

    ​Vantaggi: Implementazione pulita dal punto di vista della sicurezza. Evita la riautenticazione e funziona con i privilegi originali. Il codice relativo alla sicurezza è trasparente per il consumatore dell'evento.

    ​Svantaggi: Necessità di refactoring. Anche il fatto che il codice di sicurezza pertinente trasparente per il consumatore dell'evento possa causare problemi.

Il terzo approccio è attualmente la tecnica di elaborazione preferita.

Processi di workflow

Nelle implementazioni del processo del flusso di lavoro, la sessione utente corrispondente che ha attivato il flusso di lavoro in genere va persa. Ciò porta ai processi di workflow che spesso utilizzano sessioni amministrative per eseguire il proprio lavoro.

Per risolvere questi problemi, si consiglia di utilizzare gli stessi approcci indicati in Eventi di elaborazione, Preprocessori di replica e Processi .

Processori POST Sling e pagine eliminate

Ci sono un paio di sessioni amministrative utilizzate nelle implementazioni del processore POST Sling. Solitamente, le sessioni amministrative vengono utilizzate per accedere ai nodi in attesa di eliminazione all’interno del POST in elaborazione. Di conseguenza, non sono più disponibili tramite la sessione di richiesta. È possibile accedere a un nodo in attesa di eliminazione per indicare una metada che altrimenti non dovrebbe essere accessibile.

In questa pagina