InCommon Library Services

[Dean Woodbeck <>]

Here are draft minutes from the June 15 phone call. Please email with any changes/corrections.

Dean



InCommon Library Services Working Group
Draft Minutes
June 15, 2007
 
Steven Carmody, Brown University (chair)\
Lisa German, Penn State University
Adam Chandler, Cornell University
Joy Veronneau, Cornell University
Tom Barton, University of Chicago
Tod Olson, University of Chicago
Bob Morgan, University of Washington
Gabe Lawrence, University of California-San Diego
Holley Eggleston, University of California-San Diego
Dean Woodbeck, Internet2 (scribe)
 
**Action Items**
 
[AI] {Steve} will adjust the SFX/EZProxy work flow (found on the wiki) to start with the current fourth step (SFX server).
 
**Walk-In Library Users**
 
RL “Bob” Morgan sent an email to the list (and posted information on the wiki) concerning location-based authentication. The University of Wisconsin uses an Apache module to provide location based authentication. The Apache module and Shibboleth allow the university to maintain an authentication method that is transparent to the resource provider. This simplifies things for the resource provider as library walk-in users appear the same as user-authenticated patrons.
 
Bob’s complete statement is here:
https://spaces.internet2.edu/display/inclibrary/Location-based+authentication
 
One question still under consideration is whether the attributes sent for a walk-in user need to identify that person as such. There may also be a question regarding login/log out and persistence of attributes at public access terminals. If a guest user does not log out and walks away from the terminal, will such persistence cause confusion for the next user.
 
**EZProxy Follow-Up**
 
Steve Carmody and a number of others joined in a conference call with EZProxy developer Chris Zagar to discuss features for the next version of the software. As a result of the call, Steve has updated the wiki with a proposed flow, through SFX and EZProxy, to a Shibboleth-protected resource.
 
As currently envisioned, the flow is this:

1. User is working from off-campus.
2. User accesses MedLine, does a search, finds relevant abstracts.
3. User clicks OPENURL button, gets redirected to SFX server at their home campus.
4. SFX server provides user with a menu of choices for accessing the resource; user selects "view online" option. SFX server prepends EZproxy prefix, and redirects user to local EZProxy server, passing eventual target URL and parameters to access a single article within that target ("the deep link")
5. CURRENTLY: For shibboleth-protected resources not appearing in EZProxy's configuration, EZProxy redirects the user browser directly to the resource, and the Shibboleth transaction proceeds without further involvement of EZProxy.
6. (Suggestion from Scott Cantor) EZProxy should redirect the user to a SessionInitiator at the SP along with a parameter telling it which IdP to use, and a parameter containing the deep link URL. This will bypass all WAYF processing. The SP will use the Federation metadata to choose an appropriate protocol to use when comunicating with the user's campus IdP. The SP will then redirect the browser user to their IdP for authentication, passing along the deep link as the eventual target.

A user who has previously authenticated is redirected back to the deep link target. If the user has not authenticated, the normal process proceeds, then he or she is redirected.
While the number of redirects might not be ideal, this avoids presenting the user with a WAYF during the process. Also, if the resource is Shib-enabled, EZProxy removes itself from the process and sends the user to the target URL.
 
After discussion, it was decided that the work flow should actually start with the SFX server and #4. [AI] {Steve} will make the update on the wiki.
 
**Technical and Policy Issues**
 
Steve reported that he has reviewed the issues and questions originally posed for these calls and has created two broad categories on the wiki: 1) technical issues and 2) policy and business practice issues.
 
Technical Issues – for a full discussion, see the wiki:
https://spaces.internet2.edu/display/inclibrary/TechIssues
 
Question #1: We need to be able to continue our current level of functionality under a load-balancing environment.
 
Answer: A link was provided to the Shibboleth wiki, where the load-balancing question is addressed: https://spaces.internet2.edu/display/SHIB/LoadBalancedIdP
 
Tod said this question originally came from the University of Chicago, where load-balancing issues have been resolved.
 
Question #2: How do you configure an IdP to have multiple trust relationships?
 
Answer: See the Shib wiki: https://spaces.internet2.edu/display/SHIB/IdPMultipleFederations
 
Cornell and Penn State both reported that this would be helpful as they try to integrate their medical centers, which may be in relationships with resource providers or federations that are different than the main campuses.
 
Question #3: At least one service with which we want to use Shibboleth does not yet formally support it, but has informal support and cannot yet receive attributes.
 
Answer: This was a question from the University of Chicago, which is now working with the vendor on implementing Shibboleth. Steve mentioned that he frequently has conversations with commercial service providers about Shib issues. Send him a note if he can help in this capacity.
 
Question #4: There are some special cases where authorization relies on information not contained in the campus IdP. For example, alumni who have paid for borrowing privileges are eligible to use Interlibrary Loan, but the campus IdP does not have this information (nor should it); students working as research assistants often act as proxies for faculty and thus have two roles.
 
Answer: Sometimes libraries have their own sets of friends and associates that are not in the central person registries. Brown, for example, has a program in which local businesses can buy library access for employees. These people will typically not have IDs or credentials in the main system.
 
Tom Barton mentioned that he would like this group to consider this question and how the campus IdP infrastructure might be used in such cases. While each campus might need to have its own solution, perhaps there are similar-use models that could be developed.
 
Penn State has several such scenarios (alumni users, affiliated doctors or nurses, attorneys who teach classes but are not on the payroll). Brown has a number of community physicians that are clinical instructors in the med school; they are carried in the university’s person registry. Even this, however, may carry some attribute issues.
 
Another case involves people on campus for a short period of time that may need access to licensed materials. At UC-San Diego, such users must be authorized by departments. Another question is whether use by any such users complies with license agreements.
 
Another discussion point is remote library access for those not in the campus IdP. Reports from those on the call indicate that such users are not granted remote access privileges.
 
**Policy and Business Practice Issues **
 
Question #1: There needs to be a process or responsible party to determine the attribute release policy for each SP. This is more of an issue, for example, if the SP wants an actual individual identifier for a person, rather than just an affiliation attribute. The more privacy we erode, the more of an issue we have.
.
Campuses need processes in determining attribute release policies with each vendor. The campus asserts the attribute that the user is covered by the license. As libraries move to Shib, they need to create attribute release policies for each vendor.
 
Question #2: 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.
 
Answer: This wasn’t much of a concern to those on the call. The only negative experience may be a user having to authenticate twice – once to EZProxy for non-Shib applications and once for Shib resources. Making the local installation of EZProxy Shib-aware might be a solution.
 
Other issues raised on the call:
 
* What would be the experience to a user who is on-campus and accessing an IP address protected resource. If the resource is Shibbolized, would the user see an unfamiliar log-in process?
 
Steve said that Shib-enabled vendors continue to also support IP address authentication. As vendors take advantage of additional attributes, however, this may shift. Users and vendors may see value in personalization, for example, where searches can be saved. The user may face a log-in, which does not currently happen, to take advantage of the added value.
 
*What about the lack of a log-off function in Shibboleth? If a person at a public terminal does not log-off, the next person could operate under person #1’s authentication.
 
In many cases, the only way to log out of all sessions is to close the browser. Shib 2.0 will log a user out of any connection, provided the service provider has implemented that code. Universities may also choose to log users out after a certain time span of inactivity. The University of Washington issues certificates for a five-minute SSO vs. eight hours.
 
Steve closed the call by encouraging people to think about additional issues and concerns as the roll-out continues.


**Next Call June 29, 2007, 12:30 pm EDT**