What is it?
Shibboleth is an open software system for web single sign-on. It enables web applications deployed in most typical web server environments to authenticate (that is, securely establish the identity of) users by referring them to a centralized service known as an identity provider. This service interacts with the user to collect a password (or carry out a similar challenge) to authenticate the user. The user is returned to the web application (called a service provider) using a secure exchange that provides the application with a collection of attributes about the user. The attributes include such standard information as which identity provider authenticated the user (e.g., LSU), how the authentication was performed, and may include various kinds of unique identifiers associated with the user's account, group memberships and eligibilities, etc.
The single sign-on notion recognizes the identity provider's ability to maintain a session with the user so that subsequent referrals for authentication by other service providers during that session can be invisible to the user and appear automatic.
How does it work?
For detailed information about how Shibboleth works, refer to the Shibboleth and SAML web sites for pertinent material. Shibboleth is an implementation of the SAML specifications for web single sign-on and attribute exchange. It adds additional layers of public-key trust management and configuration features specifically designed for web-based deployment. It is designed to interoperate with other open and proprietrary implementations of SAML and with applications, portals, etc. that offer SAML support. (No particular compatibility with other implementations is guaranteed.)
What's the point of federation?
Most single sign-on systems are designed to function within a single security domain. A single set of users (for example, all accounts issued by the university) can identify themselves to an application. With a federated system, this simple approach is still possible, but it's also possible to expand the application's scope and securely expose it to users from any trusted identity provider in the world. Naturally, this raises a variety of technical and policy considerations. The InCommon Federation is a vehicle for exploring this new way of doing business in the American higher education sector and eventually beyond.
