The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.

IDP3 ECP with Tomcat and Apache-Managed Authentication

This is a guide to using Tomcat and Apache Web Server to manage authentication with IDP3 ECP – specifically, using the web server to manage the authentication.  

The Shibboleth IDPv3 offers a simpler approach for basic password authentication that requires fewer steps than outsourcing the authentication to Tomcat or Apache.

Install Shibboleth IDP3 following the instructions for Tomcat (currently at Installation).  It is strongly recommended to perform the status test described in the installation guide.

Edit conf/idp.properties.  Set idp.auth.flows to RemoteUserInternal.

#idp.authn.flows= Password
idp.authn.flows=RemoteUserInternal

Edit the server.xml file in your Tomcat conf directory ($CATALINA_HOME/conf/server.xml if you’re running Tomcat as a standalone server).  In the section where it defines the AJP connector port (8009), set Tomcat authentication to "false."  We want the Apache web server, not Tomcat, to handle the authentication with this particular setup.

<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
tomcatAuthentication="false"/>

Since both Apache and Tomcat need to be running, and we’ll want to be able to access Shibboleth through port 443 (HTTPS), we’ll need to use Apache web server’s AJP module to send IDP traffic over to Tomcat.  We can do this by editing the proxy_ajp.conf file, which on our Centos 6 system is located at /etc/httpd/conf.d/proxy_ajp.conf .  Add the following line to the end of the file:

ProxyPass /idp/ ajp://localhost:8009/idp/


Because we want the Apache web server to manage the authentication, we’ll need to edit the configuration files on the web server to protect the directory.  There are some different ways to do this, depending on what kind of authentication you want to use.  Below are some examples:

Kerberos (/etc/httpd/conf.d/auth_kerb.conf on our system)

<Location /idp/profile/SAML2/SOAP/ECP>
AuthType Kerberos
AuthName "SAML2 ECP"
# Note: If you can’t use akey tab, use the line below
KrbVerifyKDC off
KrbDelegateBasic on
require valid-user
</Location>


LDAP (/etc/httpd/conf.d/authz_ldap.conf on our system)

<Location /idp/profile/SAML2/SOAP/ECP>
AuthType Basic
AuthBasicProvider "ldap"
AuthBasicAuthoritative On
# Will need the line below for Apache servers >= 2.2.4
# AuthLDAPBindAuthoritative Off
AuthName "LDAP test login"
AuthLDAPURL ldaps://ldap.ncsa.illinois.edu:636/ou=people,dc=ncsa,dc=illinois,dc=edu?uid?sub?(objectClass=inetorgperson)
AuthZLDAPAuthoritative Off
Require valid-user
</Location>


Basic (/etc/httpd/conf.d/auth_basic.conf on our system)

<Location /idp/profile/SAML2/SOAP/ECP>
AuthType Basic
AuthUserFile /opt/testuserpass
AuthName "SAML2 ECP"
require valid-user
</Location>

After making changes to Apache, you will need to restart the server.  On our system, "sudo /sbin/service httpd restart" will do this.

Note: You may be able to troubleshoot by creating a test location (like /var/www/html/TestMyAuthentication) and putting a simple index.html file in it and then setting up the web server to protect those files.  Just pull up http://www.yourserver.org/TestMyAuthentication in your browser and see if the web authentication works as expected.

As an intermediate step, you may want to see whether it’s possible to log into your IDP at all.  There’s a relatively simple script at http://www.cilogon.org/ecp called testecp.sh .  Note that for IDP 3, all the test scripts have been modified to set the content type header to text/xml.  This is because curl by default will set an inappropriate content type application/x-www-form-urlencoded) that IDP 2 would tolerate, but IDP 3 will not.  If you want to use testecp.sh to see whether you can log into the IDP before setting up the metadata related to SPs, you will need to make a few (possibly temporary) changes to your configuration.  To make your IDP "open," you can edit the conf/relying-party.xml file to support an UnverifiedRelyingParty.  

<bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">
<property name="profileConfigurations">
<list>
<!-- <bean parent="SAML2.SSO" p:encryptAssertions="false" /> -->
<ref bean="SAML2.ECP" />
<ref bean="SAML2.Logout" />
<ref bean="SAML2.AttributeQuery" />
<ref bean="SAML2.ArtifactResolution" />
</list>
</property>
</bean>

You may also need to set idp.encryption.optional to true in conf/idp.properties

idp.encryption.optional = true

To work with the other testing scripts, you will probably need to configure your metadata related to Service Providers.  The directions for that are at Configuration.

After you are done making changes to Tomcat, you will need to restart it.

For troubleshooting, you can adjust your log levels by editing the conf/logback.xml file.  For example, you might try changing some of the levels to "debug."

If you get a SOAP error, you may want to double-check the test script you’re using and verify that it’s been updated to set the content type to "text/xml."