David,
Few points from my limited experience with vendors:
1.
Vendor likes WAYFless way to use shibboleth, this is the
necessary step they have to implement anyway, this step is right after user
pick the region and institution, and vendor will redirect the login to user’s
shib location, the redirect url used by vendor in most case is the same as the
WAYFless url.
2.
Common attributes shared by vendors and
institution (for example, eduPersonEntitlement),
this is the problem area, the information is not in any place you can see
during the connection session, and among three vendors I worked with, they used
two different attribute values to endPersonEntitlement, “urn:mace:dir:entitlement:common-lib-terms” vs. “urn:mace:incommon:entitlement:common:1”.
There is also use of optional attribute eduPersonTargetedID (for
personalization, optional) .
this is the area we need to provide suggestions/recommendation/best practice to
vendor on how to implement, for example access with personal profile.
3.
Incommon federation group already developed standard attributes
released to each other, maybe we should look at the standard attributes to see
if we can give some input from library respective. Based on my understanding,
the standard attributes release are from IT background staff.
4.
Find the right contact person from vendor site, I spent one week
trying to find the right person from Elsevier, and wasted many emails last
week.
5.
Standardize on the url itself, as David suggested. “login url”,
IdP (standardize on the name:providerID/entityID), return url, target url…, and
format.
That is all I can think for now.
Foster
From: David Kennedy
[mailto:]
Sent: Friday, June 05, 2009 10:46 AM
To: Foster Zhang
Cc: Foster Zhang; ; Kent Percival
Subject: Re: [InC-Lib-Vendor] ezproxy and shib
Foster,
I do agree.
From a technical perspective, vendors won't really see ezproxy at all.
In these scenarios, ezproxy just facilitates a redirect.
I did like how
Kent phrased it yesterday as EZproxy ready specification. But, you do
rightly point out that ezproxy is really not part of the vendor's concern, and
it might actually be misleading from the vendor perspective. Maybe what
we are asking for is vendors to be capable of a WAYFless session initiation.
And that this session initiation requires a specific url that can take
two parameters, a provider id and a target url, and provide a WAYFless
shibboleth authentication to the target url.
Although the
implementation of this could possibly be quite involved on the vendor side, it
doesn't seem like there is any more to the specification than that.
What do you
think?
Dave
-----
David Kennedy
Systems Programmer
Perkins Library, Duke University
(919) 613-6831
|
Foster
Zhang <>
06/05/2009
10:31 AM
|
|
To
|
Foster
Zhang <>, David Kennedy <>,
Kent Percival <>
|
|
cc
|
""
<>
|
|
Subject
|
[InC-Lib-Vendor]
ezproxy and shib
|
|
David,
I
think that library will use ezproxy to help to redirect off campus access to
shibboleth sessioninitator site, so the vendor has nothing to do with ezproxy,
all vendor sees is the url to their shib authentication…, and the established
search/connection session will be managed by the vendor directly with users, no
proxy needed in between.
To
make the communication clear, we do not need to tell vendor about the ezproxy?
Maybe to us (library and OCLC ezproxy group), we need to find a easy way to
implement shib redirecting inside ezproxy config.
Foster
From: Foster Zhang
[mailto:]
Sent: Friday, June 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
_
