1) SAMLThe most common and standard SSO handler is SAML and AEM ships with the SAML 2.0 Authentication Handler. The documentation states it supports:
- signing and encryption of messages
- automatic creation of users
- syncing groups to existing ones in AEM
- Service Provider and Identity Provider initiated authentication
SAML bridges the gap between the Identity Provider (like Okta, Layer7 Siteminder, etc.) and the Service Provider, in this case, AEM and exchanges authentication information specific to the user in the form of a SAML assertion POST. This solution is primarily intended for external visitors. The Adobe documentation provides steps to set up the SAML handler.
Here are the basic steps, per the documentation:
- Setup the IdP – you’ll need the AEM SSO endpoint URL for your application (note it must end in /saml_login) and any attributes you want to be mapped with the assertion POST. In return, you’ll get the IdP URL, the IdP Certificate.
- Add the IdP Certificate to the AEM TrustStore – note the TrustStore password created as well as the cert_alias ID once uploaded. The key detail here: this alias and password must be the same on all publishers in the farm (hint: use packaging to sync the TrustStore).
- Create the KeyStore password for the authentication-service user and optionally upload the private key and certificate chain for added encryption – again ensure the password is the same across the publish farm.
- Configure the SAML OSGI handler. As a best practice, it’s important to maintain the OSGI customizations under source control and associated with a project.
- Update the Referrer Filter to allow POSTS from the IdP host domain – as a security best practice.
- Configure the dispatcher and third-party CDNs for permission sensitive caching rules
- Configure a logger
From here you can further customize the SAML integration to suit just about any needs. The handler allows for the auto-creation of users with mapped profile information from the Identity Provider.
2) SSO Authentication HandlerAnother option, if SAML is not available or does not satisfy requirements, is the AEM SSO Authentication handler. Again, this is an out-of-the-box solution with AEM. This is a more traditional approach to SSO that inspects HTML requests for auto-authentication and authorization. Another server or application performs the login function (the trusted authenticator) and passes the login token to AEM in the form of request headers, secure cookies or parameters. The handler then decodes the token to extract the relevant user information. A good use case for this method would be NTLM authentication so that when a user is logged onto their organizational network, they would be automatically logged-into AEM based on the authentication header information.
To set this up, you simply need to configure the Adobe Granite SSO Authentication Handler with the SSO header details.
Typically, this approach is used to secure full directories under the content structure and would, therefore, be not as flexible in nature as the SAML option. Also, all requests would need to be sent through a web server that runs the SSO agent. This is crucial so that request headers and cookies do not get compromised and open AEM up to vulnerabilities.
3) LDAP as the Identity ProviderIf you prefer to have a more direct SSO integration and available user store, then you can configure AEM to directly connect to an LDAP server like CA Directory, OpenLDAP or Microsoft Active Directory. AEM includes a few OSGI handlers to enable this. A good use-case for this is for an internal, authoring purpose where you would rather use an existing LDAP source for the user store. Users log in through the normal AEM login screen but the credentials are the same as the organizational credentials. This saves time having to manually create each user individually within AEM, a redundant process in this case. It also can utilize LDAP groups to map to AEM groups for role-based permissions.
The steps for this are as follows – refer to this documentation:
1. Configure Apache Jackrabbit Oak LDAP Identity Provider – for connecting directly to an LDAP server and configuring LDAP through SSL
2. Configure Apache Jackrabbit Oak Default Sync Handler – allows for auto syncing users from LDAP, mapping of user properties and groups, default memberships (like community contributors)
3. Configure Apache Jackrabbit Oak External Login Module – this is where the LDAP identity provider and Sync handler are brought together
4. Configure a logger
As a best practice, regular purging of users from CRX, through the JMX Console, is required as they do not get automatically removed when records are removed from the organizational LDAP. Also, it’s important to map the users to a default group upon synchronization (User auto membership) so they have the appropriate permissions upon login (and not get a 404).
4) OAuth authenticationAEM does include an OAuth authentication mechanism as well. This would be used for external applications needing to authenticate against AEM say, for example, content/asset consumption or creation. The benefit with this approach is that access to AEM can be granted to third-party applications on a limited scope basis and it does not require a full login credential. OAuth tokens are issued from the AEM side and can be revoked on demand. Once the client attempts to authenticate against AEM the first time, they are presented with an authorization screen, much like you see with Google or Facebook authentication. The client configuration is pretty straightforward using the AEM Touch UI. Simply configure a new client through the security tools in order to generate the token ID and secret key. These are then shared with the third-party tool for use.
As a security best practice with this approach, the scope of the tokens should be locked down to the bare minimum required so as not to compromise AEM and reviewed regularly to determine if they need to be revoked. Another thing to keep in mind with these OAuth tokens is since they are issued on the publisher side and if there are multiple publishers in a farm, then User Synchronization must be enabled so the token is valid on all servers.
5) Adobe IMS AuthenticationFinally, the latest SSO implementation for AEM is the Identity Managed System based authentication for AEM Managed Services customers, which touts:
“AEM onboarding to the Admin Console will allow AEM Managed Services customers to manage all Experience Cloud users in one console. Users and Groups can be assigned to product profiles associated with AEM instances, allowing them to log in to a specific instance.”
This only supports AEM authors, admins and developers and not for external visitors to public sites. This is a great solution for managing your internal users that have access to multiple Adobe cloud-based products and use AEM with AMS. It’s a blend of using an external repository of users (like LDAP) combined with OAuth. The primary benefit here is you don’t need to create separate user accounts on each AEM authoring instance, the credential can be shared for all (AMS managed) instances.
SSO with AEM can be achieved out-of-the-box with minimal customization on both the author side and for external users on the publisher side through one of these provided options.
