Registratie, aanmelding en gebruikersprofiel registration-login-and-userprofile

Inleiding introduction

Webtoepassingen bieden veelal functies voor accountbeheer waarmee eindgebruikers zich op een website kunnen registreren, waardoor hun gegevens over gebruikersgegevens behouden blijven. Hierdoor kunnen eindgebruikers zich in de toekomst aanmelden en genieten van een consistente ervaring. In dit artikel worden de volgende concepten voor AEM as a Cloud Service beschreven:

Registratie registration

Wanneer een eindgebruiker zich registreert voor een account op een AEM-toepassing, wordt een gebruikersaccount gemaakt op de AEM Publish-service, zoals wordt weerspiegeld in een gebruikersbron onder /home/users in de JCR-opslagplaats.

Er zijn twee manieren om registratie uit te voeren, zoals hieronder beschreven.

Beheerd door AEM aem-managed-registration

U kunt aangepaste registratiecode schrijven die minimaal de gebruikersnaam en het wachtwoord van de gebruiker nodig heeft en een gebruikersrecord in AEM maakt die vervolgens tijdens de aanmelding kan worden gebruikt voor verificatie. De volgende stappen worden doorgaans gebruikt om dit registratiemechanisme samen te stellen:

Vereiste:

Voor de hierboven beschreven logica om correct te functioneren, gelieve ​ gegevenssynchronisatie ​ toe te laten door voor te leggen
een verzoek aan de Klantenondersteuning met vermelding van het juiste programma en de juiste omgevingen.

Extern external-managed-registration

In sommige gevallen is de registratie of het creëren van gebruikers eerder gebeurd in infrastructuur buiten AEM. In dat scenario wordt het gebruikersrecord tijdens de aanmelding in AEM gemaakt.

Aanmelden login

Zodra een eindgebruiker op de de Publish dienst van AEM wordt geregistreerd, kunnen deze gebruikers login om voor authentiek verklaarde toegang (gebruikend de vergunningsmechanismen van AEM) en voortgezette, gebruikersspecifieke gegevens zoals profielgegevens te hebben.

Implementatie implementation

Aanmelding kan op de volgende twee manieren worden uitgevoerd:

Beheerd door AEM aem-managed-implementation

Klanten kunnen hun eigen aangepaste componenten schrijven. Meer leren, overweeg vertrouwd worden met:

Vereiste:

Voor de hierboven beschreven logica om correct te functioneren, gelieve ​ gegevenssynchronisatie ​ toe te laten door voor te leggen
een verzoek aan de Klantenondersteuning met vermelding van het juiste programma en de juiste omgevingen.

Integratie met een identiteitsprovider integration-with-an-idp

De klanten kunnen met een IdP (identiteitsleverancier) integreren, die de gebruiker voor authentiek verklaart. De technologieën van de integratie omvatten SAML en OAuth/SSO, zoals hieronder beschreven.

GEBASEERDE SAML

De klanten kunnen op SAML-Gebaseerde authentificatie via hun aangewezen SAML IdP gebruiken. Wanneer het gebruiken van een IdP met AEM, is IdP verantwoordelijk voor het voor authentiek verklaren van de geloofsbrieven van de gebruiker en het bemiddelen van de authentificatie van de gebruiker met AEM, die tot het gebruikersverslag in AEM zoals nodig leidt, en het beheren van het de groepslidmaatschap van de gebruiker in AEM, zoals die door de bewering van SAML wordt beschreven.

Zie documentatie voor meer informatie over ​ SAML 2.0 de Handler van de Authentificatie ​.

OAuth/SSO

Zie het ​ Enige Sign On (SSO) documentatie ​ voor informatie over het gebruiken van de Dienst van de Handler van de Authentificatie van AEM SSO.

De interface com.adobe.granite.auth.oauth.provider kan met de leverancier OAuth van uw keus worden uitgevoerd.

Vereiste:

Als beste praktijken, baseer altijd op idP (de Leverancier van de Identiteit) als één enkel punt van waarheid wanneer het opslaan van gebruiker-specifieke gegevens. Als de extra gebruikersinformatie in de lokale bewaarplaats wordt opgeslagen, die geen deel van idP uitmaakt, gelieve ​ gegevenssynchronisatie ​ toe te laten door een verzoek aan de Steun van de Klant voor te leggen die op het aangewezen programma en de milieu's wijst. Naast ​ gegevenssynchronisatie ​, in het geval van de de authentificatieleverancier van SAML, zorg ervoor dat ​ dynamisch groepslidmaatschap ​ wordt toegelaten.

Vaste sessies en ingekapselde tokens sticky-sessions-and-encapsulated-tokens

AEM as a Cloud Service maakt op cookies gebaseerde sticky-sessies mogelijk, zodat een eindgebruiker op elke aanvraag naar hetzelfde publicatieknooppunt wordt gerouteerd. In bepaalde gevallen, zoals gebruikersverkeersspikes, zou de ingekapselde symbolische eigenschap prestaties kunnen verhogen zodat het gebruikersverslag in de bewaarplaats te hoeven niet om op elke aanvraag worden van verwijzingen voorzien. Als publiceer knoop waaraan een eindgebruiker een affiniteit heeft wordt vervangen, is hun verslag van gebruikersidentiteitskaart beschikbaar op nieuw publiceer knoop, zoals die in de ​ hieronder beschreven gegevenssynchronisatie ​ sectie wordt beschreven.

Als u de ingekapselde tokenfunctie wilt gebruiken, dient u bij de Klantenondersteuning een aanvraag in waarin het juiste programma en de juiste omgevingen worden vermeld. Nog belangrijker, kan het ingekapselde teken niet zonder ​ gegevenssynchronisatie ​ worden toegelaten en moet samen worden toegelaten. Controleer daarom zorgvuldig het gebruiksgeval voordat u de functie inschakelt en zorg ervoor dat deze essentieel is.

Gebruikersprofiel user-profile

Afhankelijk van de aard van de gegevens zijn er verschillende benaderingen voor het aanhouden van gegevens.

AEM-opslagplaats aem-repository

Gebruikersprofielgegevens kunnen op twee manieren worden geschreven en gelezen:

Vereiste:

Voor de server-zijlogica van het gebruikersprofiel persistentie om correct te functioneren, gelieve ​ gegevenssynchronisatie ​ toe te laten door voor te leggen
een verzoek aan de Klantenondersteuning met vermelding van het juiste programma en de juiste omgevingen.

Gegevensopslag van derden third-party-data-stores

Eindgebruikersgegevens kunnen naar externe leveranciers, zoals CRM's, worden verzonden en via API's worden opgehaald wanneer de gebruiker zich bij AEM aanmeldt en op het profielknooppunt van de AEM-gebruiker aanhoudt (of vernieuwd) en door AEM worden gebruikt.

Realtime toegang tot derdediensten om profielattributen terug te winnen is mogelijk, echter, is het belangrijk om ervoor te zorgen dit verzoekverwerking in AEM niet wezenlijk beïnvloedt.

Vereiste:

Voor de hierboven beschreven logica om correct te functioneren, gelieve ​ gegevenssynchronisatie ​ toe te laten door voor te leggen
een verzoek aan de Klantenondersteuning met vermelding van het juiste programma en de juiste omgevingen.

Machtigingen (gesloten gebruikersgroepen) permissions-closed-user-groups

Publiceer-rij toegangsbeleid, ook genoemd Gesloten Gebruikersgroepen (CUGs), wordt bepaald in de auteur van AEM, zie ​ Creërend een Gesloten Groep van de Gebruiker ​. Als u bepaalde secties of pagina's van een website van bepaalde gebruikers wilt beperken, past u de CUG's waar nodig toe met de AEM-auteur, zoals hier beschreven, en repliceert u deze naar de publicatielijst.

Onafhankelijk van login, kan de douanecode ook het groepslidmaatschap van een gebruiker voortzetten en beheren zoals vereist door de unieke vereisten van een organisatie.

Gegevenssynchronisatie data-synchronization

Eindgebruikers van een website hebben een verwachting van een consistente ervaring op elk verzoek van een webpagina of zelfs wanneer ze zich aanmelden met een andere browser, zelfs als ze deze niet kennen, worden ze naar verschillende serverknooppunten van de infrastructuur van de publicatielaag gebracht. AEM as a Cloud Service doet dit door de maphiërarchie van /home (gegevens van gebruikersprofielen, groepslidmaatschap enzovoort) snel te synchroniseren over alle knooppunten van de publicatielaag.

In tegenstelling tot andere AEM-oplossingen gebruikt de synchronisatie van gebruikers- en groepslidmaatschappen in AEM as a Cloud Service geen 'point-to-point' berichtaanpak, in plaats van een publicatieabonnementbenadering te implementeren waarvoor geen configuratie van de klant vereist is.

Eisen voor aangepaste code en migratie custom-code-and-migration-requirements

De volgende vereisten zijn alleen van toepassing wanneer aangepaste code wordt gebruikt om lokale gebruikers of lokale groepen te maken. Wanneer Gegevenssynchronisatie is ingeschakeld, moet deze aangepaste code worden bijgewerkt om externe gebruikers en externe groepen met dynamisch groepslidmaatschap te maken.

Vereiste Stappen:

Voor gedetailleerde technische begeleiding bij het bijwerken van douaneimplementaties en het migreren van bestaande gebruikers en groepen, verwijs naar ​ het Migreren aan Externe Identiteit en het Dynamische Lidmaatschap van de Groep ​.

Overwegingen bij cache cache-considerations

De voor authentiek verklaarde HTTP- verzoeken kunnen moeilijk zijn om op zowel CDN als Dispatcher in het voorgeheugen onder te brengen aangezien zij de mogelijkheid van gebruiker-specifieke staat dragen die als deel van de reactie van het verzoek wordt overgebracht. Als geverifieerde verzoeken per ongeluk in de cache worden geplaatst en aan andere browsers worden aangeboden, kan dit leiden tot onjuiste ervaringen of zelfs tot het lekken van beveiligde of gebruikersgegevens.

De benaderingen voor het handhaven van hoge geheim voorgeheugen-capaciteit van verzoeken terwijl het steunen van gebruiker-specifieke reacties omvatten: