Install CAF FedSSO (Shibboleth) w/ idp-caf-installer

I pretty much followed the instructions for installing Shibboleth from
the CAF website, the only difference would be using Ubuntu instead of

Configure Server to See Active Directory

vi /etc/ldap/ldap.conf

TLS_CACERT      /etc/ssl/certs/ca-certificates.crt
URI  ldaps://

vi /etc/network/interfaces

dns-nameservers 444.444.444.444, 555.555.555.555

vi /etc/resolv.conf

nameserver 444,444,444,444,
nameserver 555,555,555,555

Install Java

sudo apt-get install openjdk-7-jdk sudo
/usr/bin/update-alternatives --config java

Generate config file

These first steps can be done from your own computer. Start by cloning
the source for the CAF installer
git clone you can view
the project here

Next you’ll need to create your config file. In the idp-installer-CAF
directory open the www/appconfig/CAF/index.htm file in a browser.

NOTE If you’re using Active Directoy and your users are spread across
multiple objects (or the standard ports 389 and 636) aren’t working.
Consider using the Global Catalog ports instead port 3268 instead of 389
and port 3269 secure port instead of 636.

Screen Shot 2014-10-01 at 12.45.24

Screen Shot 2014-10-01 at 12.45.37

Save your config file.

Prepping Ubuntu 14.04

Update the OS

apt-get update
apt-get upgrade

from the idp-installer-CAF directory run:


Running the CAF Installer

Copy the config file you made into the idp-installer-CAF directory.
Set JAVA_HOME if you haven’t already. Then run,
answer all the questions, don’t worry about the Certificate Questions we
will be replacing them with our own later.

After the Installation has complete you should be able to verify that
everything is up and running by visiting . If you get a 404
see the Troubleshooting section at the bottom of the page.

Also, make sure tomcat6 is the owner for the shibboleth-idp directory

chown -R tomcat6:tomcat6 /opt/shibboleth-idp

Configuring For Active Directory using Secure LDAP

vi /opt/shibboleth-idp/conf/login.config

edu.vt.middleware.ldap.jaas.LdapLoginModule required

vi /opt/shibboleth-idp/conf/attribute-resolver.xml

<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"

Setup Signed Certificate for https

After talking with CAF they had suggested against me using the wildcard
cert for both the https and shibboleth certificates. Instead they
suggested that I use our signed wildcard cert for https and a
self-signed cert for shibboleth. Since Apache would then only be used
for https I opted to stop using it and generate a p12 file for a tomcat
only setup.

openssl pkcs12 -export -out mywildcard.p12 -inkey mywildcard.key -in mywildcard.crt -certfile CA.pem

I then updated /etc/tomcat6/server.xml to point to
/etc/ssl/mywildcard.p12 instead of the https.p12 in

Editing metadata-idp.xml for CAF

In <Extensions> at the top of the file added

<mdui:UIInfo xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">
    <mdui:DisplayName xml:lang="en">STU</mdui:DisplayName>
    <mdui:Description xml:lang="en">St. Thomas University</mdui:Description>
    <mdui:InformationURL xml:lang="en"></mdui:InformationURL>

at the bottom of the file just above </EntityDescriptor> added

  <OrganizationName xml:lang="en">STU</OrganizationName>
  <OrganizationDisplayName xml:lang="en">St. Thomas University</OrganizationDisplayName>
  <OrganizationURL xml:lang="en"></OrganizationURL>
<ContactPerson contactType="technical">
  <SurName>STU Help Desk</SurName>

You can view our idp-metadata.xml file


Go to your Shibboleth Test site
and login. If you get any errors, see the Troubleshooting section. NOTE If you’re logging in directly you’ll get a 404 after login, that’s fine, we’re just testing authentication at this step.

Next is to see if you can connect it to another system using
testshib. Follow their instructions, it’s pretty


Debugging LDAP Issues

You can do this by editing /opt/shibboleth-idp/conf/logging.xml.

uncomment this line

<logger name="edu.vt.middleware.ldap" level="WARN"/>

and change WARN to ALL

<logger name="edu.vt.middleware.ldap" level="ALL"/>

That should tell you everything that’s happening with you LDAP
connection. Of course you’ll probably want to turn this back to WARN in
production once you get everything working.

Visiting results in a 404.

I got this when I LDAP wasn’t binding properly. I had structured the
bind login name incorrectly using ldapbinddn=STUbindaccount rather than

Authentication failed despite proper username/password. Error message was javax.naming.PartialResultException: Unprocessed Continuation Reference(s)

Login appeared to find my user but authentication was failing when I
entered my username and password into the form at

I ended up having to switch my ldap port from 389 to 3268 inorder for it
to work with AD. To fix the
javax.naming.PartialResultException: Unprocessed Continuation Reference(s)
error I was getting. In login.config change
ldapUrl="ldap://" to

Dave Canam

Programmer Analyst at St. Thomas University

Latest posts by Dave Canam (see all)