Registration, Login, and User Profile registration-login-and-userprofile

Introduction introduction

Web applications often provide account management features for end users to register on a website, which persists their user data information, allowing them to login in the future and enjoy a consistent experience. This article describes the following concepts for AEM as a Cloud Service:

Registration registration

When an end-user registers for an account on an AEM application, a user account is created on the AEM Publish service, as reflected on a user resource under /home/users in the JCR repository.

There are two approaches to implementing registration, as described below.

AEM Managed aem-managed-registration

Custom registration code can be written that takes, minimally, the user’s username and password, and creates a user record in AEM which can then be used to authenticate against during login. The following steps are typically used to construct this registration mechanism:

Prerequisite:

For the above-described logic to function correctly, please enable data synchronization by submitting
a request to Customer Support indicating the appropriate program and environments.

External external-managed-registration

In some cases, registration or user creation has previously happened in infrastructure outside of AEM. In that scenario, the user record is created in AEM during login.

Login login

Once an end-user is registered on the AEM Publish service, these users can log in to have authenticated access (using AEM authorization mechanisms) and persisted, user-specific data such as profile data.

Implementation implementation

Login can be implemented with the following two approaches:

AEM Managed aem-managed-implementation

Customers can write their own custom components. To learn more, consider becoming familiar with:

Prerequisite:

For the above-described logic to function correctly, please enable data synchronization by submitting
a request to Customer Support indicating the appropriate program and environments.

Integration with an Identity Provider integration-with-an-idp

Customers can integrate with an IdP (identity provider), which authenticates the user. Integration technologies include SAML and OAuth/SSO, as described below.

SAML BASED

Customers can use SAML-based authentication via their preferred SAML IdP. When using an IdP with AEM, the IdP is responsible for authenticating the user’s credentials and brokering the user’s authentication with AEM, creating the user record in AEM as needed, and managing the user’s group membership in AEM, as described by the SAML assertion.

See documentation for more information about the SAML 2.0 Authentication Handler.

OAuth/SSO

See the Single Sign On (SSO) documentation for information about using AEM’s SSO Authentication Handler Service.

The com.adobe.granite.auth.oauth.provider interface can be implemented with the OAuth provider of your choice.

Prerequisite:

As a best practice, always rely on the idP (Identity Provider) as a single point of truth when storing user-specific data. If the additional user information is stored in the local repository, which is not part of the idP, please enable data synchronization by submitting a request to Customer Support indicating the appropriate program and environments. In addition to data synchronization, in the case of the SAML authentication provider, ensure that dynamic group membership is enabled.

Sticky sessions and Encapsulated Tokens sticky-sessions-and-encapsulated-tokens

AEM as a Cloud Service enables cookie-based sticky sessions, ensuring an end-user is routed to the same publish node on each request. In particular cases, such as user traffic spikes, the encapsulated token feature might increase performance so the user record in the repository does not need to be referenced on each request. If the publish node to which an end-user has an affinity is replaced, their user ID record is available on the new publish node, as described in the data synchronization section below.

To leverage the encapsulated token feature, please submit a request to Customer Support indicating the appropriate program and environments. More importantly, the encapsulated token can not be enabled without data synchronization and must be enabled together. Therefore, carefully review the use case before enabling and ensure the feature is essential.

User Profile user-profile

There are various approaches to persisting data, depending on the nature of that data.

AEM Repository aem-repository

User profile information can be written and read in two ways:

Prerequisite:

For the server-side user profile persistence logic to function correctly, please enable data synchronization by submitting
a request to Customer Support indicating the appropriate program and environments.

Third-party data stores third-party-data-stores

End-user data can be sent to third-party vendors such as CRMs and retrieved via APIs upon the user’s login to AEM and persisted (or refreshed) on the AEM user’s profile node, and used by AEM as needed.

Real-time access to third-party services to retrieve profile attributes is possible, however, it is important to ensure this does not materially impact request processing in AEM.

Prerequisite:

For the above-described logic to function correctly, please enable data synchronization by submitting
a request to Customer Support indicating the appropriate program and environments.

Permissions (Closed User Groups) permissions-closed-user-groups

Publish-tier access policies, also called Closed User Groups (CUGs), are defined in the AEM author, see Creating a Closed User Group. To restrict certain sections or pages of a website from some users, apply the CUGs as needed using the AEM author, as described here, and replicate them to the publish tier.

Independent of login, custom code can also persist and manage a user’s group memberships as required by an organization’s unique requirements.

Data Synchronization data-synchronization

Website end users have an expectation of a consistent experience on every web page request or even when they log in using a different browser, even if unbeknownst to them, they are brought to different server nodes of the publish tier infrastructure. AEM as a Cloud Service accomplishes this by quickly synchronizing the /home folder hierarchy (user profile information, group membership, and so on) across all the nodes of the publish tier.

Unlike other AEM solutions, user and group membership synchronization in AEM as a Cloud Service does not use a point-to-point messaging approach, instead implementing a publish-subscribe approach that does not require customer configuration.

Cache Considerations cache-considerations

Authenticated HTTP requests can be difficult to cache on both the CDN and Dispatcher since they carry the possibility of user-specific state being transferred as part of the request’s response. Inadvertently caching authenticated requests and serving them to other requesting browsers can result in incorrect experiences, or even leaking protected or user data.

Approaches for maintaining high cache-ability of requests while supporting user-specific responses include: