InCommon Library Services

["Declan Fleming" <>]

Hi - UCSD's group met today to prepare for next week's call.  Here our our 
comments on the question Steve asked:

"1) could each campus post to the (new!) email list the set of the 
issues they feel they'll need to address in order to begin to use 
Shibboleth within their library services. Possible issues might be 
technical, integration, user experience, process, policy, 
whatever....."

UCSD sees Shib as being used in libraries in 2 ways:

1)  Vendors as Shibbolized service providers

In this instance, vendors support Shib as an authentication and authorization 
mechanism.  Campuses have the Shib components installed and configured to 
allow their patrons access, and campus libraries have negotiated Shib as a 
viable access method.

UCSD Background

This is the state UCSD is in right now.  The Shib technical underpinnings are 
provided by our Administrative Computing and Telecommunications (ACT) group.  
A short list of vendors have Shib available as an access method to us.

We are very fortunate that our campus' Single Sign On (SSO) architecture is 
Shib/SAML based, so the Libraries have a "built-in" Shib service we can rely 
on.  I am certain this is not the case at most Universities, and getting a 
Shib architecture implemented is a high barrier to entry.  [There is much 
more to be said here about integration with existing campus identity 
management.]

At UCSD, the initial setup, deployment, and support of the Shib technical 
infrastructure is handled outside of the Libraries by ACT.  This requires 
close communication for training and any changes needed to accommodate new 
vendors coming on board.

Issues in this case include:

a)  There appear to be very few vendors available to simply turn on Shib.  
Much work is still required in polling the vendors' state of readiness both 
technically and from a contract perspective.

b)  User training, already a significant public services workload, can become 
more complicated due to the addition of another access option.  Hopefully, 
over time as Shib becomes the norm, this will settle out to be a win.

c)  With a hybrid environment, Shib may not be compelling to a user who has 
already figured out how to set up Proxy/VPN access on her machine to library 
services, and who may be simultaneously required by the vendor to also use 
Proxy/VPN access for the majority of services.

2)  Libraries as service providers

In this case, a library has a web service that they would like to secure and 
manage access to with Shib.  One case we have now is a MediaWiki instance 
that we would like to keep confined to just UCSD Libraries staff.  Another 
example is switching from barcodes to SSO for item checkout through our OPAC.

Issues in this case include:

a)  A library must have sufficient technical expertise to modify their web 
servers and web applications to work smoothly with Shib authentication and 
authorization.  For us, this was mainly a training effort.  We have enough IT 
staff within the Libraries to learn and implement a Shibbolized web 
application.  I'm not sure this is the case at most libraries.  Our ACT group 
has gone to great lengths to document straightforward procedures.

b)  User training is also an issue here.  What credentials do we expect them 
to use?  At UCSD, users do not have a single login and password that can be 
expected to work in every instance.  In fact, our campus SSO architecture is 
designed with a "plug-in" methodology where the web application provider 
chooses the set of credentials that is acceptable.  Succinctly explaining to 
a user which credentials to use is actually quite a challenge.

Other Concerns:

Privacy and Attribute Exposure Policy – ditto UofChicago

Walkup Patron - ditto UofChicago
        UCSD – Gabe Lawrence has a proposed solution
                Needs discussion to see if it can be used universally

How will places like the library set up affiliates on the fly?
UCSD working on web service

UCElinks (link resolvers) need to work smoothly with Shib’d resources
Focus on EJournal vendors to facilitate the tipping point – critical mass of 
material to drive traffic through Shib

Shib doesn’t easily support load balancing and clustering – ditto UofChicago
Critical for a core infrastructure piece

Shib doesn’t really have a standard logout method

Declan


>>> <> 04/05/07 01:45PM >>>
Change already... based on feedback, the name of the list and the 
domain/machine hosting the list have both been changed.... the old 
list name is going away....

I'd like to suggest two action items:

1) could each campus post to the (new!) email list the set of the 
issues they feel they'll need to address in order to begin to use 
Shibboleth within their library services. Possible issues might be 
technical, integration, user experience, process, policy, 
whatever.....

2) schedule the first conference call, for some time during the week 
of April 16th. Please send to the list days/times during that week 
when you're available.... That week might might turn out to be too 
close, but let's try....

I'd like to ask if the issues lists could be shared on the email 
before the first conference call.

Thanks!