After
our teleconference discussion, I’ve been thinking about what my understanding
of the InC-Library, and the Vendor subgroup is all about. I share these
thoughts, not as a proposal of what to do but to get some feedback on how
others view the issues and alternative solution paths. What is the
specific problem we are trying to solve, and do we understand the framework for
that problem/solution?
- EZproxy:
Phase one identified the importance of EZproxy as a tool used by many
libraries to provide the users of their library we services transparent
access to contracted external services from publishers, etc.
- EZproxy
Problem 1: There are a number of issues related to user authentication,
including management of patron information as well as restrictions and
exposures of IP-address-based access control.
- Adding
Shibboleth-based authentication is a relatively easy way to use the
campus central IAM authentication resources. Differentiating
privilege requires more work with central IAM management of attributes.
- However,
there are use cases (e.g. walk-ins) that complicate the use of central
IAM.
- The
library-vendor transaction will only be fully transparent (i.e. not log
in step) if the user has first logged into their home Single Sign
On (SSO) service. This should occur when the user first
accesses anything of significance in the library web service. Various
use cases complicate this!
- The
80% solution is pretty well understood. The stumbling block
for full implementation is how to handle the various use cases inside
integration with the campus central IAM, supporting the library-vendor
connection implementation (including user database scope and privilege
management). A clear statement of critical use cases will assist
librarians to define their IAM issues to the central IAM team.
- EZproxy
problem 2: Transitioning from IP-address-based access control to federated
access control, requires a new interaction with vendors sites in which
the vendor controls access based on assertions of a campus Identity-assertion
Provider (IdP), relying on the InCommon trust fabric.
To continue to make the library-vendor transaction (almost) transparent
to the user, a richer protocol is required for the exchange.
- In
Shibboleth, the authentication/authorization process is handled by
Session Initiators (SI) sitting in from of the application. At the
basic level the SI initiates the IdP discovery process (WAYF) and the
dialogue with the home institution IdP.
- The
library-vendor interaction requires protocol allowing the library
application (EZproxy) to bypass the discovery phase by providing a home
IdP pointer. The Session Initiator also has to recognize the
significance of the transaction, bypassing the normal application login pages.
- Some
vendors are implementing specifically configured SIs (see Foster’s
information in the Registry). Work on this has been proceeding in
the UK and Germany, at least.
- It
appears that the key issue around this is the lack of documentation and standardization
by the library-vendor community. … and is this just a
library-vendor issue, or a protocol standardization for the Shibboleth
(SAML) developers/implementers?
- Beyond
EZproxy: Moving away from IP-address-based access control permits
users to access contracted resources from anywhere, based only on their
campus identity. However using EZproxy for the library-vendor link
requires the user to go through the library service, rather than go
directly to the vendor.
- If
vendors participate in the InCommon trust fabric, they already rely on
home IdPs for access assertions. Therefore they can permit users to
log into their services directly. Do vendor-library contracts
support this? i.e. to all the use cases transfer?
- From
discussions with 2 vendors, it appears that their evolving business cases
will include value-add services in their front end. i.e. their
business value will be on a new layer of generated metadata, and proprietary
functions using that metadata, not just one their collection of bibliographic
resources. Their growth model will include attracting users directly
to the value add services. How do libraries intend to integrate
these proprietary services?
- The
challenge for the vendor-library community in building better access-controlled
tools is a need to recognize and balance the priorities of the two
groups.
- Libraries
want tools to transparently integrate basic vendor content into the
library view.
- Vendors
want to attract users directly to their proprietary value-add services.
- This
dialogue requires having all parties at the table to discuss priorities,
standardization, and implementation plans. This is an service/application
not a IT design issue only. It potentially requires a much better
understanding of the landscape. Our Vendor Registry would have
provided part of the picture, but we also would need a picture of what
the R&E library community is doing.
- This
sounds like a much bigger issue. Should we constrain our effort
to the EZproxy issues, avoiding too much time on understanding where the
library-vendor relationship may go in the future?
Thoughts,
comments?
....Kent
_
|
