Background
UNC-Chapel Hill has been running EZproxy for many years and as is the case at other institutions, it is a critical and heavily used resource for the campus community. The companion diagram shows an oversimplified representation of our current environment. The "library run auth selector page" contains four options that fall into the three categories represented in the diagram. The "main campus ID" selection accounts for 84% of uses with "AHEC" accounting for roughly 13% and the two types of "patron db" authentications accounting for the balance (roughly 3%). The "patron db" is the database of ILS users managed by staff within the main University Library, the AHEC database is managed by staff at our campus's Health Sciences Library, and the "main campus ID" is obviously managed by central computing on our campus (ITS) and is the ID used for campus email, personal web space, corporate calendaring, and many other applications.
Recent history
Over the last 18 months, ITS deployed both test and production Shibboleth IdP's, became a member of InCommon, and worked with Library staff to map out a strategy forward. During 2009, we worked with ITS to transition the AUTHENTICATION for the "main campus ID" users from LDAP to Shibboleth. The AUTHORIZATION step has historically used a lookup of information (patron type and expiration date) in the ILS's "patron db"; this REMAINS the second step of the process. [The "AHEC" and straight "patron db" paths, by comparison, handle AUTHN *and* AUTHZ via a single connection out to their respective external datasources.]
Future plans
To begin to more fully utilize the capabilities of Shibboleth, the next phase for us will be to move that "second step" (see above) from a patron db lookup to an evaluation of the eduPersonEntitlement attribute released by the Shibboleth IdP during the AUTHENTICATION step. We continue to work with ITS to help test the proper population of that value for the appropriate UNC affiliates, as we are the first campus service to use the eduPersonEntitlement. It is worth noting that the time and effort involved for ITS to not only get the right affiliates "entitled" but to set up and maintain appropriate mechanisms for keeping those entitlements correct (as people join and leave the University or change roles at the University), is incredibly significant. It is, however, a necessary foundation on which to build access for remote resources.
Beyond that, the focus will shift to incrementally (i.e., one-by-one) enabling Shibboleth directly with licensed external vendors.
The hope is also that there will be opportunities to consolidate the three separate paths we currently have down to a single Shibboleth-enabled path, but that will likely prove to be a tough task for a number of reasons.
