inc-librsvcs - RE: [inc-librsvcs] InC-Library Notes - 20-Mar-2009 - Conference Call
Subject: InCommon Library Services
List archive
- 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 _ |
- InC-Library Notes - 20-Mar-2009 - Conference Call, Dean Woodbeck, 03/23/2009
- Re: [inc-librsvcs] InC-Library Notes - 20-Mar-2009 - Conference Call, Tod Olson, 03/23/2009
- RE: [inc-librsvcs] InC-Library Notes - 20-Mar-2009 - Conference Call, Kent Percival, 03/31/2009
Archive powered by MHonArc 2.6.16.