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
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 for 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.
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).
App Server for IDP
: Apache Tomcat 6
(Download the apache tomcat for linux).
Following Steps will be covered :
- Installing LDAP Server.
- Installing Shibboleth IDP.
- Installing Apache tomcat on Ubuntu.
- Configuring Shibboleth IDP.
- Installing LDAP Server.
For installing LDAP and configuring it for AEM (if needed), Installing and configuring LDAP for AEM can be followed.
- 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.
/etc/hosts file to have an entry like below:
127.0.0.1 idp.intelligrape.com idp
3. Installing Apache tomcat on Ubuntu.
- Generate the keystore files for tomcat to enable SSL.
keytool -genkey -alias tomcat -keyalg RSA -keystore \path\to\my\keystore
- Apply the SSL certificate generated in above step to TOMCAT_HOME/conf/server.xml. (TOMCAT_HOME refers to the installation directory of Tomcat)
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="<your keystore file generated in above step>"
keystorePass="&lt;your password here&gt;" clientAuth="false"
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.
<Context docBase="/opt/shibboleth-idp/war/idp.war" privileged="true"
unpackWAR="false" swallowOutput="true" />
- 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 https://idp.intelligrape.com:8443/idp/profile/Status returns Ok.
- Configuring Shibboleth IDP
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.)
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.
xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="uid" sourceAttributeID="uid">
<resolver:Dependency ref="myLDAP" />
Find out the
tag and uncomment it for LDAP setting. Customize the same as per your LDAP settings.
<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>"
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.
SAML_IDP_HOME/conf/logging.xml for detail debug trace. Increase the log level to Debug.
ldapUrl="&amp;lt;Ldap host setting like ldap://ldap-test.intelligrape.com:389 &amp;gt;"
baseDn="&amp;lt;base dn settings like dc=intelligrape,dc=com&amp;gt;"
bindDn="&amp;lt;Principal user dn settings like cn=admin,dc=intelligrape,dc=com &amp;gt;"
bindCredential="&amp;lt;Principal user password&amp;gt;"
port="&amp;lt;port where ldap is running&amp;gt;"
userField="&amp;lt;ldap attribute which will be used as username e.g. uid"&amp;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. 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.
- For each
rp:ProfileConfiguration tag, change
encryptAssertionsattribute 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..
P.S. This post was originally published on my company’s website
Hope it helps !! 🙂