Registrazione, accesso e profilo utente registration-login-and-userprofile

Introduzione introduction

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
IMPORTANT
Affinché la funzionalità descritta in questo articolo funzioni, è necessario abilitare la funzione Sincronizzazione dati utente, che al momento necessita di una richiesta all'Assistenza clienti per indicare il programma e gli ambienti appropriati. Se non è abilitata, le informazioni utente vengono mantenute per un breve periodo (da 1 a 24 ore) prima di scomparire.

Registrazione registration

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 aem-managed-registration

È possibile scrivere un codice di registrazione personalizzato che accetta, come minimo, il nome utente e la password dell'utente 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 external-managed-registration

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 login

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 implementation

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

AEM Managed aem-managed-implementation

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

Integrazione con un provider di identità integration-with-an-idp

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 e dell'intermediazione dell'autenticazione dell'utente con AEM, della creazione del record utente in AEM in base alle necessità e della gestione dell'appartenenza al gruppo dell'utente in AEM, come descritto dall'asserzione SAML.

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

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 sticky-sessions-and-encapsulated-tokens

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 user-profile

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

Archivio AEM aem-repository

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 third-party-data-stores

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) permissions-closed-user-groups

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 data-synchronization

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 /home gerarchia di cartelle (informazioni sul profilo utente, appartenenza al gruppo e così via) 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.

NOTE
Per impostazione predefinita, la sincronizzazione del profilo utente e dell’appartenenza al gruppo non è abilitata e pertanto i dati non verranno sincronizzati o memorizzati 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 cache-considerations

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
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab