Rutgers Shibboleth Service

Shibboleth is a system designed to control access to network resources, particularly web applications. It is specifically intended to be used across institutions, e.g. for cooperative projects among institutions and for vendors that need to verify that a user is affiliated with an institution that has a contract with the vendor.

Shibboleth is designed so that it doesn't divulge any more information about the users than necessary. E.g. a vendor might be able to tell that the user is a student, but couldn't tell who the user is. To do this, shibboleth allocates an anonymous "handle" for your session. Of course shibboleth knows who is behind the handle, but it will only give out information that the user has authorized.

Shibboleth is a project of the Internet 2 community. There is a dedicated Shibboleth web site. For background on related infrastructure projects associated with Internet 2, see the Internet 2 Middleware web page.

Rutgers will be doing a Shibboleth pilot for the Fall of 2003. The pilot will involve two projects:

• A project by OIT to control access to web sites by information such as course membership.
• A project by the Library to control access to library resources.

Currently the "origin" end of Shibboleth is set up. This is the part of Shibboleth that authenticates the user and gives out information. The "target" end is installed on the systems with the actual applications or web pages.

The current shibboleth origin is on shib-origin.rutgers.edu. It is registered with the Internet 2 InQueue federation. This is a collection of universities that are evaluating Shibboleth. This federation is nominally for pilot implementations. In production we would likely join other federations. The federation runs some infrastructure that target sites can use, such as the "Where Are You From" service, which directs users to the proper origin site.

In case you need to test, here is some information about the origin service:

• URL: https://shib-origin.rutgers.edu:554
• client certificates may be registered with any of the standard commercial services, or the RULink CA.
• anyone with a valid Rutgers NetID may authenticate, by NetID and password. (This will likely be expanded to include anyone in an RULink-based domain.)
• currently the only information that will be released is employeeType, eduPersonAffiliation, and eduPersonScopedAffilation. These are defined in the ldap.rutgers.edu schema. eduPersonScopedAffilation is like eduPersonAffiliation but with @rutgers.edu on the end. E.g. a staff member would be staff@rutgers.edu. In particular user name, netid, etc, are not being released.
• authentication to the Shibboleth origin is handled by mod_auth_ldap, one of the many modules for doing authentication in Apache using LDAP. (Incidentally, this is not necessarily the one we would recommend for normal web sites. I picked it because it was well documented. In many ways Alex Mayrhofer's mod_auth_ldap looks more useful for a normal web site. In fact I suspect this will turn out to be a more useful way to control access to web sites, unless you specifically need interinstitutional service.)

Other attributes will surely be made available. If you need additional attributes for testing, contact hedrick@rutgers.edu. Note that no information is currently being released that would let you identify the user. That's because we expect to add course registration information to the default set of information that is released. We can't let random people see who is in what course. So we expect to let sites see what course a user is in, but not who the user is. We can arrange to release additional information to specific sites.

Some caveats, because this is still in early testing:

• This system is not yet in production. It could be down while work is done on it, or because the system needs to be used for some other purpose. If you need to use the system, please contact hedrick@rutgers.edu. It could fairly easily be put into semi-production (i.e. similar to production, but with no redundancy).
• Shibboleth systems should use a web cookie system for authentication. This one currently does not. That doesn't mean that it will be asking for your password all the time, because the web browsers do cache passwords. As long as you're using SSL (which you will be), that should be OK. However we do plan to connect this to a web cookie system after we have some discussion about which one to use.