Project index

Shibboleth Installation Notes

(Work in progress)

Notes from meeting between Jasper Tredgold and Graham Klyne at ILRT Bristol to learn about Jasper's work to use Shibboleth with portals.


1. Agenda

Goals for this meeting:

2. Overview of Shibboleth/WSRP work

The work to copnvey Shibboleth attributes in WSRP is aimed at portlet personalization rather than any real security purpose.

There is an assumption that the WSRP consumer and producer are in a common trust domain. The act of handing over a Shibboleth attribute implies that the recipient of the attribute is trusted by the giver. If they are in different administrative domains then some out-of-band authentication mechanism may be needed to build a trusted retationship between them.

What the work does allow is that a portal in domain A can provide a personalized service to a user from domain B using their normal preferences. (It's not clear if this extends to updating those preferences.)

 +-------------+                  +-------------+
 | (Domain A)  |                  | (Domain B)  |
 |             |                  |             |
 | IdP         |        --------->| IdP         |
 |             |       |          |             |
 |             |       |          |             |
 | Portal -----|-------           | Portal      |
 |             |                  |             |
 +-------------+                  +-------------+
   User from
   domain B

3. Installing a Shibboleth Identity Provider

This note is concerned purely with technical aspects of installing some working software, and does not address the complex organizational issues that must be observed when creating a live installation to provide meaningful security. The Shibboleth project provides a test Identity Provider called InQueue, which allows any developer to joint its federation. This note also omots details of how to install and run the optional WAYF element of the authentication process.

There are quite good instructions on the Shibboleth wiki [3], specifically at [4] and [5]. Most of the detailed information is in the "InQueue Installation" description: if not using Apache then the corresponding sections can be skipped. The other link, "Install in Tomcat Alone", provides some additional information for deploying a local identity provider using just Tomcat, and is probably best passed over for an initial installation.

An Identity Provider (IdP) requires two SSL connections: an generally available connection for initial authentication (default port 443), and one for authenticated entities to perform attribute queries via SOAP requests (default port 8443) to a Shibboleth Attribute Authority (AA). These two service elements are distinct servlets, and may be run on different hosts.

Expect to end up with a directory structure something like this:

The etc subdirectory contains a configuration file idp.xml; also federation metadata, information about the federation that may be polled from a federation manager - mainly, a liost of the entities in the federation, described in a format based on SAML metadata.

(Resolver -> attribute resolution -> in some file)

(Arps - attribute release policy)

(IdPconfig: default ports, default relying party identifier, point to federation files.)

Also need to config tomcat-users for demonstration local authentication.

(certificates or key? .p12 file, javakey format; use keytool java application)

(trust store: list of root CA certificates for verifying attribute consumers)

4. Installing a Shibboleth Service Provider

The Service Provider (SP) module determines whether access to a resource allow is to be allowed, based on examination of provided credentials obtained previously from the IdP, and also provides mechanisms for accessing attribute values from the AA.

Two forms of SP module available: one is C/C++, and one is Java. Using the Java SP is not recommended. The C/C++ SP module is an Apache module, which is configured to intercept specified request URIs and impose security checks before allowing resources to be accessed. In a very simple deployment, this could be used to control access to statically served data.

Try installing from RPMs first - if that doesn't work, may need to build from source.


Shibboleth SP setup uses a similar federation setup to the IdP elements. Shibboleth.xml configures the SP component.

There are two choices for access control: Apache configuration (httpd.conf, etc.) configuration can use the shibboleth SP module. The application can call the SP layer for information. Setup for the first option is covered here.

5. Portal integation with Shibboleth

There is a JAAS [9] module, which access Shibboleth authentication (and attribute?) information and makes it available via the Java JAAS APIs, and which can be used as a Tomcat authentication/authorization module. The SPIE project JAAS module [10] obtains the JAAS object from the Tomcat environment and stuffs it into the servlet's HTTP request context as a new "shibatts" attribute of the request.

The processing chain is something like this:

Web client
Apache SP layer - exctracts SAML information from incoming request and gets further information from the Shibboleth AA.
JAAS module - configured as Tomcat authorization module;  creates a Java object with authentication (and attribute?) information and passes this to the application via the servlet context.
Web application

Module extracts information from the Servlet request context "shibatts" attribute and inserts it into the portlet request UserInfo area (as defined for the JSR-168 API).

Another module in the WSRP consumer code [where?] extracts this information and inserts it into an extension field of the WSRP interface data.

See also some related documents at [6][7][8].

In summary, the authentication/attribute information is passed down the request dispatch chain via:

In principle, a web application could use JAAS directly, but that would require more intrusion into the web application code for the purpose of access control. (And maybe some servlet cross-context information handling problems?)

HTTP request
Portal (servlet)
  Pluto "plugin" copies information into Portlet context area
 |      <--- this interface constrained by JSR-168
WSRP consumer

Note: JSR-168 interface has a getUserPrincipal, and an interface for asking if the principal is a member of a named role, but no method for obtaining attributes associated with the entity.

6. References

  1. - Personalisation, Shibboleth and WSRP in the SPIE Project, Jasper Tredgold's presentation to the Sakai VRE demonstrator workshop help in Portsmouth, January 2006.

  2. - Shibboleth-aware Portals and Information Environments (SPIE) project website









-- GrahamKlyne 2006-03-22 14:11:29

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.