InCommon Library Services

["John M. Kiser" <>]

Steve,

Related to your question about a persistent URL are a few things I've
been musing about while preparing use cases. I realized that I'm unclear
on exactly what _is_ the current/planned use case for a researcher
accessing a restricted resource from a Shib enabled vendor. On the one
hand I imagine someone simply going straight to, say, JSTOR, opting to
authenticate via Shib, at which point magic happens, and the resource is
accessed.

What I can't figure out is how--and this is probably the more typical
scenario--a researcher gets from a list of search results to the
resource in a way that makes no assumptions about how much or little
s/he knows of Shib, or even the vendor. Libraries, through a variety of
tools (e.g., Ex Libris' SFX) tend toward emphasis on the bibliographic
data, rather than the vendor. To be sure, vendor info is part of that
info display and is of interest to many researchers, but ultimately it
tends to be ancillary to the need at hand.

In other words, what's unclear to me, and what I want to remain mindful
of, is 1) how vendors participating in InCommon go about implementing
"Shib enabled"; and 2) where are there possibilities for this group to
inform vendors' efforts to realize the promise of federated SSO.
Ideally, Shib could move into place with a minimum of change in how
researchers get what they need.

Apologies for the lengthy, possibly irrelevant reply :) ... spending
time thinking about use cases raised a lot of questions for me.

Best,
jk

 wrote:
> I'm trying to write up my understanding of a model for getting EZProxy
> and Shibboleth to work together effectively. This is based on what I
> remember from Phase 1 of this effort. Unfortunately, I haven't been able
> to find any notes, and thus I'm forced to rely on memory -- always an
> iffy process. Fortunately, this group includes a couple of people from
> OCLC who are quite knowledgeable about EZProxy, and I'm hoping they will
> help move this towards "correctness".
> 
> I think of EZP as having two parts: a front-end and a proxy.
> 
> The front-end includes this sequence of steps:
>     -- a way to configure whether the destination is shib-enabled or
> not. If the destination is shib-enabled, the user is forwarded there
> directly, bypassing the proxy.
>     -- if the browser user is coming from an on-campus network, they are
> forwarded directly to the destination.
>     -- if the browser user is coming from off-campus, they are
> redirected to the proxy.
> 
> The proxy is the easy part -- that's the actual re-writing proxy.
> 
> In addition, the front-end includes some sort of authorization
> mechanism. The site manager can define groups within EZP (can the groups
> be defined in ldap?), and can then create rules such as "only members of
> Group X can access Resource Y". I'm not sure where the authZ processing
> occurs in the sequence of front end processing.
> 
> One suggestion I've heard is that it makes sense to define a persistent
> url for a provider as pointing to the EZP front-end. This would insulate
> the url from changes if the vendor moves from IP-access control to Shib
> access control. Does this idea make sense?

-- 
John M. Kiser
Project Lead, Information Technology and Digital Development
Van Pelt-Dietrich Library Center
University of Pennsylvania
http://www.library.upenn.edu/

(215) 573-5036