Registrazione, accesso e profilo utente

Introduzione

Le applicazioni web forniscono spesso funzioni di gestione dell’account che consentono agli utenti finali di registrarsi su un sito web e che persistono le informazioni sui dati utente, consentendo loro di accedere in futuro e di godere di un’esperienza coerente. Questo articolo descrive i seguenti concetti per AEM come Cloud Service:

  • Registrazione
  • Accesso
  • Memorizzazione dei dati del profilo utente
  • Iscrizione al gruppo
  • Sincronizzazione dati
IMPORTANTE

Affinché la funzionalità descritta in questo articolo funzioni, è necessario abilitare la funzione Sincronizzazione dati utente, che al momento richiede una richiesta al supporto clienti per indicare il programma e gli ambienti appropriati. Se non è abilitata, le informazioni utente verranno mantenute per un breve periodo (da 1 a 24 ore) prima di scomparire.

Registrazione

Quando un utente finale si registra per un account su un'applicazione AEM, viene creato un account utente sul servizio AEM Publish, come riportato su una risorsa utente in /home/users nell'archivio JCR.

Esistono due approcci per implementare la registrazione, come descritto di seguito.

AEM gestito

Il codice di registrazione personalizzato può essere scritto che prende, minimamente, il nome utente e la password dell'utente finale, e crea un record utente in AEM che può poi essere utilizzato per l'autenticazione durante l'accesso. I seguenti passaggi vengono generalmente utilizzati per creare questo meccanismo di registrazione:

  1. Visualizza un componente AEM personalizzato che raccoglie le informazioni sulla registrazione
  2. Dopo l’invio, un utente di servizio con provisioning appropriato viene utilizzato per
    1. Verifica che un utente esistente non esista già, utilizzando uno dei metodi findAuthorizables() dell'API UserManager
    2. Creare un record utente utilizzando uno dei metodi createUser() dell'API UserManager
    3. Mantieni i dati del profilo acquisiti utilizzando i metodi setProperty() dell’interfaccia autorizzabile
  3. Flussi facoltativi, ad esempio per richiedere all’utente di convalidare la propria e-mail.

Esterno

In alcuni casi, la registrazione o la creazione di utenti si è verificata in precedenza in infrastrutture al di fuori di AEM. In questo scenario, il record utente viene creato in AEM durante l'accesso.

Accesso

Una volta registrato un utente finale sul servizio AEM Publish, questi utenti possono accedere per avere accesso autenticato (utilizzando AEM meccanismi di autorizzazione) e dati persistenti specifici dell’utente, come i dati del profilo.

Implementazione

L’accesso può essere implementato con i due approcci seguenti:

AEM gestito

I clienti possono scrivere i propri componenti personalizzati. Per saperne di più, è consigliabile acquisire familiarità con:

Integrazione con un provider di identità

I clienti possono integrarsi con un IdP (provider di identità) che autentica l’utente. Le tecnologie di integrazione includono SAML e OAuth/SSO, come descritto di seguito.

BASATO SU SAML

I clienti possono utilizzare l’autenticazione basata su SAML tramite il proprio IDP SAML preferito. Quando si utilizza un IdP con AEM, l'IdP è responsabile dell'autenticazione delle credenziali dell'utente finale e dell'intermediazione dell'autenticazione dell'utente con AEM, della creazione del record utente in AEM secondo necessità e della gestione dell'appartenenza al gruppo dell'utente in AEM, come descritto dall'asserzione SAML.

NOTA

Solo l’autenticazione iniziale delle credenziali dell’utente viene autenticata dall’IdP e le richieste successive a AEM vengono eseguite utilizzando un cookie di token di accesso AEM, purché il cookie sia disponibile.

Consulta la documentazione per ulteriori informazioni sul Gestore autenticazione SAML 2.0.

OAuth/SSO

Per informazioni sull'utilizzo del servizio Gestore autenticazione AEM SSO, consulta la documentazione Single Sign On (SSO) .

Puoi implementare l’interfaccia com.adobe.granite.auth.oauth.provider con il provider OAuth desiderato.

Sessioni permanenti e token incapsulati

AEM come Cloud Service dispone di sessioni permanenti basate su cookie abilitate, che garantiscono che un utente finale venga indirizzato allo stesso nodo di pubblicazione su ogni richiesta. Per migliorare le prestazioni, la funzione del token incapsulato è abilitata per impostazione predefinita, pertanto non è necessario fare riferimento al record utente nell’archivio su ogni richiesta. Se viene sostituito il nodo di pubblicazione a cui un utente finale ha un'affinità, il record del relativo ID utente sarà disponibile sul nuovo nodo di pubblicazione, come descritto nella sezione di sincronizzazione dei dati seguente.

Profilo utente

Esistono diversi approcci ai dati persistenti, a seconda della natura di tali dati.

Archivio AEM

Le informazioni sul profilo utente possono essere scritte e lette in due modi:

  • Uso lato server con l'interfaccia com.adobe.granite.security.user UserPropertiesManager dell'interfaccia, che inserisce i dati sotto il nodo dell'utente in /home/users. Assicurati che le pagine univoche per utente non siano memorizzate nella cache.
  • Lato client che utilizza ContextHub, come descritto da la documentazione.

Archiviazione di dati di terze parti

I dati dell’utente finale possono essere inviati a fornitori di terze parti come CRM e recuperati tramite API al momento dell’accesso dell’utente a AEM e memorizzati (o aggiornati) sul nodo del profilo dell’utente AEM, e utilizzati da AEM in base alle esigenze.

È possibile accedere in tempo reale a servizi di terze parti per recuperare gli attributi del profilo, tuttavia è importante assicurarsi che questo non influisca in modo rilevante sull’elaborazione delle richieste in AEM.

Autorizzazioni (gruppi di utenti chiusi)

I criteri di accesso al livello di pubblicazione, denominati anche gruppi di utenti chiusi (CUG), sono definiti nell’autore AEM come descritto qui. Per limitare alcune sezioni o pagine di un sito web a determinati utenti, applica i CUG necessari utilizzando l’autore AEM, come descritto qui, e replicali sul livello di pubblicazione.

  • Se gli utenti effettuano l'accesso autenticandosi con un provider di identità (IdP) utilizzando SAML, il gestore di autenticazione identificherà le appartenenze al gruppo dell'utente (che devono corrispondere ai CUG sul livello di pubblicazione) e persisterà l'associazione tra l'utente e il gruppo attraverso un record del repository
  • Se l'accesso viene eseguito senza l'integrazione IdP, il codice personalizzato può applicare le stesse relazioni di struttura dell'archivio.

Indipendentemente dall’accesso, il codice personalizzato può anche persistere e gestire le appartenenze a un gruppo di utenti in base ai requisiti specifici di un’organizzazione.

Sincronizzazione dati

Gli utenti finali del sito web si aspettano un’esperienza coerente su ogni richiesta di pagina web o anche quando effettuano l’accesso utilizzando un browser diverso, anche se non sono a loro conoscenza, vengono portati a diversi nodi server dell’infrastruttura del livello di pubblicazione. AEM come Cloud Service esegue questa operazione sincronizzando rapidamente la gerarchia delle cartelle /home (informazioni sul profilo utente, appartenenza al gruppo, ecc.) in tutti i nodi del livello di pubblicazione.

A differenza di altre soluzioni AEM, la sincronizzazione dell’appartenenza di utenti e gruppi in AEM come Cloud Service non utilizza un approccio di messaggistica punto-to-point, ma implementa un approccio di pubblicazione-sottoscrizione che non richiede la configurazione del cliente.

NOTA

Per impostazione predefinita, la sincronizzazione del profilo utente e dell’appartenenza al gruppo non è abilitata e pertanto i dati non verranno sincronizzati o persistono in modo permanente sul livello di pubblicazione. Per abilitare questa funzione, invia una richiesta all’Assistenza clienti indicando il programma e gli ambienti appropriati.

Considerazioni sulla cache

Le richieste HTTP autenticate possono essere difficili da memorizzare in cache sia sulla CDN che sul Dispatcher, in quanto comportano la possibilità che lo stato specifico dell’utente venga trasferito come parte della risposta della richiesta. Memorizzare involontariamente nella cache le richieste autenticate e distribuirle ad altri browser richiedenti può causare esperienze errate o anche la perdita di dati protetti o utente.

Gli approcci per mantenere un'elevata capacità di cache delle richieste e supportare le risposte specifiche dell'utente includono:

  • Memorizzazione in cache sensibile AEM autorizzazioni di Dispatcher
  • Sling Dynamic Include
  • AEM ContextHub

In questa pagina