Library Services working group

Welcome to the home page for the InC-Library space. This wiki supports the Library Services working group.

Contribution to this Wiki requires an account with a functional IdP that is a member of InCommon or other trusted source. Your eduPersonPrincipalName must be released to the SP protecting this Wiki, https://spaces.at.internet2.edu/shibboleth . If you don't belong to an IdP but still wish to contribute, ProtectNetwork is available to anyone with a non-bouncing email address.

What is Shibboleth?

The Shibboleth System is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.

What Value Does it Provide to Libraries?

 Campus libraries have often licensed access for their community members to hundreds of commercial information providers. Access control is almost always implemented using an IP-address based approach; if the browser user is "on" the campus network, access is allowed. This approach works fine for faculty and staff in their offices, and for students in dorms. When faculty and staff are at home or traveling, or students live off campus, special approaches are needed. Typically, the campus will run a proxy server (such as EZproxy) or provide a VPN service. Both approaches make the user appear to be "on" the campus network. However, both approaches have problems, and users often feel that access from campusis unreliable.

Shibboleth offers a new approach to access control. The browser user's home organization (campus) makes an Assertion to the information provider that "this user is eligible, under our contract, to use your service". The user can be anywhere; there is no need to appear to be "on" the campus network. There is no need for proxy servers or for using a VPN service. The user's home campus can optionally provide additional information to the service provider; in return, the user would expect to get additional services. Additionally:

  1.  A campus can use the Shibboleth logs to obtain information about the usage level for each resource. How many unique users; what is the demographic breakdown.
  2. Shibboleth attributes allow a campus to send an opaque value unique to each user to each service provider. The service can use this to personalize the service for each user (eg remember searches, personalize the site, etc). However, the user remains anonymous to the service provider.
  3. Shibboleth can be used to provide SSO in advanced use cases (eg while on an abstract service, user clicks an OpenURl button, gets redirected t the campus link resolver, and gets forwarded to a deep link with the service provider).

2) Deploying Shib within a Library Access Control infrastructure
    typical use cases (not actual ones, but rather ones we think are typical), and options for addressing them
        include a use case referencing link resolvers
    Shibboleth + EZP -- separate + together (added value when used together)
    Choices campuses must make during the deploy process (take existing content, and reformulate for public consumption)
        Technical Issues
        Policy and Business Practice Issues (release targetedID for everyone ?, etc)
        User Experience Issues (logon for on-campus users?, user experience, public terminals in the library, etc)
    Other Deploy Options
        describe some of approaches that are out of the mainstream...

3) Actual Use Cases
    -- from campuses

4) Implementation Recommendations for Vendors

5) Presentations

6) Resources
    include lists of shib-enabeld vendors
    pointers to various federations

  • No labels