Date: Fri, 29 Mar 2024 01:15:45 +0000 (UTC) Message-ID: <2030409050.7345.1711674945952@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7344_2006304164.1711674945951" ------=_Part_7344_2006304164.1711674945951 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Welcome to the home page for the InC-Library space. This wiki supports t= he Library Services working group.
Contribution to this Wiki requires an account with a functional IdP that is a member of InCommon or other trusted sour=
ce. Your eduPersonPrincipalName must be relea=
sed to the SP protecting this Wiki, https://spaces.at.internet2.edu/shibboleth
=
. If you don't belong to an IdP but still wi=
sh to contribute, ProtectNetwork is available to anyone with a non-bouncing em=
ail address.
The Shibboleth System is a standards based, open source software package f= or web single sign-on across or within organizational boundaries. It allows= sites to make informed authorization decisions for individual access of pr= otected online resources in a privacy-preserving manner.
Campus libraries have often licensed access for their community me= mbers to hundreds of commercial information providers. Access control is al= most always implemented using an IP-address based approach; if the browser = user is "on" the campus network, access is allowed. This approach works fin= e for faculty and staff in their offices, and for students in dorms. When f= aculty and staff are at home or traveling, or students live off campus, spe= cial approaches are needed. Typically, the campus will run a proxy server (= such as EZproxy) or provide a VPN service. Both approaches make the user ap= pear 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 h= ome organization (campus) makes an Assertion to the information provider th= at "this user is eligible, under our contract, to use your service". The us= er can be anywhere; there is no need to appear to be "on" the campus networ= k. 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. Addi= tionally:
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 wh=
en used together)
Choices campuses must make during the deploy process (t=
ake 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