Enabling SSO with CQ5 – Part II

In first part of our tri-part blog series ,  we discussed about the installation and configuration of Shibboleth IdP. We’ll be focusing on the following two use cases :

Use-Case I : Protecting CQ5 author instance when CQ5 acts as a service provider (SP).

Use-Case II: Protecting any published resource/website.
This blogpost will target to provide the solution for the first use case and provide a way to protect CQ5 author instance.
Basic Workflow: 
When user accesses a protected resource, the SP determines if the user has an active session. If there is no valid session, SP will prepare an authentication request and send that SAML authentication request to IdP. Shibboleth IdP will check for valid session on its end, if no session exists, login screen will be presented to the user to enter the login credentials. IdP will in turn request LDAP for user credentials, fetches the necessary information, generates a SAML response and send it to SP. User is now trying again to access the protected resource, but this time the user has a session and SP knows who they are. SP will service the user’s request and send back the requested data.
AEM provides support for the SAML 2.0 Authentication Request and can act as a SAML service provider.
Necessary Steps  : 
  1. Installing LDAP Server.
  2. Installing Shibboleth IdP.
  3. Installing Apache tomcat on Ubuntu.
  4. Configuring Shibboleth IdP.
  5. Creating the SP’s metadata file (AEM in this case )  and providing it to IdP.
  6. AEM configuration.
  7. Accessing AEM author instance.
Steps 1-4 have already been covered in Part  I. Subsequent steps are explained below :
  1. Creating the SP’s metadata file (AEM in this case ) and providing it to IdP.
  • As AEM is acting as an SP, it needs to provide it’s metadata file to IdP. Create and open a file say <SAML_IDP_HOME>metadata/adobecq.xml and paste the below :
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://sp.intelligrape.com">

<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SPInfo">
//copy the public key from <SAML_IDP_HOME>/credentials/idp.crt and paste here

Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/SOAP" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/Redirect" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/POST" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
Location="http://idp.intelligrape.com/Shibboleth.sso/SLO/Artifact" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:4502/saml_login" index="1"/>
  • In relyingParty.xml, we need to specify the details of IdP’s metadata and any other service provider’s metadata file that relies on our IdP. IdP’s metadata file is already provided in Part I. While specifying the relying party and metadata of AEM (SP), value of Provider attribute in <rp:RelyingParty> tag should be the same as that of EntityId specified in above metadata file. Also, change encryptAssertions attribute to “never”.

    <rp:RelyingParty id="sp.intelligrape.com" provider="https://sp.intelligrape.com" defaultSigningCredentialRef="IdPCredential"
    <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true"
    assertionLifetime="PT5M" assertionProxyCount="0"
    signResponses="never" signAssertions="always"
    encryptAssertions="never" encryptNameIds="never"
    <rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile"
    signResponses="never" signAssertions="always"
    encryptAssertions="<strong>never</strong>" encryptNameIds="never"/>
    <rp:ProfileConfiguration xsi:type="saml:SAML2LogoutRequestProfile"
  • Provide the AEM’s metadata file created in above step to IdP:

<metadata:MetadataProvider id="CQMETADATA" xsi:type="metadata:FilesystemMetadataProvider"
maxRefreshDelay="P1D" />
  1.  AEM configuration.

For better understanding of SAML 2.0 Authentication Handler, please go through the official documentation . As mentioned in documentation, we need to provide the public and private keys to AEM. After creating a node named saml under /etc/key

  • Create a binary property idp_cert inside this node and upload the idp.crt file from <SAML_IDP_HOME>/credentials/idp.crt path.
  • Create a binary property private inside this node .Upload the below mentioned  newly converted key here.The private key must be in PKCS8 format.  To convert a PEM encoded private key to PKCS8 with openssl :
openssl pkcs8 -topk8 -inform PEM -outform DER -in idp.key  -nocrypt &amp;gt; pkcs8.key

where idp.key is the key that needs to be converted and pkcs8.key is the resulted key after conversion.

  • Update the ReferrerFilter,add the <IDP Hostname> in allow hosts property.

In Adobe Granite SAML 2.0 Authentication handler :

  • Set the IdP URL to the path where the SAML authentication request should be sent to or simply paste the below : https://idp.intelligrape.com:8443/idp/profile/SAML2/POST/SSO
  • Set the SP provider id to the ID specified in above metadata file (adobecq.xml) i.e. https://sp.intelligrape.com 

  • Uncheck the Use Encryption property in Adobe Granite SAML 2.0 Authentication Handler.

  • User Id attribute’s value should be the same as the ID of the <SAML Attribute > that contains the user id to authenticate the user.

  • For GroupMembership property , provide the id of the <SAML Attribute > here which will contain the list of groups to which the user will be added to after creation. You can add an attribute called “OU” in user profiles maintained in LDAP. Value of this attribute should be the valid group name present in CRX. Make sure you release the attribute and do the necessary configuration needed in <SAML_IDP_HOME>/conf/attribute-resolver.xml and <SAML_IDP_HOME>/conf/attribute-filter.xmlfiles. Refer Part I for more details. Please note that the value of the GroupMembership property should be the same as you provide the ID of the attribute “OU” in attribute-resolver.xml file.

  1. Accessing AEM author instance. 
  • Making a request to AEM at http://<host&gt;:<port>/ should redirect to IdP login page . Try to login with valid user profiles maintained in LDAP. You should be able to login if credentials are valid and all the above configuration is correct.

Troubleshooting Steps:

  1. After getting the IdP login screen, you log in using an LDAP user credential and are presented with a 404 error code and an error stack trace on welcome page.

This means that the imported user does not have appropriate READ permissions. You could give READ permission to this user, although the appropriate way would be to give READ permission to the group (say “iggroup”) to which imported LDAP users are assigned as members.It can be achieved by creating a group “iggroup” as member of the “contributor” group so that “iggroup” inherits the default permissions from the “contributor” group. In SAML authentication handler service , we specify the group membership attribute which will contain the list of groups the newly created user will be added to. To achieve this, add an attribute say ou in LDAP user profile , and specify the same attribute name in IdP attribute-filter.xml file. The id specified in attribute-filter.xml will be used as the value for groupMembership attribute in SAML handler.

  1. If IdP login page doesn’t appear , cross check the configuration again.

References :




P.S. This post was originally published on my company’s website.

Hope it helps !! 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s