Enabling SSO with CQ5 – Part II

In the first part of our tri-part blog series, we discussed 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 the CQ5 author instance.

Basic Workflow:
When a 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 a valid session on its end, if no session exists, the 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. The 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 the AEM author instance.

Steps 1-4 have already been covered in Part I. Subsequent steps are explained below :

5. 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 its metadata file to IdP. Create and open a file say <SAML_IDP_HOME>metadata/adobecq.xml and paste the below :

&lt;md:EntityDescriptor xmlns:md=&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot; xmlns:ds=&quot;http://www.w3.org/2000/09/xmldsig#&quot; entityID=&quot;https://sp.intelligrape.com&quot;&gt;

&lt;md:SPSSODescriptor protocolSupportEnumeration=&quot;urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol&quot;&gt;
&lt;md:KeyDescriptor&gt;
&lt;ds:KeyInfo xmlns:ds=&quot;http://www.w3.org/2000/09/xmldsig#&quot; Id=&quot;SPInfo&quot;&gt;
&lt;ds:X509Data&gt;
&lt;ds:X509Certificate&gt;
//copy the public key from &lt;SAML_IDP_HOME&gt;/credentials/idp.crt and paste here
&lt;/ds:X509Certificate&gt;
&lt;/ds:X509Data&gt;
&lt;/ds:KeyInfo&gt;
&lt;/md:KeyDescriptor&gt;

&lt;SingleLogoutService
Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:SOAP&quot;
Location=&quot;http://idp.intelligrape.com/Shibboleth.sso/SLO/SOAP&quot; xmlns=&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;/&gt;
&lt;SingleLogoutService
Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect&quot;
Location=&quot;http://idp.intelligrape.com/Shibboleth.sso/SLO/Redirect&quot; xmlns=&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;/&gt;
&lt;SingleLogoutService
Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot;
Location=&quot;http://idp.intelligrape.com/Shibboleth.sso/SLO/POST&quot; xmlns=&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;/&gt;
&lt;SingleLogoutService
Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact&quot;
Location=&quot;http://idp.intelligrape.com/Shibboleth.sso/SLO/Artifact&quot; xmlns=&quot;urn:oasis:names:tc:SAML:2.0:metadata&quot;/&gt;

&lt;md:AssertionConsumerService Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot; Location=&quot;http://localhost:4502/saml_login&quot; index=&quot;1&quot;/&gt;
&lt;/md:SPSSODescriptor&gt;
&lt;/md:EntityDescriptor&gt;

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), the value of Provider attribute in <rp:RelyingParty> the tag should be the same as that of EntityId specified in the above metadata file. Also, change encryptAssertions attribute to “never”.

&lt;rp:RelyingParty id=&quot;sp.intelligrape.com&quot; provider=&quot;https://sp.intelligrape.com&quot; defaultSigningCredentialRef=&quot;IdPCredential&quot;
defaultAuthenticationMethod=&quot;urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport&quot;&gt;
&lt;rp:ProfileConfiguration xsi:type=&quot;saml:SAML2SSOProfile&quot; includeAttributeStatement=&quot;true&quot;
assertionLifetime=&quot;PT5M&quot; assertionProxyCount=&quot;0&quot;
signResponses=&quot;never&quot; signAssertions=&quot;always&quot;
encryptAssertions=&quot;never&quot; encryptNameIds=&quot;never&quot;
includeConditionsNotBefore=&quot;true&quot;/&gt;
&lt;rp:ProfileConfiguration xsi:type=&quot;saml:SAML2ArtifactResolutionProfile&quot;
signResponses=&quot;never&quot; signAssertions=&quot;always&quot;
encryptAssertions=&quot;&lt;strong&gt;never&lt;/strong&gt;&quot; encryptNameIds=&quot;never&quot;/&gt;
&lt;rp:ProfileConfiguration xsi:type=&quot;saml:SAML2LogoutRequestProfile&quot;
signResponses=&quot;conditional&quot;/&gt;
&lt;/rp:RelyingParty&gt;

Provide the AEM’s metadata file created in the above step to IdP:

&lt;metadata:MetadataProvider id=&quot;CQMETADATA&quot; xsi:type=&quot;metadata:FilesystemMetadataProvider&quot;
metadataFile=&quot;/opt/shibboleth-idp/metadata/adobecq.xml&quot;
maxRefreshDelay=&quot;P1D&quot; /&gt;

AEM configuration.
For a better understanding of the SAML 2.0 Authentication Handler, please go through the official documentation. As mentioned in the 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 &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 :
• Set the SP provider id to the ID specified in above metadata file (adobecq.xml) i.e.
• 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. The 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 to 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.

Refer to the below image :
7. Accessing the AEM author instance.
Making a request to AEM at http://<host>:<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 the 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 a 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 the 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.

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

References :
http://helpx.adobe.com/experience-manager/kb/saml-demo.html
http://dev.day.com/content/docs/en/cq/current/core/administering/saml-2-0-authenticationhandler.html