Registrazione, accesso e profilo utente

Introduzione

Le applicazioni Web spesso forniscono funzioni di gestione dell'account per gli utenti finali che si registrano su un sito Web; in questo modo le informazioni sui dati dell'utente vengono conservate, consentendo loro di effettuare l'accesso in futuro e di godere di un'esperienza coerente. Questo articolo descrive i seguenti concetti per AEM as a Cloud Service:

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

Registrazione

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

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

AEM Managed

È possibile scrivere un codice di registrazione personalizzato che comprende, come minimo, il nome e la password dell'utente finale e crea un record utente in AEM che può essere utilizzato per l'autenticazione durante l'accesso. i passaggi di questo meccanismo di registrazione sono:

1. Visualizza un componente AEM personalizzato che raccoglie le informazioni sulla registrazione
2. Dopo l’invio, un utente del servizio con provisioning appropriato viene utilizzato per
   1. Verificare che un utente esistente non sia già registrato, utilizzando uno dei metodifindAuthorizables() delle API di UserManager
   2. Creare un record utente utilizzando uno dei metodicreateUser() delle API UserManager
   3. Mantenere i dati del profilo acquisiti tramite i metodisetProperty() dell'interfaccia Authorizable
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 un utente si sono verificate 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 che un utente finale è registrato sul servizio AEM Publish, può effettuare il login per un accesso autenticato (utilizzando i meccanismi di autorizzazione di AEM) e salvare i dati specifici dell'utente, come i dati del profilo.

Implementazione

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

AEM Managed

I clienti possono creare i propri componenti personalizzati. Per saperne di più, acquisisci familiarità con:

• Il Framework di autenticazione Sling
• E considera di chiedere agli esperti della community AEM informazioni sull’accesso.

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.

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

OAuth/SSO

Consulta la documentazione Single Sign On (SSO) per informazioni sull'utilizzo del servizio di gestione dell'autenticazione SSO di AEM.

L’interfacciacom.adobe.granite.auth.oauth.provider può essere integrata con il provider OAuth desiderato.

Sessioni permanenti e token incapsulati

AEM as a Cloud Service dispone di sessioni permanenti basate su cookie abilitate, che garantiscono che un utente finale venga indirizzato allo stesso nodo di pubblicazione a 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 a ogni richiesta. Se viene sostituito il nodo di pubblicazione con 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 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:

• Utilizzo lato server con com.adobe.granite.security.user Interfaccia UserPropertiesManager, che inserirà 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 nella documentazione.

Archiviazione 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 in base alle esigenze.

È possibile accedere in tempo reale a servizi di terzi per recuperare gli attributi del profilo, 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, sono definiti nell’autore AEM come qui descritto. 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à l'appartenenza al gruppo degli utenti (che devono corrispondere ai CUG sul livello di pubblicazione) e manterrà l'associazione tra l'utente e il gruppo attraverso un record dell'archivio
• 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 l'appartenenza a un gruppo dell'utente in base ai requisiti specifici di un’organizzazione.

Sincronizzazione dati

Gli utenti finali dei siti Web si aspettano un'esperienza coerente a ogni richiesta di pagina o anche quando accedono utilizzando un altro browser, anche se a loro insaputa vengono portati su nodi server diversi dell'infrastruttura a livello di pubblicazione. AEM as a Cloud Service esegue questa operazione sincronizzando rapidamente la /home gerarchia di cartelle (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 as a Cloud Service non utilizza un approccio di messaggistica point-to-point, ma implementa un approccio publish-subscribe che non richiede la configurazione del cliente.

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 inadeguate 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:

• Autorizzazioni AEM Dispatcher sensibili alla cache
• Sling Dynamic Include
• AEM ContextHub

Risorse Business.Adobe.com