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 InCommon or other trusted source. Your must be released to the SP protecting this Wiki,
https://spaces.at.internet2.edu/shibboleth . If you don't belong to an 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:
- 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.
- 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.
- 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)
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
include lists of shib-enabeld vendors
pointers to various federations