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

Prerequisito:

Affinché la logica sopra descritta funzioni correttamente, abilita la sincronizzazione dei dati inviando
una richiesta all’Assistenza clienti che indica il programma e gli ambienti appropriati.

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:

Prerequisito:

Affinché la logica sopra descritta funzioni correttamente, abilita la sincronizzazione dei dati inviando
una richiesta all’Assistenza clienti che indica il programma e gli ambienti appropriati.

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.

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.

Prerequisito:

Come best practice, considera sempre l’idP (Identity Provider) come un singolo punto di verità per l’archiviazione di dati specifici dell’utente. Se le informazioni utente aggiuntive sono memorizzate nell'archivio locale, che non fa parte dell'idP, abilitare la sincronizzazione dati inviando una richiesta all'Assistenza clienti indicando il programma e gli ambienti appropriati. Oltre alla sincronizzazione dati, nel caso del provider di autenticazione SAML verificare che sia abilitata l'appartenenza al gruppo dinamico 🔗.

Sessioni permanenti e token incapsulati sticky-sessions-and-encapsulated-tokens

AEM as a Cloud Service abilita sessioni permanenti basate su cookie, garantendo che un utente finale venga indirizzato allo stesso nodo di pubblicazione su ogni richiesta. In casi particolari, come i picchi di traffico degli utenti, la funzione del token incapsulato potrebbe migliorare le prestazioni, 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 nel nuovo nodo di pubblicazione, come descritto nella sezione sincronizzazione dati seguente.

Per sfruttare la funzione del token incapsulato, invia una richiesta all’Assistenza clienti indicando il programma e gli ambienti appropriati. Un aspetto ancora più importante è che il token incapsulato non può essere abilitato senza sincronizzazione dati e deve essere abilitato insieme. Pertanto, rivedi attentamente il caso d’uso prima di abilitarlo e assicurati che la funzione sia essenziale.

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:

Prerequisito:

Per il corretto funzionamento della logica di persistenza del profilo utente lato server, abilitare sincronizzazione dati inviando
una richiesta all’Assistenza clienti che indica il programma e gli ambienti appropriati.

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.

Prerequisito:

Affinché la logica sopra descritta funzioni correttamente, abilita la sincronizzazione dei dati inviando
una richiesta all’Assistenza clienti che indica il programma e gli ambienti appropriati.

Autorizzazioni (gruppi di utenti chiusi) permissions-closed-user-groups

I criteri di accesso al livello Publish, denominati anche gruppi di utenti chiusi, sono definiti nell'autore AEM. Vedere Creazione di un gruppo di utenti chiuso. 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.

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 la gerarchia di cartelle /home (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.

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: