InC-Lib-Vendor

[David Kennedy <>]

Kent,

I agree with a lot of what you are saying
here.  I do tend to look at this as primarily a technology problem,
though, or at least problems in which existing technologies can be used
effectively in problem solving.

There are a lot of problems to solve.
 In my opinion, all are best served if we start small, baby steps.
 Focusing on the ezproxy problems that you note does seem like the
best approach to me.  And I do think we are headed in the right direction
to get to address these problems.  We talked about a phased approach
in the last call, where phase 1 would focus on building a registry.  2nd
phase would be to focus on standardization of approach with the vendors
in the registry, but also amongst our participating universities.  3rd
phase would be to reach out to other vendors to follow.

In doing so, I am hoping that we can
move towards standard practice around two things: the integration of Shibboleth
and Shibboleth Session Initiators into vendor's resource platforms, and
the centralization of ezproxy within the library environment.

As a start, this would allow libraries
a rather seamless integration between local campus and library services
and the resources that they contract for.  But, more importantly,
I think it lays the groundwork for solving the problems that you note in
Beyond EZproxy, namely vendors/libraries getting out of the business of
IP management and the use cases for which users access vendors directly
(ie. not through the library).

For the first of these, getting out
of the business of IP management, I don't think anyone is really there
yet.  There is a key piece missing that I tried to push on in Phase
I of this working group, but did not get much traction.  And that
piece is for Shibboleth guest access (based on location) that can be overridden
for personal access.  I won't go into the details of this or why I
think it is important, but think that we can get back to it at a later
date.

For the second of these, users accessing
vendors directly, this is where EZproxy really becomes important.  Because,
well, it's easy!  We have already seen that it is easy to integrate
into the campus/library computing environment.  And it can be incorporated
into the browser, such as with libX.  Maybe it could be integrated
into google scholar?

I think I am getting a little off topic
though.  In response to your last question, I do think that we should
constrain our efforts to the ezproxy issues.

Dave
-----
David Kennedy
Systems Programmer
Perkins Library, Duke University
(919) 613-6831

"Kent Percival" <>

06/02/2009 11:39 AM

Please respond to
"Kent Percival" <>

To	<>
cc
Subject	RE: [InC-Lib-Vendor] Wiki access

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
           _