What the Shibboleth?

In April of 2011, Emory began to use Shibboleth as its Enterprise authentication solution. Since that time, the Emory Login Service (Shibboleth) has authenticated over 11.8 million requests (averaging about 230,000 per month) and has grown to provide authentication services for over 100 distinct service providers both internal and external to Emory. Although the service has been in production for some years now, for many, there still seems to be some mystery as to what exactly Shibboleth is and a basic understanding of how it works.

What is Shibboleth?

From https://shibboleth.net/, “Shibboleth is an open-source project that provides Single Sign-On capabilities and allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.”

Huh? What the Shibboleth? The simpler answer is that Shibboleth is software used to authenticate users and provides a single sign-on (SSO) solution. Single sign-on simply means that if a user logs into an application configured to use Shibboleth and then that user goes to another application that also uses Shibboleth, that user will not have to log in again. Additionally, if the same user quits either application A or application B and then comes back to either application on the same computer within a configured time limit, that user will not have to log in again. This is the default behavior for a protected resource that uses Shibboleth.

Although clearly linked, there are important differences between authentication and access. Authentication is the process of identifying who a user is; access is the process of allowing a user to get to and use a resource which may or may not be protected. Sometimes authentication may be successful, but access can then be denied based on the access rules in place for the resource.

For example, let’s say someone wants to go to an R-rated movie. The requirement is that the person be at least 17 years of age and have a valid ticket (user attributes). Only by meeting both conditions (the access rules) can that individual attend the movie…authentication being the use of a picture ID to identify one’s self. Shibboleth works much the same way.

How does Shibboleth work?

Shibboleth consists of two pieces of software, referred to as the identity provider (IdP) and the service provider (SP). Additionally Shibboleth needs another piece of software called an authenticating source (in the example for the movie, you can think of the authenticating source as the issuer for the photo ID, perhaps the DMV, and the service provider as the movie attendant).

For the purposes of this discussion, the SP can be thought of as the web server, which typically is maintained by the server system admin. The Emory Login Service IdP is maintained by the LITS WebHosting group while the LITS Messaging group maintains the authenticating source (LDAP). The LITS Identity Management (IDM) group provides user support as regards to LDAP. In the movie example, I mentioned authentication and access; the IdP software manages authentication while the SP software manages access. All three of these systems (the IdP, the SP and the authenticating source) work together to provide or deny as appropriate access to a shibboleth-protected resource/application.

Without getting into the technical details, the process for authentication (managed by the IdP) and access (managed by the SP) typically happens as follows:

1. A user requests a Shibboleth-protected resource by typing that URL into a browser.
2. The service provider (SP) software, which runs on the web server, intercepts that request and checks to see if the user already has logged into that resource within a configured time period (i.e., checks for a valid user session). If the user has previously logged into the resource within the configured time, access is granted without contacting the IdP, as the user already has a valid user session. If the user does not have a valid user session, the SP forwards the request to the identity provider (IdP) for authentication.
3. The IdP software collects the user credentials (typically but not necessarily the Emory netID and password) and contacts the authenticating source providing the user credentials.
4. The authenticating source verifies that the user is indeed who he/she says they are based on the user credentials (i.e., Emory netID and user password). Again at Emory, the authenticating source is LDAP, so essentially an LDAP query is executed using the user’s netID and his/her password is compared to what is returned by LDAP. If the passwords match, then the user is authenticated (of course, if the user netID is not found , authentication also fails).
5. If authentication is successful, the authenticating source then collects all the information that it knows about the user (the user attributes) and sends all of that information back to the IdP.
6. Based on a previously configured attribute filter on the IdP for that particular SP, the IdP strips away and only provides to the SP those attributes as configured by the SP’s specific attribute filter. At this point, the IdP has performed its function and the IdP’s job is completed; it is now up to the SP to either allow or deny access to the protected resource.
7. The SP collects the user attributes as provided by the IdP, and either allows or disallows access based on the access rules as configured for that particular protected resource on the SP.

Believe it or not, these complicated steps are actually simplified and do not even address other details such as certificates, keys, queries, broker communication, and metadata. For a more thorough discussion beyond what I have provided, please see https://wiki.shibboleth.net/confluence/dashboard.action and the accompanying links. For a list of other institutions that also use shibboleth, please see  http://www.incommon.org/federation/info/all-orgs.html.