Defining Use Cases for Federating Library Services

["Paul B. Hill" <>]

Hi,

I'd like get this fleshed out a little bit more:

..."2) work the “friends of the library” group (and perhaps others) into 
the Shibbolized access to resources (currently, these people are only 
stored in the library ILS system)"...

Which, or how many, of the participating schools allow, or have 
contracts which would allow, walk-in patrons access to remote resources?

Which, or how many, of the participating schools sell patron access, and 
allow, or have contracts which would allow, paid-patron access to remote 
resources?

What are the other characteristics that make someone a "friend of the 
library"?

Paul

Dean Woodbeck wrote:
> Notes
> Library Use Case Subgroup Call
> August 14, 2009
>
> -----------
> Attending
>
> Steven Carmody, Brown University
> Lynn Garrison, Penn State University
> Tim Mori, North Carolina State University
> Dean Woodbeck, Internet2
>
> -----------
> Needs/Outcomes
>
> There was a general discussion about the needs and outcomes people are 
> looking for from this group.
>
> Penn State – 1) need to go through a process similar to Dave Kennedy’s 
> during phase 1 (testing Shib and EZProxy and other applications), 2) 
> attract additional Shibbolized vendors to Penn State, 3) identify 
> additional local services offered by the library that are candidates for 
> Shibboleth.
>
> North Carolina State: 1) Shib-enabling the proxy system, 2) work the 
> “friends of the library” group (and perhaps others) into the Shibbolized 
> access to resources (currently, these people are only stored in the 
> library ILS system), 3) plug these in to a campus federation.
>
> -----------
> Shibboleth/EZProxy Work Flow
>
> A number of issues were discussed related to Shibboleth and EZProxy. 
> They included:
>
> 1) Shib-enabling an EZProxy server.
> 2) Resolving issues related to a Shib-enabled EZProxy server. For example:
>
>      a. Identifying all of the access points (like Google Scholar)
>      b. Mapping the flow when someone goes to an access point like 
> Google Scholar.
>      c. Determining the types of entitlements required for different 
> types of users (for example, those at the medical school may have access 
> to some resources to which all other users do not have access).
>
> 3) Identify issues related to multiple licenses with a single vendor 
> (i.e. some resources in Science Direct are available to medical students 
> while other resources are available to the entire campus).
>      a. Work with campus identity providers to identify issues
>      b. Getting Shib and EZProxy working together
>
> 4) Determine how to help the staff who maintain the IdP to interact with 
> vendors. What entitlements do they need?
>
> 5) Document and list pros/cons on delineating groups within EZProxy.
>      a. This can be confusing/difficult to configure.
>      b. You can configure a resource only once in EZProxy. Cases with 
> multiple licenses with one vendor prohibits this approach.
>
> It would be helpful to document how to deploy and configure an 
> integrated Shibboleth/EZProxy system, identifying the choices sites 
> would need to make. Some examples might include:
>
> 1) Document/diagram how you integrate Shibboleth and EZProxy
>      a. There is more than one way
>      b. Provide pros and cons for each method
>
> 2) Document/diagram the flow for a user browser session.
>
> 3) For both of these, include decision points and the decision that one 
> or another of the systems is making at that point.
>
> -----------
> Other Issues
>
> Federated Service Providers – There are about 100 information providers 
> in the U.K. federation; the U.S. lags in getting vendors into InCommon. 
> At Brown, for example, the librarians believe that getting the 15-20 
> most-used external resources Shib-enabled would take 90-95 percent of 
> the traffic off the proxy server. On customer surveys, users complain 
> more about the proxy than everything else combined.
>
> ARPs and Privacy Tags – Tim said that N.C. State is looking at ways to 
> determine how to handle having users make decisions about which 
> attributes third-party providers will receive. Brown is most of the way 
> through a deployment of uApprove, which allows users to see which 
> attributes are about to be released and to approve/disapprove. These 
> processes will require education of the users as to the process, but 
> also that disapproval will prevent access.
>
> -----------
> Next Steps
>
> 1) Create a wiki page for the documentation outlined above
>
> 2) Group members post any of their documentation relating to these areas.
>
> 3) Create a generic document describing Shibboleth/EZProxy integration 
> and outlining the issues.