InCommon Library Services

["Ann West" <>]

For today's call.

Ann


Motivation

EZproxy has been central to the University of Chicago's plan to adopt
Shibboleth. We see a Shibboleth-enabled EZproxy as a way to provide
three key values:

   1. A consistent single sign-on method for remote electronic resources
while the resources themselves will be split between Shibboleth and
IP-based authentication. This is accomplished by relying on the EZproxy
configuration to contain only those resources requiring proxied IP
address access, and letting ILS technologies such as SFX continue to
produce URLs with the EZproxy prefix for all resources. For
shibboleth-protected resources not appearing in EZproxy's configuration,
EZproxy redirects the user browser directly to the resource, and the
shibboleth transaction proceeds without further involvement of EZproxy.
It is also possible to tune the EZproxy configuration so that on-campus
access can be proxied without requiring a login, provided the resource
provider continues to offer IP address-based access protection in
addition to any shibboleth access protection.
   2. Incorporation of access to remote electronic resources within the
campus single sign-on domain, along with other Library services and
services offered by other parts of the campus. This is accomplished by
protecting the campus shibboleth IdP with the campus web integrated
sign-on service (webISO), so that the union of local webISO, local
shibboleth, and remote shibboleth resources form a single logical single
sign-on domain.
   3. Ability to conditionally proxy access to an IP address-protected
remote electronic resource depending on the affiliation or other
attributes of the user. This is accomplished by configuring a shibboleth
Attribute Release Policy to provide EZproxy with appropriate attributes
about authenticated users. These attributes are used in EZproxy
configuration declarations to associate users with groups of resources,
enabling central management of which classes of users are enabled to
access which sets of remote resources. This is also an aspect of value
#1, in that as a resource becomes shibbolized, user attribute
information will continue to determine conditional access to the
resource. The difference is that with IP address based access, the
campus EZproxy does the policy enforcement, and with shibboleth the
resource provider does the enforcement.

Maintenance

The University of Chicago has 438 entries in its EZproxy configuration
file at this writing. We have more than that number of electronic
subscriptions, but many subscriptions coexist on the same platform. For
most services, proxying occurs at the domain level, but a few are
proxied a the host level.

Of the 438 entries, 365 entries require no special configuration. 73
entries have some special configuration directives, mostly minor tweaks.
There are just a handful of entries that have major configuration
requirements. To our knowledge, all databases are currently fully
functional; granted a correct configuration, none are hobbled by going
through EZproxy.

Most of the solutions to configuration problems come from the EZproxy
website or, if our Electronic Materials Assistant cannot figure it out,
the EZproxy mailing list. The most common problem is that a service
provider may use an internal domain that is not already in our
configuration file.

All of the configuration entries are maintained by the Electronic
Materials Assistant. Most entries are simply domain names or host names
that are exported from a database of subscriptions into a CSV file. More
complex configurations are maintained in EZproxy configuration syntax, a
key-value text file. These two feeds are exported in CSV format and sent
to central IT, which runs EZproxy. These two feeds are merged with other
configuration elements from other parts of campus to produce the actual
configuration file.

Tom Barton
Tod Olson