Registrering, inloggning och användarprofil

Introduktion

Webbprogram har ofta funktioner för kontohantering så att slutanvändarna kan registrera sig på en webbplats som bevarar användarinformationen, vilket gör att de kan logga in i framtiden och få en konsekvent upplevelse. I den här artikeln beskrivs följande begrepp för AEM as a Cloud Service:

  • Registrering
  • Inloggning
  • Lagra användarprofildata
  • Gruppmedlemskap
  • Datasynkronisering
VIKTIGT

För att de funktioner som beskrivs i den här artikeln ska fungera måste funktionen för synkronisering av användardata vara aktiverad, vilket för närvarande kräver en begäran till kundsupport som anger vilket program och vilken miljö som är lämplig. Om den inte är aktiverad sparas användarinformationen bara under en kort period (1 till 24 timmar) innan den försvinner.

Registrering

När en slutanvändare registrerar sig för ett konto i ett AEM skapas ett användarkonto i AEM Publish-tjänsten, vilket återspeglas på en användarresurs under /home/users i JCR-databasen.

Det finns två sätt att genomföra registreringen, som beskrivs nedan.

AEM hanterad

Du kan skriva en egen registreringskod som minimalt tar slutanvändarens användarnamn och lösenord och skapar en användarpost i AEM som sedan kan användas för att autentisera mot vid inloggning. Följande steg används vanligtvis för att konstruera den här registreringsmekanismen:

  1. Visa en anpassad AEM som samlar in registreringsinformation
  2. Vid inlämningen används en korrekt etablerad tjänstanvändare för att
    1. Verifiera att en befintlig användare inte redan finns, med en av API:erna för UserManager findAuthorizables() metoder
    2. Skapa en användarpost med någon av API:erna för UserManager createUser() metoder
    3. Bevara alla profildata som samlats in med det redigerbara gränssnittets setProperty() metoder
  3. Valfria flöden, som att kräva att användaren validerar sin e-post.

Extern

I vissa fall har registrering eller skapande av användare tidigare skett i infrastruktur utanför AEM. I så fall skapas användarposten i AEM under inloggningen.

Inloggning

När en slutanvändare har registrerats i AEM Publish-tjänsten kan dessa användare logga in för att få autentiserad åtkomst (med hjälp av AEM autentiseringsmekanismer) och beständiga, användarspecifika data som profildata.

Implementering

Inloggning kan implementeras med följande två metoder:

AEM hanterad

Kunderna kan skriva egna komponenter. Om du vill veta mer kan du kanske börja lära dig mer om:

Integrering med en identitetsleverantör

Kunder kan integrera med en IdP (identitetsleverantör) som autentiserar användaren. Integrationstekniken inkluderar SAML och OAuth/SSO, enligt beskrivningen nedan.

SAML-BASERAT

Kunder kan använda SAML-baserad autentisering via SAML IdP. När IdP används med AEM ansvarar IdP för att autentisera slutanvändarens inloggningsuppgifter och förmedla användarens autentisering med AEM, skapa användarposten i AEM efter behov och hantera användarens gruppmedlemskap i AEM, vilket beskrivs i SAML-försäkran.

OBSERVERA

Endast den initiala autentiseringen av användarens autentiseringsuppgifter autentiseras av IdP:en och efterföljande begäranden till AEM utförs med en cookie för AEM inloggningstoken, så länge cookien är tillgänglig.

Mer information om SAML 2.0-autentiseringshanterare.

OAuth/SSO

Se Dokumentation för enkel inloggning (SSO) om du vill ha information om hur du använder AEM SSO Authentication Handler Service.

The com.adobe.granite.auth.oauth.provider -gränssnittet kan implementeras med valfri OAuth-leverantör.

Anteckningssessioner och inkapslade token

AEM as a Cloud Service har aktiverat cookie-baserade klistersessioner, vilket ser till att slutanvändaren dirigeras till samma publiceringsnod vid varje begäran. För att förbättra prestanda är den inkapslade tokenfunktionen aktiverad som standard, så användarposten i databasen behöver inte refereras till vid varje begäran. Om den publiceringsnod som en slutanvändare har en tillhörighet att ersätta, är användar-id-posten tillgänglig på den nya publiceringsnoden, vilket beskrivs i avsnittet Datasynkronisering nedan.

Användarprofil

Det finns olika sätt att se på beständiga data, beroende på vilken typ av data det rör sig om.

AEM

Användarprofilinformation kan skrivas och läsas på två sätt:

  • Användning på serversidan med com.adobe.granite.security.user Gränssnittet UserPropertiesManager som placerar data under användarens nod i /home/users. Se till att sidor som är unika per användare inte cachelagras.
  • Klientsidan som använder ContextHub, enligt beskrivningen i dokumentationen.

Datalager från tredje part

Slutanvändardata kan skickas till tredjepartsleverantörer som CRM och hämtas via API:er när användaren loggar in på AEM och sparas (eller uppdateras) på AEM profilnod, och användas av AEM efter behov.

Åtkomst i realtid till tjänster från tredje part för att hämta profilattribut är möjlig, men det är viktigt att se till att detta inte i väsentlig grad påverkar behandlingen av begäranden i AEM.

Behörigheter (stängda användargrupper)

Åtkomstprinciper på publiceringsnivå, som även kallas stängda användargrupper, definieras i AEM författare som beskrivs här. Om du vill begränsa vissa avsnitt eller sidor på en webbplats för vissa användare, ska du tillämpa användargränssnitten efter behov med hjälp av AEM författare, enligt beskrivningen här, och replikera dem till publiceringsnivån.

  • Om användare loggar in genom att autentisera med en identitetsleverantör (IdP) med SAML, identifierar autentiseringshanteraren användarens gruppmedlemskap (som ska matcha användargrupperna på publiceringsnivån) och behåller kopplingen mellan användaren och gruppen via en databaspost
  • Om inloggning sker utan IdP-integrering kan anpassad kod använda samma databasstrukturrelationer.

Oberoende av inloggning kan den anpassade koden också innehålla och hantera en användares gruppmedlemskap enligt organisationens unika krav.

Datasynkronisering

Slutanvändarna på webbplatsen förväntar sig en enhetlig upplevelse på alla webbsidesförfrågningar eller till och med när de loggar in i en annan webbläsare, även om de inte känner till dem, kommer de till olika servernoder i infrastrukturen på publiceringsnivån. AEM as a Cloud Service gör detta genom att snabbt synkronisera /home mapphierarki (användarprofilinformation, gruppmedlemskap osv.) över alla noder i publiceringsnivån.

Till skillnad från andra AEM lösningar använder synkronisering av användare och grupper i AEM as a Cloud Service inte en metod för att skicka meddelanden från punkt till punkt, utan implementerar i stället en strategi för att publicera prenumerationer som inte kräver någon kundkonfiguration.

OBSERVERA

Som standard är synkronisering av användarprofiler och gruppmedlemskap inte aktiverat och data kommer därför inte att synkroniseras till eller ens bli permanent beständiga på publiceringsnivån. Om du vill aktivera funktionen skickar du en begäran till kundsupport med information om rätt program och miljöer.

Cacheöverväganden

Autentiserade HTTP-begäranden kan vara svåra att cachelagra både i CDN och Dispatcher eftersom de kan medföra att användarspecifikt tillstånd överförs som en del av begäran. Om du av misstag cachelagrar autentiserade begäranden och skickar dem till andra begärande webbläsare kan det leda till felaktiga upplevelser eller till och med läcka skyddade data eller användardata.

Metoder för att behålla hög cache-kapacitet för förfrågningar med stöd för användarspecifika svar är bland annat:

  • AEM Dispatcher Behörighetskänslig cachelagring
  • Sling Dynamic Include
  • AEM ContextHub

På denna sida