Friday, December 15, 2023

AEM as a Cloud: IMS based SSO Authentication for Authors

AEM as a Cloud Service integrates Adobe Identity Management Service (IMS) for user verification. Various other Adobe products, including the Adobe Admin Console, also utilize this IMS authentication method. For AEM Authors in AEM as a cloud service, Adobe IMS authentication is activated, a change from previous AEM versions where identity and access management (IAM) settings had to be implemented individually on each AEM author server. With AEM in the cloud, single sign-on (SSO) configurations for AEM Authors and user and group management are centrally handled through the Adobe Admin Console using Adobe IMS.

The Admin Console enables administrators to oversee all users in the Experience Cloud from a single point. Within this console, users and groups are allocated to product profiles linked to a specific AEM as a Cloud Service instance. This arrangement permits them to access that particular instance.

To manage the Identity configurations, the role of a System Administrator is necessary.

Create a new identity Directory.

Either option is viable for enabling the SSO configuration. If Azure AD is selected, complete the setup by logging in as the admin user.

The “Other SAML providers” option facilitates SSO activation with various SAML providers. Once SAML configurations are enabled, you can obtain the ACS URL and Entity ID or choose to download the Adobe metadata file. Enable the required configurations in IDP using the ACS URL and Entity ID or the Adobe Metadata file. Once the IDP configuration is ready, the IDP metadata file can be uploaded to finalize the configurations, ensuring that SAML claims such as FirstName, LastName, Email, and Country Code are appropriately mapped.

You can test the IDP configurations, ensuring that the SSO configurations and claim mappings work as expected.

The subsequent step involves claiming the SSO domain (such as the email domain, for instance, example.com for user@example.com). If necessary, multiple SSO domains can be claimed.

Three methods are available: logging in directly to Azure Active Directory, adding a domain through Google, and adding domains via DNS proof. After verifying the domain, your SSO configurations become active and ready for use.

However, a potential challenge arises if an organization has already claimed or validated the SSO domain (mainly when a company operates with multiple Adobe Admin Console organizations). In such instances, domain validation may fail, resulting in a notification that “This domain has already been claimed.

An alternative is for the organization that has already claimed the domain to approve its use in a different organization. While user and group management remain distinct in this scenario, it’s important to note that the original organization retains control over the authentication configuration, which the new organization will use. To obtain this approval, you should follow the below-specified process.

Initiating this will send a request email to the organization that has previously claimed the domain. Once they approve, the directory becomes active. As mentioned before, no additional authentication-related configurations are necessary. The settings from the organization that initially configured this will be utilized.

SSO via the company IDP is now active. When logging into AEM Author, other Adobe products, or the Admin Console with an email corresponding to the configured domain, users will be redirected to the company’s SSO page — successful login grants access to the intended services.

If the directory configuration is enabled for an organization with pre-existing users, these users must be transitioned to Federated ID, assuming their default authentication was via Enterprise ID. This transition can be efficiently managed in bulk by downloading the user details as a CSV file, making the necessary updates, and then re-uploading the modified CSV.

Download CSV template

Choose the specified directory to download only those users associated with it who require ID-type migration.

Modify the New Identity type to “Federated ID,” update the New Email, and set the New Username to the existing email ID. For the Country code, specify the appropriate code, or use ‘UD’ (Undefined) if specifying a country code is not necessary.

After incorporating the new values for all users, upload the files. The processing might take a while, but you can monitor its progress via the “bulk operation results” section. This change in Identity Type will not affect the existing user permissions.

The SSO configuration is now complete, allowing users to utilize the company SSO to log in to the Adobe Admin Console and AEM Authors.

Select ‘Company or School Account’ on the next screen. This action directs the user to the company IDP. Upon successful login, the user will be redirected to the Admin Console or AEM Authors, depending on the initial request.

Next, follow these high-level steps to enable the necessary permissions for AEM Authors.

Create IMS Groups:

In the Adobe Admin Console, establish IMS Groups to streamline the management of users who need the same level of access. Additionally, appoint Admins to oversee each of these individual groups. Create groups specific to each environment to manage user access.

Place the users into the appropriate groups as needed.

Assign Product Profiles to the Groups:

Assign the Product Profiles to their respective groups. By default, AEM as a Cloud Service creates AEM Admin and AEM User profiles for each environment. Assign the environment specific Admin profile, or user profile, to the corresponding environment-specific groups. The admin profile grants full control over the environment, while the User profile provides basic read-only access to the specific environment. If necessary, additional product profiles can be defined. These product profiles are then synchronized with the AEM servers.

  • AEM Administrators: An AEM administrator is typically assigned to developers, in particular developers who need access to, for example, the development environments. The AEM administrator’s product profile is used to grant administrator privileges in the associated AEM instance.
  • AEM Users: AEM users are the users in your organization who use AEM as a Cloud Service generally to create content. These users need to access AEM to do their tasks. The AEM user's product profile is typically assigned to an AEM content author who creates and reviews the content. This content can be of many types such as pages, assets, publications, and so on. The AEM user's product profile shown below is assigned to these members.

Assign groups that require full administrator access to the corresponding environment-specific Administrator profile. The rest of the users can be added to the environment-specific AEM Users profile.

IMS groups and Members to AEM:

The IMS groups and their associated members are synchronized with the corresponding AEM environment. This membership synchronization occurs whenever a user logs into the system. This process ensures that users are accurately linked to their specific AEM access levels.

Create Corresponding Local Groups in AEM:

In AEM, create local User Groups that correspond to the IMS groups. Clearly define the specific permissions for each of these local groups within the AEM environments.

Assign Local Groups to the Corresponding IMS Groups:

Link the local groups in AEM to the relevant IMS groups. These IMS groups are automatically created and synced in AEM, along with the details of their members from IMS. Utilizing local groups in AEM for permission management, instead of adding users directly to the IMS groups, helps maintain a clear separation between IMS-managed groups and AEM local groups. This approach ensures that the IMS groups handle user membership while the local AEM groups manage the necessary permissions.

Users assigned to a IMS group in the Adobe Admin Console are typically automatically linked to the corresponding local User Group in AEM. This means that when users log into AEM, they acquire the permissions associated with the local User Group that align with their Product Profile. Consequently, when users log in through the SSO, they gain the appropriate access within the AEM system.

User Management Flow — AEM as a Cloud

If needed, you can activate automatic synchronization of IDs between Active Directory or LDAP servers and the identities created within the Adobe Console through the User Sync tool. This tool enables system administrators to align user groups from the customer’s directory with product configurations and user groups in the Admin Console. The User Sync Tool can adaptively map new LDAP groups for user membership, facilitating dynamic user group creation within the Admin Console.

The User Sync Tool is available via the Adobe GitHub repository. As an open-source tool, it offers customization options, allowing customers to tailor it to their needs. This synchronization feature includes dynamically mapping new LDAP groups for user membership in the Admin Console and creating new user groups dynamically.

References:

IMS Support for Adobe Experience Manager as a Cloud Service | Adobe Experience Manager (mktossl.com)

Create a directory for SAML-based identity providers (adobe.com)

Authenticate your users with Microsoft Azure (adobe.com)

Google SSO federation (adobe.com)

Originally published at https://www.albinsblog.com.

Follow me for upcoming blogs follow.

Friday, December 8, 2023

Managing SSL and Domains in AEM as a Cloud Service

 This post will discuss handling SSL and domains when using AEM as a Cloud Service. This is for you if you’ve been wondering about keeping things secure and running smoothly on the cloud. Let’s dive into some easy tips and tricks.

AEM as a Cloud service allows you to manage SSL and domains through a cloud manager.

SSL Management:

As a first step, begin by uploading your SSL certificates to Cloud Manager. refer to SSL Certificate Management Basics — Developers | by Albin Issac | Tech Learnings | Medium for understanding the details of SSL management. At any given time, Cloud Manager will allow a maximum of 50 SSL certificates to be installed. These can be associated with one or more environments across your program and also include any expired certificates. However, some prerequisites exist for the SSL certificates: Domain Validated (DV) or self-signed certificates are not supported. The SSL certificate files must be in PEM format to be installed with Cloud Manager, and the Private Key should be in pkcs8 unencrypted format. For more details on managing SSL certificates in AEM as a Cloud, refer to the guide Introduction to Managing SSL Certificates | Adobe Experience Manager on the Adobe Experience Manager website.

AEM as a Cloud Service supports single domain, SAN, and wildcard certificates via the Cloud Manager.

You can go to cloud manager environments → SSL Certificates →Add SSL Certificates.

Enter a name for the SSL certificate and copy its content. Copy the content of the SSL certificate, you will receive the certificate file from the Certificate Authority (e.g., DigiCert) by following the certificate generation process. Ensure the file is in .pem format; if it’s not, you’ll need to convert it to .pem.

-----BEGIN CERTIFICATE-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----

Copy the content of the private key, ensuring that it is in the non-encrypted pkcs8 format. If your key is in another format, such as OpenSSL, it can be converted to pkcs8. I usually use Key Explorer for this purpose, although OpenSSL can also be used to convert to different formats. These tools provide a quick way to change key formats.

Make sure that the key is not encrypted.

In addition to the actual certificate, you will receive certificate chains from the Certificate Authority (CA), which typically include two types of chain certificates: the Intermediate certificate and the Root certificate. You should arrange the Intermediate and Root certificate contents in the correct order and copy the combined content into the certificate chain field.

-----BEGIN CERTIFICATE-----
Intermediate Certificate
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
Root certificate
-----END CERTIFICATE-----

If the private key is uploaded in a format other than pkcs8, you will encounter an error stating, ‘Private key does not match the certificate.

Once the certificate is successfully uploaded, it becomes available for association with a domain and environment. The SSL certificate can also be updated or deleted as needed.

DNS Management:

Now, you have the ability to add a new custom domain, associate it with an SSL certificate, and assign it to a specific environment. For more detailed information on DNS management in AEM as a Cloud service, please refer to ‘ Adding a Custom Domain Name | Adobe Experience Manager’ in the Adobe Experience Manager documentation. Additionally, for a fundamental understanding of DNS management, consult ‘DNS Management Basics for Web Developers | by Albin Issac | Tech Learnings | Medium.

There are certain limitations when managing custom domains in Cloud Manager. Each environment can support a maximum of 500 custom domains. Custom domain names are accommodated in Cloud Manager for both ‘publish’ and ‘preview’ services in Sites programs, but they are not supported for author services. To add a custom domain name in Cloud Manager, a user must hold either the Business Owner or Deployment Manager role. Additionally, you must be utilizing the out-of-the-box (OOTB) Fastly CDN.

Cloud Manager → Environments → Domains →Add Domain

Enter the fully qualified domain name, such as a test domain (e.g., samplesite-dev.test.com) or a live site (e.g., samplesite.test.com). Then, select the environment where this domain will be active, based on your configuration (e.g., dev, uat, stage, prod). Next, choose the service with which you want to associate the domain, either ‘publish’ or ‘preview’. Finally, select the SSL certificate associated with this domain (only those SSL certificates linked to the specified domain will be listed).

Now, you will receive a TXT record that needs to be configured in your Domain Manager to verify domain ownership.

Now, add the TXT record to your domain using your DNS management system, such as CSC Global, GoDaddy, etc.

Wait for the changes to propagate, which may take some time. You can verify this through online tools or command-line utilities like ‘dig’.

Click ‘Create.’ The TXT record will then be validated. You can also choose to create it first and validate it later, once the changes have propagated, by clicking ‘Verify’ again.

Once the domain is successfully validated, a green checkmark will appear.

Now, return to your Domain Manager and create a CNAME record for your custom subdomain (e.g., www.testdomain1.com) that points to cdn.adobeaemcloud.com. Alternatively, you can add an A-Record instead of a CNAME if you are using a root (APEX) domain. For more details, refer to the ‘Configuring DNS Settings | Adobe Experience Manager’ section in Adobe Experience Manager documentation.

Wait for the changes to take effect. You can verify this through the same online tools or command-line utilities,

Now, click ‘Resolve’ again to configure the domain’s CNAME resolution.

Once resolved, you will see a ‘Resolved Correctly’ message, indicating that the domain is now ready for use.

Enable the necessary Dispatcher configurations to direct the domain to a specific content path.

AEM as a Cloud offers a self-service capability for managing SSL and DNS configurations through Cloud Manager, greatly simplifying the process of handling SSL certificates and DNS settings. It’s important to configure your domain well in advance, as the entire process, including domain validation and resolving through your DNS manager, can take a reasonable amount of time.

As an additional note, I recommend creating a common test domain to manage test domains across different environments. For instance, using test.com allows you to create various subdomains for different environments, such as dev.test.com, uat.test.com, stage.test.com, etc.

site1-dev.test.com
site1-uat.test.com
site1.stage.test.com

Now, create a wildcard certificate that supports *.test.com and upload this certificate to Cloud Manager. It can be used to configure all the test domains across various environments. Additionally, create a SAN (Subject Alternative Name) certificate to support all your live domains.