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
_
