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:
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.
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.
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:
findAuthorizables()
metodercreateUser()
metodersetProperty()
metoderI 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.
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.
Inloggning kan implementeras med följande två metoder:
Kunderna kan skriva egna komponenter. Om du vill veta mer kan du kanske börja lära dig mer om:
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.
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.
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 öka 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.
Det finns olika sätt att se på beständiga data, beroende på vilken typ av data det rör sig om.
Användarprofilinformation kan skrivas och läsas på två sätt:
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.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 till tredjepartstjänster i realtid för att hämta profilattribut, men det är viktigt att se till att detta inte i väsentlig grad påverkar behandlingen av förfrågningar i AEM.
Å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, 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.
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.
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.
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: