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.
Goals for this meeting:
- Links to the various pieces of information needed, starting from scratch and not assuming prior knowledge of Shibboleth, to get a demonstration system running in a new environment.
- Opinions and links to relevant information to get a minimal Shibboleth test/development/demonstration environment up and running. If it doesn't already exist, documentation for setting up such an environment might be a useful output of our Sakai VRE demonstrator work. (So far, I've not found the Shibboleth site to be helpful in this regard.)
- Understanding which are the key modules in Jasper's software development dealing with the aspects of implementing Shibboleth-over-WSRP. Jasper's Portsmouth presentation  might be a starting point for this.
- Discuss how the Jasper's work done so far would carry over to using constrained delegation profiles purportedly supported by Shibboleth 2.
- Discuss some thoughts we have about focusing on Shibboleth-enabling the portal rather than the portlets (are there parts of Jasper's work that might be relevant here?). (It seems that Shib'ing portlets is something that may be fruitfully left until the Shibboleth 2 work comes available.)
- Anything else that seems relevant and/or interesting!
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 , specifically at  and . 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 -> ref.id 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  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  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. | Tomcat | 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 uk.ac.portal.spie.pluto.factory.impl.RenderRequestFactoryImpl.java 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 .
In summary, the authentication/attribute information is passed down the request dispatch chain via:
- JAAS information about HTTP request
- Servlet HTTP request session data
- Portlet JSR-168 interface userinfo
- WSRP extension field
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 | Tomcat | Servlet \ JAAS / Portal (servlet) \ Pluto "plugin" copies information into Portlet context area / | <--- this interface constrained by JSR-168 Portlet | 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.
http://www.dsg.port.ac.uk/events/workshops/VRE05/talks/Jasper%20Tredgold.ppt - Personalisation, Shibboleth and WSRP in the SPIE Project, Jasper Tredgold's presentation to the Sakai VRE demonstrator workshop help in Portsmouth, January 2006.
http://spie.oucs.ox.ac.uk/ - Shibboleth-aware Portals and Information Environments (SPIE) project website
6.1. Other links
ShibbolethNotes - Shibboleth background and setup notes in this wiki
-- GrahamKlyne 2006-03-22 14:11:29