Registrazione, login e profilo utente

Introduzione

Le applicazioni Web forniscono spesso funzioni di gestione dell'account per consentire agli utenti finali di registrarsi su un sito Web, il che persiste nelle informazioni sul loro profilo utente, consentendo loro di accedere in futuro e di godere di un'esperienza coerente. Questo articolo descrive:

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

Affinché la funzionalità descritta in questo articolo possa funzionare, è necessario abilitare la funzione di sincronizzazione dei dati utente, che in questa fase richiede una richiesta all'assistenza clienti per indicare il programma e gli ambienti appropriati. Se questa opzione non è attivata, le informazioni sugli utenti 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 si riflette 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, in modo minimo, il nome utente e la password dell'utente finale, e crea un record utente in AEM che può essere utilizzato per l'autenticazione durante il login. Per creare questo meccanismo di registrazione vengono in genere utilizzati i seguenti passaggi:

  1. Visualizzare un componente AEM personalizzato che raccoglie le informazioni di registrazione
  2. Dopo l'invio, un utente del servizio con il provisioning corretto viene utilizzato per
    1. Verificare 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. Mantenere qualsiasi dato di profilo acquisito utilizzando i metodi setProperty() dell'interfaccia autorizzabile
  3. Flussi opzionali, ad esempio la richiesta all'utente di convalidare la propria e-mail.

Esterno

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

Accesso

Dopo che un utente finale è registrato nel servizio AEM Publish, questi utenti possono accedere per ottenere l'accesso autenticato (tramite AEM meccanismi di autorizzazione) e i dati specifici dell'utente persistenti, come i dati del profilo.

Implementazione

Il login 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 esegue l'autenticazione dell'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 ID 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.

Per ulteriori informazioni sul gestore di autenticazione SAML 2.0, consultare la documentazione.

OAuth/SSO

Per informazioni sull'utilizzo AEM servizio gestore autenticazione SSO, vedere la documentazione relativa a Single Sign On (SSO).

L'interfaccia com.adobe.granite.auth.oauth.provider può essere implementata con il provider OAuth di vostra scelta.

Sessioni permanenti e token incapsulati

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

Profilo utente

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

AEM repository

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

  • Utilizzo lato server con l'interfaccia com.adobe.granite.security.user UserPropertiesManager dell'interfaccia utente, che posizionerà i dati sotto il nodo dell'utente in /home/users. Verificate 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 per AEM e persistere (o aggiornare) sul nodo del profilo dell'utente AEM, e utilizzati da AEM secondo necessità.

L'accesso in tempo reale ai servizi di terze parti per recuperare gli attributi del profilo è possibile, tuttavia, è importante assicurarsi che questo non influisca materialmente 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 descritti qui. Per limitare determinate sezioni o pagine di un sito Web da parte di alcuni utenti, applicate i CUG in base alle esigenze utilizzando l’autore AEM, come descritto qui, e replicateli sul livello di pubblicazione.

  • Se gli utenti accedono autenticandosi con un provider di identità (IdP) utilizzando SAML, il gestore di autenticazione identificherà le appartenenze del gruppo dell'utente (che devono corrispondere ai CUG nel 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 con IdP, il codice personalizzato può applicare le stesse relazioni di struttura del repository.

Indipendentemente dall’accesso, il codice personalizzato può anche persistere e gestire le appartenenze a un gruppo di utenti, in base alle esigenze specifiche 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 accedono utilizzando un browser diverso, anche se non li conoscono, vengono portati a nodi server differenti dell'infrastruttura del livello di pubblicazione. AEM come Cloud Service, questo avviene sincronizzando rapidamente la gerarchia di cartelle /home (informazioni sul profilo utente, appartenenza al gruppo, ecc.) tra tutti i nodi del livello di pubblicazione.

A differenza di altre soluzioni AEM, la sincronizzazione di membri di utenti e gruppi in AEM come Cloud Service non utilizza un approccio di messaggistica point-to-point, ma implementa un approccio di iscrizione a pubblicazione 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 saranno sincronizzati o persistenti sul livello di pubblicazione. Per abilitare questa funzione, inviare una richiesta all'Assistenza clienti indicando il programma e gli ambienti appropriati.

Considerazioni sulla cache

Le richieste HTTP autenticate possono essere difficili da memorizzare nella cache sia sul CDN che sul dispatcher, poiché comportano la possibilità che lo stato specifico dell'utente venga trasferito come parte della risposta della richiesta. Se si memorizzano inavvertitamente nella cache le richieste autenticate e le si distribuiscono ad altri browser richiedenti, è possibile che si verifichino esperienze errate, o persino che i dati protetti o degli utenti vengano persi.

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

  • AEM Dispatcher Permissions nella cache sensibile
  • Sling Dynamic Include
  • AEM ContextHub

In questa pagina

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free