What is Single Sign-On (SSO) ?
Single Sign-On (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. SSO eliminates further prompts for username/password when the user switches between applications during the same browser session. This helps for logging user activities, monitoring user accounts, disabling user accounts when user leaves an organisation and centralised password management.
Enabling AEM author/publish for SP-initiated SSO
In this post we look into the pre-requisites for enabling SSO with SAML 2.0 authentication for AEM author. These pre-requisites are based on the on-boarding process with PingFederate as IDP. But the process is broadly similar for other Identity Providers supporting SAML 2.0 standard. The same author configuration & process can be followed for publish as well. Normally, users login to AEM author/publish instances with credentials such as username/password provided by AEM admins. However, with AEM’s Adobe Granite SAML 2.0 Authentication Handler, users can login with their organisation credentials for seamless SSO experience.
What is an IDP/SP?
For the purposes of this post – Identity Provider (IDP) is PingFederate and Service Provider (SP) is AEM author/publish app.
Why SP-initiated login?
SAML protocol provides 2 types of login IDP-initiated and SP-initiated.
In IDP-initiated login, an organisation assigns url to an author/publish applications (this url is also known as Vanity URL). IDP url can be in the form <appName>.sso.domain.com. Accessing this url in the browser triggers SSO login flow and returns SAML response to browser creating session for this user. However, this IDP url is not preferred because it does not allow bookmarking and not widely used by AEM developers. Moreover, IDP login is also considered as unsolicited login in some organisations.
Typically, a dev author url is in the form http://dev.cq.author.domain.com:4502. This url is well-known to AEM developers and used routinely to access the application. Accessing this url triggers SAML auth request that triggers SSO login flow which authenticates the user and returns SAML response, creating browser session for the user. This explicit SAML request/response is preferred by many organisations as it enables better audit tracing and SP application is in better control of the SAML configuration.
Process and Pre-requisites
- Every organisation has some form of SSO on-boarding process. The federated authentication is provided by teams that control and manage LDAP/AD user accounts. Figure out whom to contact to initiate SSO on-boarding process for your AEM author instance.
- Assign an SP Entity ID for AEM author instance, eg http://dev.cq.author.domain.com:4502 (note: the SP Entity ID is same as url in this case). Provide this EnityID to Ping admins (Entity ID is a unique ID that identifies author instance within IDP)
- Provide Assertion Consumer Service (ACS) url for your AEM author application to Ping admins.
If you decide to apply security from the root “/” path, ACS url is http://dev.cq.author.domain.com:4502/saml_login
If you decide to apply security from “/content”, ACS url is http://dev.cq.author.domain.com:4502/content/saml_login
- Ensure ‘SP Profile’ option is enabled for AEM author instance in PingFederate admin console.
- Receive IDP certificate (usually with .crt file extension) and IDP metadata.xml file from PingFederate admins.
- At this point a PingFederate connection would have been created for your AEM author instance.
- If the IDP certificate has .crt extension, then rename the file to .cer extension. This can be done simply on the command prompt. For example in windows, rename idp_cert.crt idp_cert.cer
- From the IDP metadata.xml received, note down IDP Login & IDP Logout urls.
For example, IDP Login url – https://federation.domain.com/idp/SSO.saml2
IDP Logout url – https://federation.domain.com/idp/logout
- Let the Identity Provider know to receive following SAML attributes Mail, FirstName, LastName
- Request Identity Provider to configure user ID value in SAML’s Subject:NameId tag.
This helps in auto-provisioning users into CRX repository.
The user ID in this case is the unique Identity that an organisation identifies its users. The CRX repository uses the same user ID to to uniquely identity AEM users. For example, If John Roberts is AEM developer then probably their user ID will be jroberts
- Optionally request Identity Provider to configure groupMembership attributes values that this user belongs to.
In many organisations every LDAP/AD user is member of certain group by default. AEM admins may want to leverage these groups instead of creating new ones in CRX repository.
Enabling SSO in AEM is not merely configuration changes, it is an interactive process with Identity Provider and includes exchange of IDP/SP metadata. In the case of AEM author/publish applications, SP metadata is not generated automatically. This means AEM admins should be armed with pre-requisites to enable SSO with SAML 2.0 authentication. At a minimum SP Entity ID, Assertion Consumer Service url, login type (IDP-init or SP-init), required attributes in SAML response are to be agreed with Identity Provider. Once a profile connection is provisioned at IDP and metadata & certificate received, the AEM author instance can be configured. The AEM author configuration details will be discussed in Part 2.