Before I get started I want to point out the purpose of this document. I’m trying to get the Shibboleth 1.3 Identity Provider running with as few extra components as possible. This means no LDAP, no SSL, no pubcookie and really for now, no real WAYF and no real Service Provider. This is a cut down installation guide to get it going. We’ll explore more options once everything is working. Just to reiterate, the setup described here is not secure in any way!! Don’t use this as a guide for your production site.

Download the shibboleth-1.3??.tar.gz file from http://wayf.internet2.edu/shibboleth/beta/ (I happen to be using the b5 build for now but obviously you should download the latest one)

Extract the file to a directory of your choosing and run the ant build script. This is a pretty straightforward process. One note, the first directory you are prompted for is the location of keystores, tools and other such things and should not go in the Tomcat/webapps folder.

Fire up tomcat and see what happens out of the box. Ok, not much happens out of the box. I guess I need to start reading some of the documentation.

So IMO the best place to start reading about a java app is the web.xml within the WEB-INF directory. Looking there are the following things:

• context-param contains the parameter IdPConfigFile with the location to the idp.xml
• One servlet called IdP
• Three servlet-mapping elements all pointing to the one IdP servlet. These are for the URLs ‘/SSO’ ‘/AA’ and ‘/Artifact’
• One mime-mapping for css files.

One thing that is missing is the security-constraint to tell Tomcat that these are protected resources. There is an example here: https://mail.internet2.edu/wws/arc/shibboleth-users/2005-03/msg00020.html . This example is for using LDAP but I’m going to go even simpler and use the static tomcat-users.xml file. This isn’t scalable but it will allow the IdP to get up and running then I can migrate it to use LDAP in a little bit. By default, Tomcat comes configured to read users from the tomcat-users.xml and the user ‘tomcat’ with the password ‘tomcat’ will work for our purposes. This user will have one role of ‘tomcat’.

In the example the protected resource is in the URL ‘/HS’. As of Shibboleth 1.3 this has been renamed ‘/SSO’ so make the appropriate modifications to your web.xml.

Copy the security-constraint (changing the url-pattern to /SSO) and copy the login-config to your web.xml.

After restarting Tomcat, the IdP servlet was throwing an exception about not having the right kind of XML parser so I renamed the default tomcat/common/endorsed jars and copied all of the jars from the shibboleth-idp-install/endorsed to tomcat/common/endorsed and restarted tomcat.
Ooh, that was bad. Now XML parser errors are spewing all over the place. In tomcat’s server.xml I had the xmlValidation=”true” attribute set in the Host tag. Set it back to false and it started working. (Working in as much as Tomcat started)

When I go to /SSO or /AA I get the following Shib Exception:
No protocol handler registered for location (http://localhost:8080/timb-idp/SSO).
org.opensaml.SAMLException: Request submitted to an invalid location.

By modifying the idp.xml to bump up the logging to DEBUG we can see what is happening.

The Identity Provider was trying to register a URL at example.org. So modify the AAUrl attribute of the idp.xml to point to my AA (http://localhost:8080/timb-idp/AA)

Ooh!! Lots more messages came out of the tomcat console before it blew up. Still got the same error message, but it took longer to get there. That’s progress!

Within the idp.xml, change providerId attribute to point to my webapp and change the three ProtocolHandler/Location tags to correspond to what I’m doing.

Now I get the error org.opensaml.SAMLException: Invalid data from Service Provider: no target URL received.

That makes sense. I didn’t tell my SSO webapp where I was trying to go once I got authenticated. I need to pass some parameters to the SSO servlet so it knows what to do once everything is working.

According to the latest copy of the specification guide the HTTP request to the SSO must contain the following parameters on the query string:

• providerId
• shire
• target
• time (optional)

Providing all of those now works and it redirected me to the URL provided by the shire parameter.

We now have a more-or-less-working-yet-toally-insecure Identity Provider.
Next step is to put up a Service Provider that can consume these credentials.