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 the protection of sensitive content and use by applications. Please visit the Shibboleth home page if you are not familiar with it.
In this post of this tri-blog series, I will cover the installation and configuration of Shibboleth IdP.
Basic Concept:
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 the 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
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).
- Installing LDAP Server.
- Installing Shibboleth IDP.
- Installing Apache Tomcat on Ubuntu.
- Configuring Shibboleth IDP.
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.
Edit /etc/hosts file to have an entry like below:
127.0.0.1 idp.intelligrape.com idp
Installing Apache Tomcat on Ubuntu.
Existing documentation can be leveraged for installing Apache Tomcat.
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 the 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="<your password here>" clientAuth="false" sslProtocol="TLS" />
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.
<Context docBase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiResourceLocking="false" antiJARLocking="false" 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 returns Ok.
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 the 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 the same as present in LDAP user profiles.
<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>
Find out the tagand uncomment it for the 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>"
<dc:FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</dc:FilterTemplate>
</resolver:DataConnector>
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. )
<afp:AttributeRule attributeID="uid">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
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 a 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
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}";
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.
<metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
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 the next parts…
No comments:
Post a Comment
If you have any doubts or questions, please let us know.