Enabling SSO with CQ5 – Part I
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.
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
- Installing LDAP Server.
- Installing Shibboleth IDP.
- Installing Apache tomcat on Ubuntu.
- Configuring Shibboleth IDP.
- Installing LDAP Server.
- Installing Shibboleth IDP
-
After downloading the Shibboleth IDP from the link mentioned above , execute the
install.shfile . 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 usingidp.intelligrape.comas IdP hostname in the forthcoming post. -
Edit
/etc/hostsfile to have an entry like below:
[shell]127.0.0.1 idp.intelligrape.com idp [/shell]
- 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.warfromSAML_IDP_HOME/war/idp.wartoTOMCAT_HOME/webapps. Alternatively, you can create and openTOMCAT_HOME/conf/Catalina/localhost/idp.xmlfile 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/endorsedand 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.
- Configuring Shibboleth IDP
- Modify
SAML_IDP_HOME/metadata/idp-metadata.xmlto 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.xmlto add definition of attribute and ldap connect string. Find out thetag 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.xmlfor each attribute you are releasing to be used by SP. (Add it insideafp:AttributeFilterPolicytag. )
[xml]<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
[/xml]
-
Modify
SAML_IDP_HOME/conf/handler.xmlto 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.xmlfor detail debug trace. Increase the log level to Debug.
-
Modify
SAML_IDP_HOME/conf/login.configto provide the login credential for LDAP. Uncomment the code present inShibUserPassAuthor 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:ProfileConfigurationtag, changeencryptAssertionsattribute 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…
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?