Registrering, inloggning och användarprofil registration-login-and-userprofile

Introduktion introduction

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 koncept för AEM as a Cloud Service:

Registrering registration

När en slutanvändare registrerar sig för ett konto i ett AEM program skapas ett användarkonto på den 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 aem-managed-registration

Du kan skriva en egen registreringskod som innehåller användarens användarnamn och lösenord och som 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:

Förutsättning:

Aktivera datasynkronisering genom att skicka in data för att ovanstående logik ska fungera korrekt.
en förfrågan till kundsupport med uppgifter om lämpliga program och miljöer.

Extern external-managed-registration

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 login

När en slutanvändare har registrerats på AEM Publish-tjänst 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 implementation

Inloggning kan implementeras med följande två metoder:

AEM hanterad aem-managed-implementation

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

Förutsättning:

Aktivera datasynkronisering genom att skicka in data för att ovanstående logik ska fungera korrekt.
en förfrågan till kundsupport med uppgifter om lämpliga program och miljöer.

Integrering med en identitetsleverantör integration-with-an-idp

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 en IdP används med AEM ansvarar IdP för att autentisera anvä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.

Mer information om autentiseringshanteraren SAML 2.0 finns i dokumentationen.

OAuth/SSO

Mer information om hur du AEM SSO-autentiseringshanterartjänsten finns i dokumentationen för enkel inloggning (SSO).

Gränssnittet com.adobe.granite.auth.oauth.provider kan implementeras med valfri OAuth-provider.

Förutsättning:

Det bästa sättet är att alltid förlita sig på idP (Identity Provider) som en enda sanning när användarspecifika data lagras. Om den ytterligare användarinformationen lagras i den lokala databasen, som inte är en del av idP, ska du aktivera datasynkronisering genom att skicka en begäran till kundsupport som anger rätt program och miljöer. Förutom datasynkronisering, när det gäller SAML-autentiseringsprovidern, kontrollerar du att dynamiskt gruppmedlemskap är aktiverat.

Anteckningssessioner och inkapslade token sticky-sessions-and-encapsulated-tokens

AEM as a Cloud Service möjliggör cookie-baserade klistersessioner så att slutanvändaren dirigeras till samma publiceringsnod vid varje begäran. I vissa fall, t.ex. vid användartrafik, kan den inkapslade tokenfunktionen öka prestandan så att användarposten i databasen inte behöver refereras till vid varje begäran. Om publiceringsnoden som en slutanvändare har en tillhörighet till ersätts, är användar-ID-posten tillgänglig på den nya publiceringsnoden, vilket beskrivs i avsnittet datasynkronisering nedan.

Om du vill utnyttja den inkapslade tokenfunktionen skickar du en begäran till kundsupporten där det anges vilket program och vilken miljö som är lämplig. Viktigare är att den inkapslade token inte kan aktiveras utan datasynkronisering och måste aktiveras tillsammans. Granska därför användningsexemplet noggrant innan du aktiverar och kontrollera att funktionen är nödvändig.

Användarprofil user-profile

Det finns olika sätt att se på beständiga data, beroende på vilken typ av data det gäller.

AEM aem-repository

Information om användarprofiler kan skrivas och läsas på två sätt:

Förutsättning:

Aktivera datasynkronisering genom att skicka in data för att beständighetslogiken för användarprofilen på serversidan ska fungera korrekt.
en förfrågan till kundsupport med uppgifter om lämpliga program och miljöer.

Datalager från tredje part third-party-data-stores

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.

Det är möjligt att få åtkomst i realtid till tredjepartstjänster för att hämta profilattribut, men det är viktigt att se till att detta inte påverkar behandlingen av förfrågningar i AEM.

Förutsättning:

Aktivera datasynkronisering genom att skicka in data för att ovanstående logik ska fungera korrekt.
en förfrågan till kundsupport med uppgifter om lämpliga program och miljöer.

Behörigheter (stängda användargrupper) permissions-closed-user-groups

Åtkomstprinciper på Publish-nivå, som även kallas för 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, tillämpar du de CUG-grupper som behövs med hjälp av AEM författare, enligt beskrivningen här, och replikerar dem till publiceringsnivån.

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

Datasynkronisering data-synchronization

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 uppnår detta genom att snabbt synkronisera mapphierarkin /home (användarprofilinformation, gruppmedlemskap och så vidare) över alla noder i publiceringsnivån.

Till skillnad från andra AEM använder synkronisering av användare och gruppmedlemskap 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.

Cacheöverväganden cache-considerations

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 svaret på 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: