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:
In order for the functionality described in this article to work, the User Data Synchronization feature must be enabled, which at this time requires a request to customer support indicating the appropriate program and environments. If not enabled, user information will be persisted for just a short period (1 to 24 hours) before disappearing.
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.
Custom registration code can be written that takes, minimally, the end 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:
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.
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.
Login can be implemented with the following two approaches:
Customers can write their own custom components. To learn more, consider becoming familiar with:
Customers can integrate with an IdP (identity provider), which authenticates the user. Integration technologies include SAML and OAuth/SSO, as described below.
Customers can use SAML-based authentication via their preferred SAML IdP. When using an IdP with AEM, the IdP is responsible for authenticating the end 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.
Only the initial authentication of the user’s credentials are authenticated by the IdP, and subsequent requests to AEM are performed using an AEM login token cookie, as long as the cookie is available.
See documentation for more information about the SAML 2.0 Authentication Handler.
See the Single Sign On (SSO) documentation for information about using AEM’s SSO Authentication Handler Service.
com.adobe.granite.auth.oauth.provider interface can be implemented with the OAuth provider of your choice.
AEM as a Cloud Service has cookie-based sticky sessions enabled, which ensures that an end-user is routed to the same publish node on each request. In order to increase performance, the encapsulated token feature is enabled by default so the user record in the repository does not need to be referenced on each request. If the publish node which an end-user has an affinity to is replaced, their user id record will be available on the new publish node, as described in the data synchronization section below.
There are various approaches to persisting data, depending on the nature of that data.
User profile information can be written and read in two ways:
com.adobe.granite.security.userInterface UserPropertiesManager interface, which will place data under the user’s node in
/home/users. Make sure that pages that are unique per user are not cached.
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 3rd party services to retrieve profile attributes is possible, however, it is important to ensure this does not materially impact request processing in AEM.
Publish-tier access policies, also called Closed User Groups (CUGs), are defined in the AEM author as described here. In order 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.
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, etc) 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.
By default, user profile and group membership synchronization are not enabled and so data will not be synchronized to or even permanently persisted on the publish tier. To enable the feature, send a request to Customer Support indicating the appropriate program and environments.
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: