InC-Lib-Vendor

[David Kennedy <>]

Kent,

I think it may be quite
valuable to begin a dialogue now with a few vendors who have implemented
Shibboleth, in any way, to determine the state of their implementation,
awareness of library needs, and interest in participating in a joint specification.


I wrote a pretty hasty response to this
comment yesterday.  I think this might be the best immediate next
step for our subgroup.

I have two questions if this is what
you all think we should be doing:

- To begin this dialog, should we send
a stock email to all of the vendors in our top 10 list, or just to the
three that Foster has had some initial success with?  (I am leaning
towards the former)

- If we decide to send a stock email,
is someone willing to draft it?  I am willing to, but suspect there
are others in this group better suited than me.

Dave

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

Foster Zhang <>

06/05/2009 10:01 AM

To	David Kennedy <>, Kent Percival <>
cc	"" <>
Subject	RE: [InC-Lib-Vendor] Wiki access

David and Kent,
 
Thank you for sharing your
thoughts and suggestions. I like the idea to concentrate on EZProxy first.
 
It seems to me that Jstor,
Ebsco, and Elesvier are ready for shibboleth sessioninitator access. The
work they need to do is to training their technical support staff and update
their information webpage. I know that at least Univ. of Chicago and Hopkins
have implemented the access in production, and I have not heard any problems
from the users except good feedback.
 
I would like to suggest to
work with Oxfordjournal and Sagepub, because shibboleth is available to
UK federation library already from both of them, if they can expand the
institution to US Higher Education, we are almost ready to go. See the
info from their site:
 
Oxfordjournal: http://www.oxfordjournals.org/for_librarians/shibboleth.html
Sagepub: http://online.sagepub.com/cgi/shibboleth?entityid=https:/idp0.abertay.ac.uk
 
I also found this link that has
the information help us to talk to shibboleth support people from university
IT depot and vendor technical support.
https://spaces.internet2.edu/display/InCCollaborate/Federated+Services+Offered+Through+InCommon
Foster
From: David Kennedy [mailto:]
Sent: Thursday, June 04, 2009 4:08 PM
To: Kent Percival
Cc: 
Subject: RE: [InC-Lib-Vendor] Wiki access
 

What we are asking for is a special SI configuration which supports how
the libraries want to use EZproxy  so what we really need is a specification
of how we want them to configure their SI.  We can then use that in
the Registry to explicitly denote “EZproxy-ready” vendors.

Well said! 

I think it may be quite valuable to begin a dialogue now with a few vendors
who have implemented Shibboleth, in any way, to determine the state of
their implementation, awareness of library needs, and interest in participating
in a joint specification. 

Or maybe we should begin this dialogue with the few vendors that Foster
has indicated are "ezproxy-ready", because at least we think
we know what we want, and they are already providing it.  I seem to
recall mention on one of the calls that at least one of these vendors would
like to promote that they are doing this SessionInitiator bit, was that
JSTOR? 

Dave 

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

"Kent Percival" <>

06/04/2009 03:54 PM

Please respond to
"Kent Percival" <>

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

 

Dave, 
While I was writing about the broader framework, we are on the same page
– you wrote “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.“
 we need to stay focused on EZproxy.
Out subgroup charge is “Develop a prioritized
list of information providers (e.g. JSTOR, Science Direct, etc) that the
group would like to have support Shibboleth-enabled access. Determine which
resources already support Shibboleth. Identify the top priorities for making
the business case to support Shib. Include information about which vendors
are already associated with InCommon.  Use this information to create
the beginnings of a registry of Shibboleth-enabled resources.
 As we agreed the development of the registry of vendors is the way
of understanding the vendor community and how they have progressed with
their Shibboleth implementations, especially the ones who are already delivering
services in other jurisdictions (the leaders?).   By involving some
of those vendors we can leverage some of their experience and expertise,
while informing them of library technology priorities.  
The part that may be missing from our charge (or is it for a future sub-group)
is the definition of “Shibboleth Session Initiators”.  From my understanding
they are a basic part of SP configuration – a front end controlling how
the service responds to new requests.  What we are asking for is a
special SI configuration which supports how the libraries want to use EZproxy
 so what we really need is a specification of how we want them
to configure their SI.  We can then use that in the Registry to explicitly
denote “EZproxy-ready” vendors.
I understand some vendors have already done such configurations.  Should
we be coming up with our own specification before we talk to vendors or
should we be confirming what is already out there.  Maybe we just
need to document the various ways vendors have implemented advanced Sis.
 Foster has made a great start on a list with specific documentation
of the access methods. 
  
I think it may be quite valuable to begin a dialogue now with a few vendors
who have implemented Shibboleth, in any way, to determine the state of
their implementation, awareness of library needs, and interest in participating
in a joint specification. 
....Kent 
 _ 
  
From: David Kennedy [mailto:] 
Sent: June 4, 2009 12:47
To: Kent Percival
Cc: 
Subject: RE: [InC-Lib-Vendor] Wiki access
  

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
          _