Introduction

Shibboleth, a project of the Internet2 Middleware Architecture Committee for Education (MACE), is investigating technology to support inter-institutional authentication and authorization for access to managed resources. The intent is to support, as much as possible, the local campus-wide security systems in use today, rather than mandating use of particular schemes like Kerberos or X.509-based PKI. The goal is to create a flexible and efficient way to provide reliable, trustworthy authorization information to resource access managers while also preserving individual privacy.

The architecture that has been developed includes standardized message semantics and syntax based on SAML/XML. Initial authentication of a user is accomplished by the local campus’s "initial sign-on" or other generalized digital credential system. Trusted agents then exchange encrypted and/or digitally signed messages to securely identify themselves to each other and then exchange appropriate information about the potential user of the resource.

A prototype implementation is now underway with teams from Carnegie-Mellon University and IBM/Tivoli. Because of its modular design, Shibboleth components should be easy to incorporate into existing large-scale web-based server systems, e.g. Apache, Tivoli, etc. MACE would like to thank IBM/Tivoli for its participation and analytic support.

For a complete description of the Shibboleth project and architecture, please see https://middleware.internet2.edu/shibboleth/

1. Aren’t PKI certificates sufficient to solve the problem of remote access?

PKI certificates by themselves probably won't be sufficient for remote resource access. The certificate payload is too limited, too inconsistent, and the resource owner's requirements are likely to be quite varied. The certificate will most likely provide a "handle" by which the resource owner can retrieve the necessary authorization data. We believe the on-line resource industry needs a standardized protocol for acquiring a wide variety of appropriate authorization data. This is beyond the scope of typical PKI certificates alone. The standardized exchange of authorization data is the function that Shibboleth addresses.

2. Does Shibboleth use digital certificates now? If not, then in the future?

The heart of Shibboleth is the controlled release of information about local users by a trusted attribute authority to trusted resource managers. The local campus attribute authority makes use of whatever authentication mechanism is available at the campus. Web-ISO is one mechanism. PKI certificates is another. This is outside the scope of the design.

While Shibboleth does not require PKI certificates, the campus generally will be better served by implementing a modern, strong authentication system based on PKI. Ultimately a trust chain is only as strong as its weakest link and, except for perhaps Kerberos, most campus authentication systems (e.g. userID/Password) are relatively weak.

3. What are the core components of a Shibboleth installation? What will origin universities and target resources need to set up?

There are 5 "core" components of Shibboleth. They are intended to be implementable as stand-alone servers but in practice some of them may be combined.

1. The Shibboleth initiation request server (SHIRE) is installed at the target resource and initiates the Shibboleth interaction. It starts with the WAYF (see below) and acquires a "handle" by which inquiries about the user can be submitted to the campus’s Attribute Authority.
2. The "Where Are You From" (WAYF) server asks the user to identify their local authentication domain, e.g. MIT or Dartmouth or UC Berkeley. The idea is to support "fuzzy matching" so that a variety of responses can be mapped to the appropriate campus domain. The WAYF could be a generalized service or could be part of a SHIRE.
3. The Shibboleth Handle Server (HS) is part of a campus security domain. Its role it to supply an abstract "handle" by which queries can be submitted about a user. This is intended to preserve privacy and anonymity as needed.
4. The Shibboleth Attribute Requester (SHAR) at the target resource uses the handle provided by the SHIRE (above) to submit requests for the user’s authorization attributes. It uses a well-defined XML-based syntax for this. Semantics have been defined for an initial set of queries. The dialogue is patterned after the OASIS SAML design.
5. The Shibboleth Attribute Authority (AA) associated with the campus security domain responds to queries from the SHAR. It respects the institution's default information release policies and a user's information release preferences.

Besides the HS and the AA, a university will need a robust campus-wide user authentication system and an enterprise directory holding attributes about its community members.

The resource site will need to integrate the SHIRE and the SHAR with their web server system. The WAYF could be run at the resource site or could be a generalized server run for the Shibboleth community.

4. What do my folks need to know to run a shibboleth installation? What campus systems will Shibboleth need to interface with?

Shibboleth components on a campus look like a typical administrative application. It will use the campus’s authentication system and the campus’s enterprise directory, just like other applications. In addition, the AA will need to be configured to support a default attribute release policy and should provide a user interface to allow users to specify preferences. For the sake of FERPA, the AA will maintain logs of information release.

5. Why should our campus implement PKI digital certificates if Shibboleth is just around the corner? In other words, if you have limited resources, which technology would you implement first?

Where to put limited resources depends on campus priorities. If remote access is the most important problem and Shibboleth will solve that with an existing common authentication method, then implementing Shibboleth would make sense. If data security and digital signatures are critical, e.g. to business operations, then the campus will need PKI.

If a campus has no common authentication method, it should consider PKI. If it does have one and it isn't PKI, it should consider PKI as a goal for the next generation.

Implementation of a CA and Shibboleth can occur in any order. They are independent. Whatever reasonably robust common authentication method it has today can be used with Shibboleth. Having implemented Shibboleth, with the associated enterprise directory, PKI is a natural add-on. Ultimately a campus should implement both.

6. Who in the higher education community will be using Shibboleth?

We believe it will be useful for almost all universities and for almost all members of those communities. The initial goal is to support managed access to licensed or otherwise restricted resources, but it is general enough to address much more sophisticated applications. The SHAR and the AA may evolve into very important components of a general PKI since this is how attributes, roles, responsibilities, etc. associated with a credential holder may be exchanged with Relying Parties. Of particular interest to the university will be the AA's ability to respect FERPA and HIPAA rules.

7. Why is a pilot project with digital certificates for remote access useful if Shibboleth seems to provide the solution?

Shibboleth and PKI are complementary technologies. PKI certificates provide a very reliable digital credential, analogous to a driver’s license. Shibboleth is analogous to using the driver’s license number to look up information about the driver. PKI credentials are fundamental to a wide variety of business applications where access or privileges must be managed.

The intent of the Mellon pilot for remote access is to demonstrate the use of digital certificate technology in a constrained environment with the goal of refining the technology for use in a broader range of more sophisticated applications across campuses. Using digital certificates for basic remote access is a relatively simple but very useful application with which to begin this process.

As we gain experience with the complementary technologies of digital certificates and Shibboleth we fully expect the community to identify the strengths of each and refine the way these technologies work together and/or separately.