Enabling SSO with CQ5 – Part I

27 / Feb / 2014 by Geetika Chhabra 1 comments

Single sign-on (SSO) is a mechanism where by a single action of user authentication and authorization can permit a user to access all computers and systems for which he has access permission, without the need to enter multiple passwords. While implementing SSO as part of one of our projects , we thought of protecting CQ5 author and publish instances. I’ll be covering it in tri-part blog series which will be composed of following three parts :

Part I : Laying the groundwork for installing, configuring Shibboleth (IdP)
Part II : Protecting CQ5 author instance when CQ5 acts as a service provider
Part III : Protecting any published resource/website

We’ll be using Shibboleth as a way to provide SSO. Shibboleth is an open-source project that provides Single Sign-On capabilities and allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.

It’s an open source implementation of identity management, providing a web-based single sign-on mechanism across different organizational boundaries. It is a federated system, supporting secure access to resources across security domains. Information about a user is sent from a home identity provider (IdP) to a service provider (SP) which prepares the information for protection of sensitive content and use by applications. Please visit Shibboleth home page if you are not familiar with it.

In this post of this tri-blog series, I will cover installation and configuration of Shibboleth IdP.
Basic Concept:

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

Software stack being used:
OS : Ubuntu 12.10
CQ5 Server : AEM 5.6.1
LDAP Server : openLDAP (It can be any other LDAP server).
IDP (Identity Provider ): Shibbolet IDP 2.4.0 (Download the IDP from the given link).
App Server for IDP : Apache Tomcat 6 (Download the apache tomcat for linux).
Following Steps will be covered :
  1. Installing LDAP Server.
  2. Installing Shibboleth IDP.
  3. Installing Apache tomcat on Ubuntu.
  4. Configuring Shibboleth IDP.
  1. Installing LDAP Server.
For installing LDAP and configuring it for AEM (if needed), Installing and configuring LDAP for AEM can be followed.
  1. Installing Shibboleth IDP
  • After downloading the Shibboleth IDP from the link mentioned above , execute the install.sh file . Make sure you run it as a sudo user. You will be prompted to enter the IdP hostname. Provide the fully qualified name as per your requirement. Going forward, we’ll be using idp.intelligrape.com as IdP hostname in the forthcoming post.

  • Edit /etc/hosts file to have an entry like below:

[shell]127.0.0.1 idp.intelligrape.com idp [/shell]

  1. Installing Apache tomcat on Ubuntu.
  • Existing documentation can be leveraged for installing Apache Tomcat.
  • Generate the keystore files for tomcat to enable SSL.

[shell]keytool -genkey -alias tomcat -keyalg RSA -keystore \path\to\my\keystore [/shell]

  • Apply the SSL certificate generated in above step to TOMCAT_HOME/conf/server.xml. (TOMCAT_HOME refers to the installation directory of Tomcat)

[xml]<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="<your keystore file generated in above step>" keystorePass="<your password here>" clientAuth="false" sslProtocol="TLS" />
[/xml]

  • Copy idp.war from SAML_IDP_HOME/war/idp.war to TOMCAT_HOME/webapps. Alternatively, you can create and open TOMCAT_HOME/conf/Catalina/localhost/idp.xml file and paste the following content into it. This step will make sure that TOMCAT will always serve the latest war.

[xml]<Context docBase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiResourceLocking="false" antiJARLocking="false" unpackWAR="false" swallowOutput="true" />
[/xml]

  • Create the directory TOMCAT_HOME/endorsed and copy the .jar files included in the IdP source endorsed (SAML_IDP_HOME/lib/endorsed) directory into the newly created directory.
  • Quick Test accessing returns Ok.
  1. Configuring Shibboleth IDP
  • Modify SAML_IDP_HOME/metadata/idp-metadata.xml to make sure all the location attribute points to idp app on tomcat 8443. (SAML_IDP_HOME refers to the installation directory of Shibboleth IdP.)
  • Modify SAML_IDP_HOME/conf/attribute-resolver.xml to add definition of attribute and ldap connect string. Find out the tag and uncomment the attributes you want to release to SP. or Either copy the below . Source attribute Id should be same as present in LDAP user profiles.

[xml]<resolver:AttributeDefinition xsi:type="ad:Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="uid" sourceAttributeID="uid"> <resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:mace:dir:attribute-def:uid" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" name="uid" friendlyName="uid" />
</resolver:AttributeDefinition>
[/xml]

Find out the tagand uncomment it for LDAP setting. Customize the same as per your LDAP settings.

[xml]
<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
ldapURL="<your LDAP hostname>"
baseDN="<your base dn settings>"
principal="<principal user to login to LDAP>"
principalCredential="<Password for admin user>"
<dc:FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</dc:FilterTemplate>
</resolver:DataConnector>[/xml]

  • Modify SAML_IDP_HOME/conf/attribute-filter.xml for each attribute you are releasing to be used by SP. (Add it inside afp:AttributeFilterPolicy tag. )

[xml]<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
[/xml]

  • Modify SAML_IDP_HOME/conf/handler.xml to remove all the entries for authentication except “UsernamePassword” and “PreviousSession”. You must comment out the “RemoteUser” element or the authentication will be open for any user. Removal of “PreviousSession” will disable SSO support, that is it will require the user to authenticate on every request.

  • Modify SAML_IDP_HOME/conf/logging.xml for detail debug trace. Increase the log level to Debug.

  • Modify SAML_IDP_HOME/conf/login.config to provide the login credential for LDAP. Uncomment the code present in ShibUserPassAuth or simply copy the below. Please customize it according to your LDAP connection settings

[shell] edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="<Ldap host setting like ldap://ldap-test.intelligrape.com:389 >"
baseDn="<base dn settings like dc=intelligrape,dc=com>"
bindDn="<Principal user dn settings like cn=admin,dc=intelligrape,dc=com >"
bindCredential="<Principal user password>"
port="<port where ldap is running>"
ssl="false"
tls="false"
subtreeSearch="true"
userField="<ldap attribute which will be used as username e.g. uid">
userFilter="uid={0}"; [/shell]

  • 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. For now, we’ll provide details for IdP’s metadata only. Enter the following details into relyingParty.xml , if the same doesn’t exist already.

[xml]<metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
[/xml]

  • For each rp:ProfileConfiguration tag, change encryptAssertions attribute to “never”.

This should cover the basic configuration for Shibboleth Idp.

We’ll introduce SP and its configurations in forthcoming posts. Stay tuned for next parts…

FOUND THIS USEFUL? SHARE IT

comments (1 “Enabling SSO with CQ5 – Part I”)

  1. Girish

    i am looking to setup SAML and found your blog. I have installed Shibboleth 3.x and tomcat 8. I have go to the stage of creating self signed SSL Certificate and my tomcat is running on https:localhost:8443. I have also copied the idp.war to tomcat webapps folder. I looking for some help for the next steps. could you please help?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *