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
_
|
