Project Shibboleth: Issues and Answers

Project Shibboleth: Issues and Answers
Saturday, June 25th, 1:30-3:30 p.m.
ALA Annual Conference, Chicago

This was an excellent program that had a solid mix of speakers who could address the various aspects of Shibboleth, from the technical underpinnings to considerations for implementing it on a broad scale to perspectives of librarians on the types of changes to user behavior that Shib (for short) might require. The program allowed me to get a solid grounding in Shib without getting too technical or too theoretical. The audience was a good size and a healthy mix of techie and non-techie folks (in fact, at one point one of the presenters asked how many people in the audience were librarians from outside the systems department, and over half raised their hands).

Arrived a bit late because of the same old story, buses and lunch and tigers and bears, oh my…

When I arrived Keith Hazelton of Internet 2 was rolling along in his presentation of the fundamentals of Shibboleth and the ten main verbs to remember when thinking about how Shibboleth works. Hazelton’s main point was to bring home the fact that Shib is the “deliver” verb in the long chain of events involved in authentication (AuthN) and authorization (AuthZ). It is an open-source tool for facilitating identity management between institutions (universities and colleges) and service providers (JSTOR, EBSCO, etc.).

Hazelton discussed the problem of fragmentation, which occurs when multiple IT systems within the same institution have the ability to create a “person record”. At some point, all of those different person records have to be joined together to make one coherent person, a unified source of identity information.

Shibboleth is simply a means of moving identity information from an institution to a service provider. It is up to the institution to handle creating the person and defining who he or she is through attributes (name, status, dob, etc.) and up to the service provider to open the gate and allow the person is. Shib simply carries (delivers) identity information between the two.

Hazelton explained how this works by using the example of the three musketeers. The questions of identity are, What groups do I belong to? What roles am I in? One might answer, I am Porthos, a member of the musketeers. This would be my affiliation. On the other side of the equation, you have the privileges that are granted to persons of a given affiliation. Do you get to bear arms? Do you get to go into the palace? The privileges are easy to follow when there are only one or four people who belong to a single group, but the more people and groups you have, the more complicated it is to manage their privileges. The concept of affiliation is a nexus point to lump people into affiliations and lump privileges to that affiliation. Grouper is the name for what puts the people into groups, Signet is the name for the piece of Shib that says what groups get to do what things (who gets to go into the palace). Hazelton’s metaphor was interesting and, unlike some metaphors used at sessions that shall remain unnamed, seemed to carry through well down into the details.

Hazelton followed this metaphorical discussion with the concepts of how systems talk to each other to authorize a user’s access to a given resource. The “systems of record” (for example, HR and registrar databases) “provision” out information on a person (IAM information). This info needs to be delivered to services, which then make the AuthZ decision. Shib is the middle portion of this equation, delivering IAM information to services that are capable of making an authorization decision.

Hazelton concluded with the fact that not many people rushing to adopt Shib, in large part because it’s open source. In order to succeed, it needs partners. The move to adopt Shib needs to come from the ground up.

Hazelton also quickly flashed the ten verbs to know with Shib, upon which he based his presentation, so I’ll quickly capture them here:

Reflect
Join
Credential
Manage affil/groups
Manage privileges
Provision
Deliver authenticate
Authorize log

Next up was Chris Shillum talking about Shibboleth and ScienceDirect (Elsevier)

Shillum’s focus was on what Elsevier has been doing to integrate Shib into ScienceDirect. He showed screen shots taken earlier in the week from a live implementation showing how Shib looks to a typical user searching databases.

The first screen shot showed Science Direct. Clicking on a link took us to a WAYF service (where are you from), a simple application that provides list of all institutions in the “federation,” (a federation is the group of institutions sharing the Shib implementation). The WAYF knows where to send the user when they identify their home inst. The user selects their institution (identity provider) and then gets sent to their university’s login page (University of South. Cal. in the example). Then upon successful login, the user was sent back to Science Direct with the same rights and privileges as if they had been authorized by IP, etc.

Shillum reported that Elsevier sees this Shib as a win-win for both sides, especially since there is less administrative overhead involved. Shillum said the previous presentation gave all the concepts and ideas on the backend, demonstrating how Shib is making the delivery happen, but this example shows how simple and straight-forward this really is, how seamless.

Shillum cited the following benefits of Shib:
1) Shib could replace IP filtering. Removes administrative burden of maintaining IPs.
2) Shib decouples customer’s network architecture from authentication, allowing departmental purchases, which is very hard with IPs if a department doesn’t have its own range of IPs.
3) Also allows personalized access to remote resources using local credentials, instead of having to remember personalization passwords and logins for many different vendors, so the service system always remembers your customizations without you having to remember a separate password and identity.
4) Shib removes the need for users to remember different usernames and passwords and avoids problems of proxy servers for remote access. Bottom line: Shib helps provide the broadest access to the community.

Shillum then talked about some of the logistics and details of the Shib pilot project that Science Direct did with Dartmouth, Georgetown, NYU, UC San Diego, and Penn State.

He concluded with some of the issues surrounding Shib and vendor implementations. The technology is new, complex and rapidly changing. Federations of institutions are in their very early states. Uptake is key in moving to the next level of adoption and ubiquity. We are at a critical point. To make uptake work, we need to make implementation easier for smaller customers and vendors. Elsevier is committed to making access easier for users and will continue to support Shib.

The next presentation, more brief than the others, was by Chris Zagar, from Useful Utilities/EZproxy.

Zagar pointed out that Shib should eliminate the need for proxy servers sometime in the future, but this isn’t going to happen overnight, that everyone will be shibbolized. There will be a path where some are, and some aren’t. Zagar offered a roadmap for how to make the transition through a handout with the terminology of Shib and how it can work during a transitional period with EZproxy to make “shibbolized” and “non-shibbolized” resources work together in an EZproxy environment.

Zagar pointed out that many people probably have an environment with a variety of links to databases, etc., that point to an EZproxy server. During the transition to a Shib environment, users can use traditional EZproxy login methods that they are familiar with. This would be a transitional mode, providing a link where people can go to the Shibboleth WAYF service. Users would select an identity provider (their home institution), then use their standard netID and password. From the user’s perspective, they then just wind up in the database. To the user, this looks very similar to what they are used to with EZproxy, and they don’t have to see all of the intermediate, behind the scenes steps that go into making it happen.

Next up to the podium was John Paschoud of the London School of Economics Library, who talked about “Building a UK infrastructure for access management using shibboleth”

John brought a good deal of experience with Shib implementation from the library perspective, along with a dry British humor that lightened the mood and brought a little cadence to the afternoon. He opened with the observation that “Britain is just like America, but squashed into a very small space.”

Paschoud had a point in saying this, which was that America and Britain share similarities in the concentration of their academic activity, but the institutions are just very close together in Britain. Paschoud focused on a centralized identity management service that has been developed for British higher ed insitutions called Athens, which allows about 2.5 million users to authenticate into about 250 online resources. It is a national, UK-only system that accomplishes essentially the same thing Shib is meant to. The problem is that it is UK-only and that there is quite a bit of administrative overhead to a centralized authentication service.

The implementation of the Athens service gives the UK certain advantages in looking at Shib, particularly the fact that they have been working for 5 years on how to develop “federation” policies and practices. Federations
are organizations with a common purpose (e.g. education and research) who trust each other and sign up to a set of rules, for example who is authorized to access what resources. They also have an established body (JISC) with some centralized authority over an unruly community.

Paschoud went on to talk about what the timeline for developing a Shib infrastructure, look for institutions willing to adopt Shib, create a service for early adopters, work with publishers to make their products Shib compliant, and make national data services Shib compliant. Essentially, Paschoud was outlining a timeline going out to 2006-2007 for the whole project of “shibbolizing” the UK federations.

The big take away from Paschoud’s presentation is that identity management is happening at a national level (sort of) in the UK, but that it requires a large central database which everyone has to go through. Shib decentralizes the whole operation and puts the identity management and the authorization on the individual institutions, creating less overhead by eliminating the centralized service.

The last speaker was Mike Neuman of Georgetown University, whose presentation was “Shibboleth: Problems and Promise.”

Neuman is in the interesting but unenviable position of reporting both to the University Librarian and the CIO. His presentation was geared towareds the functionality of Shib for those in the library but not in systems.

Georgetown became involved with Shib in the fall of 2001, when it became involved in the Elsevier Shib pilot project with Science Direct.

Neuman wanted to review some of the challenges noted by reference librarians as they considered how things would work with Shib as opposed to how they work now in an IP/EZproxy environment. Among librarians there is generally a feeling that change to the status quo is not a good thing, Paschoud pointed out. But he said that some aspects of the status quo maybe need to be eliminated, and Shib might be a good way to do that.

Challenge 1: library patron groups often differ from the University directory groups. Patron groups often include non-University members, and license categories can include non-university members who may not necessarily be in the authentication directory of netIDs. For example, EBSCO has language that allows “authorized users”—so who exactly is this? Are these people that have legitimate claim to privileges, but aren’t strictly university employees? Hospital staff at Georgetown are not university employees, but they have certain privileges in the library. Shib is a way to deal with this disjoint with the university scheme of groups by allowing each individual user to have a unique identity with attributes that indicate very specifically who they are and what they have access to.

2. Licenses complicate authN and authZ models by throwing in all kinds of exceptions and limitations, such as limits on simultaneous access, restrictions on use if you’re on campus as opposed to off campus, and licenses that limit access to specific libraries or departments. E.g., the Law, Health, and Engineering libraries could conceivably be getting the same journal from different vendors. Or all three libraries could be working with the same vendor, but getting a different package of services for each library.

3. Library gate keeping. For example, sometimes resource passwords are controlled for budgetary reasons, such as resources that are licensed on pay-per-view or pay-per-search basis. At end of semester, based on budget resources, a librarian may decide to not give out the password to a resource and point user to another database. Neuman claimed that retaining gatekeeping control such as this would be complicated in a Shib environment.

Neuman also, raised the problem of delinquent patrons, who can sometimes be denied access privileges. Here there is the need for an attribute to indicate a person is blocked from using a resource or all resources. AND librarians need to have access to place and remove these blocks.

4. initially patrons may feel inconvenienced by Shib on campus if they don’t have to log into resources from on campus because of IP authentication. Dual access procedures (Shib and non-Shib) could confuse patrons.

Neuman continued by saying that it might sound from the challenges like they have been discouraged at Georgetown, but this is not true. They are bery interested in continuing to explore Shib with other vendors as well as with Elsevier. In fact, Georgetown received funding from the Mellon foundation for a proof of concept project exploring Shibboleth and scholarly communication. This is still a conceptual project, but the funding is there and planning is moving forward. The project essentially will explore the ways in which Shib can be used to promote interlinkages among various resources (for example, from a professional society publication to related resources in other databases) that are exposed in different ways to users with different identities and attributes.

The program ended with an interesting head table discussion that involved some friendly debate on several points that Neuman raised in his presentation. Essentially Hazelton wanted to make the point that some of the concerns raised by the reference librarians at Georgetown that seemed to disfavor the implementation of Shib were less about Shib itself and more about the complex identity environments that we have to deal with. Hazelton reitereated that Shib is only, in essence, the delivery boy, and it will deliver whatever it is told to between the home institution and the service provider.

The final take-away was that Shibboleth represents a remarkable opportunity to simplify the tremendous overhead of authentication and authorization in today’s academic resource environment, where many shifting groups of users with complicated identities need to gain access to a bewildering array of licensed resources, all with different terms and conditions. There is a base of support for Shib among both vendors and institutions, but in order for it to succeed as a viable alternative to IP authentication and proxy services, there needs to be a bottom-up groundswell of interest from institutions and vendors alike.

One thought on “Project Shibboleth: Issues and Answers

Comments are closed.