Shibboleth, For IT Pros: Understanding Shibboleth Terms
For IT Pros: This page provides definitions of some of the Shibboleth terms you'll encounter in the process of setting up a service provider and connecting to an identity provider for your Shibboleth-protected web application.
Every server running Shibboleth-protected content is known as a service provider or SP. The server either uses proprietary SAML2 code to initiate the sign-on process or runs the free SP software from the .
The SP communicates with at least one identity provider or IDP. Each institution runs an IDP to perform the authentication process and to return the information about a logged-in user to the SP. At this university, we run three IDPs currently: one for each of the three University of Illinois campuses. If you need to allow users into your application from all three campuses, you will need to establish a trust relationship with all three IDPs. Additional user-bases from other universities will require additional trust relationships.
Trust relationships are achieved by exchanging metadata: information in XML format that includes the unique identifier (entity ID) for your SP, how to communicate with it, and certificates for signing and encrypting information passed to it.
A federation makes it easy to establish a trust
relationship with many IDPs. A federation is a group of organizations
that have pre-established policies of trust for authenticating users and
releasing information about those users to one another.
We participate in two federations: The I-Trust federation is a federation of the three University of Illinois campuses and may extend to other Illinois institutions in the future. The InCommon Federation is comprised of education, research, and business entities throughout the United States. If you need to allow access to resources beyond the university, youâll want to participate in InCommon. Note that being in a federation doesnât mean you must allow access to all users from organizations in that federation. Rather, it means you have the option of allowing users from any of those organizations in. You can choose, within a federation, which organizations are permitted access.
A service that allows users from only one organization, such as the Urbana campus, needs only to redirect users to that organizationâs IDP on login. If your application allows users from more than one organization, though, you need to redirect users to a Discovery Service: a web page that allows a user to select their home organization. Centralized Discovery Services are available that list all organizations in InCommon and I-Trust. If youâd rather not have organizations listed who arenât allowed access to your organization, though, itâs not complicated to create your own Discovery Service page.