Skip to Content.
Sympa Menu

inc-librsvcs - RE: [inc-librsvcs] InC-Library Notes - 20-Mar-2009 - Conference Call

Subject: InCommon Library Services

List archive

RE: [inc-librsvcs] InC-Library Notes - 20-Mar-2009 - Conference Call


Chronological Thread 
  • From: "Kent Percival" <>
  • To: "'inc-librsvcs'" <>
  • Subject: RE: [inc-librsvcs] InC-Library Notes - 20-Mar-2009 - Conference Call
  • Date: Tue, 31 Mar 2009 13:45:35 -0400 (EDT)

The University of Guelph is in the process of deploying the Sun IAM suite for campus and is a founding member of the Canadian Access Federation (following in the footsteps of InCommon and national Higher education access federations). 

Our Library have been using EZproxy for years to provide off campus access to commercial bibliographic services which use IP address filtering for access control and institution recognition.  A couple of yours ago our library linked our central directory ids to the patron database, mapping id to library barcode.  This allows users to sign into Library services, including EZproxy, using either the central id/pwd or barcode.  This past winter, EZproxy was linked to our Shibboleth IdP as an alternative to direct directory query.

As mentioned by others, the disparity between the IT campus directory and the patron database causes some concern.  However,  EZproxy is used mostly to control external access to purchased bibliographic services, and those contracts, for the most part, provide access only for University faculty, staff, and students which are all in our campus directory.  “Townees” (not university library patrons) with barcode cards are not permitted to access these resources.  We still have to resolve a few issues like IT contractor names added to the campus directory but should not access the Library resources.

 

Regarding my action item …

I was raising a point about understanding the future development and evolution of a Shibbolized EZproxy.  “what comes next after EZproxy?”

In our case EZproxy is an access control mechanism to commercial providers, a less expensive process than managing a namespace at each provider.  From an IT perspective, Federated Access permits the user to bypass the Library and access the Shibbolized commercial resource directly.  EZproxy is just an interim measure until all though vendors develop Shibboleth-enabled front-ends and personalization services based on federated rather than local identities.

However, our library has incorporated access to many of these resource providers directly into their Library web services.  e.g. when I do a Library search and find an article in an electronic journal the Library service redirects me to the commercial service to access the item.  This permits the Library to build an integrated “intelligent gateway” to a variety of external resources.  One value to the Library is that this gateway provides a central point to monitor activity, supporting future decisions on vendors and contracts.  In a true federated world, users would not need to go through the Library … so there is some resistance around lack of monitoring/control.

I’m interested to understand whether others consider the library “gateway” as an important model to retain, imbedding single-sign-on right into the Library applications, or whether the direct-to-provider model, just using simple HTTP links, would suffice.   The gateway model would entail evolving the EZproxy model to something new in the Library web services to continue to manage user access to the external resources.  

 

....Kent

 _

 




Archive powered by MHonArc 2.6.16.

Top of Page