|
Business Cases
|
From Brian Owen (Simon Fraser Univ)
Seamless to the user whether the service provider is Shib-enabled or still relying upon IP address ranges. Ideally, EZproxy could play the "middleman" role and deal with all service-provider authentication requirements. This does have implications for how one may deploy EZproxy at the local level. Will it just be used for remote access, or would all traffic be routed through it?
|
|
From Brian Owen (Simon Fraser Univ)
The other area with implications for a seamless presentation is when a user associated with an approved access institution stumbles upon the resource on the internet while not within the institutions IP range. The majority of users may not realize that they will be able to log in using their institution's credentials. They may also have difficulties with the various ways that vendors present their logon process and how the Shibboleth option is displayed. In some current implementations this requires a multi-step process:
a.) find the Shibboleth logon link
b.) select your Shibboleth federation
c.) select your institution
d.) enter your ID/password
|
|
From Andy Ingham (University of North Carolina-Chapel Hill)
UNC-Chapel Hill has run EZproxy in production for many years. We are planning to Shibbolize our EZproxy in early May 2009. Our campus computing group (ITS) is supporting the IdP and the Library will continue to run the EZproxy software as it shifts to Shibboleth.
Our main problems relating to EZproxy authentication include:
- some legitimate users (in our ILS's "patron db") are NOT represented in the ITS (campus level) user database
- some legitimate users are ONLY in a THIRD data source (neither the ITS user database NOR the "patron db")
- certain user ATTRIBUTES (for users that ARE in the ITS database) are available ONLY in our "patron db"; this will continue to require a "secondary" lookup for authorization purposes AFTER authentication against the ITS IdP
|
|
From Tim Mori (North Carolina State University)
One of the issues we deal with at the library here at NC State is having a large database of non-campus users, i.e. Friends of the Library members, who require a separate authentication path. People who join our FoL organization receive library privileges and in order to provide this, these users have been entered into our ILS system (Sirsi-Dynix Unicorn). As a result we have a few thousand accounts for which we have to provide a login method.
Our campus authentication system provides something similar to Shib's Where Are you From functionality. Users can select an affiliation, one of which is "library patron". At that point they're routed to a form on our web server that allows them to enter information that is looked up in our ILS system and subsequently a cookie is sent flagging them as authorized.
The major problem is that the accounts are just in the ILS, there's no directory system for them. We would have to either come up with a Shibbolized method of authenticating this group of users (currently it's a simple SQL lookup in the database via PERL), or I'd need to figure out how to dump out all the user accounts and import them into a directory server that Shib can access.
Another wrinkle that's added to this problem is that some electronic resources are restricted to students, faculty, and staff. We have to prove to our vendors that FoL members and/or walk-ins cannot access these resources. It appears that EZProxy should be able to handle groups of people and restrict resources based on groups, but I don't know if this functionality could be used by Shibboleth. |
|
From Kent Percival (University of Guelph)
What comes next after EZproxy?
In our case EZproxy is an access control mechanism to commercial providers, a less expensive process than managing a namespace at each provider. From an IT perspective, Federated Access permits the user to bypass the Library and access the Shibbolized commercial resource directly. EZproxy is just an interim measure until all though vendors develop Shibboleth-enabled front-ends and personalization services based on federated rather than local identities.
However, our library has incorporated access to many of these resource providers directly into their Library web services. e.g. when I do a Library search and find an article in an electronic journal the Library service redirects me to the commercial service to access the item. This permits the Library to build an integrated "intelligent gateway" to a variety of external resources. One value to the Library is that this gateway provides a central point to monitor activity, supporting future decisions on vendors and contracts. In a true federated world, users would not need to go through the Library ... so there is some resistance around lack of monitoring/control.
I'm interested to understand whether others consider the library "gateway" as an important model to retain, imbedding single-sign-on right into the Library applications, or whether the direct-to-provider model, just using simple HTTP links, would suffice. The gateway model would entail evolving the EZproxy model to something new in the Library web services to continue to manage user access to the external resources.
|
|
From Rich Wenger (MIT)
Our overall aim is to implement Shibboleth SSO as widely as possible so we can return authentication where it belongs; with central computing where credentials are managed.
Whether for personalized features of the ILS, or for access to ILLiad, or authentication to EZproxy, staff and patrons should be able to authenticate with their primary campus credentials. It should be seamless, self-explanatory, and easy to use.
Our primary campus Shibboleth IdP accepts three different modes of authentication: x.509 certificate, Kerberos userid and password, Kerberos tickets. Our Collaboration Account IdP accepts registered userids and passwords or OpenID, and connections from the InCommon Federation.
We need EZproxy to redirect patrons to those IdPs as needed, regardless of who they are and where they are coming from. |
1. Enhanced patron experience. Patrons will have one id and password that works in all environments that require authentication. Currently they must register and remember many sets of access credentials.
2. Better security. Password systems in local applications are by definition easily subverted and insecure. Central computing has the staff and expertise to
maintain a serious authentication system, Shibboleth in this case.
3. Efficiency of staff time when we no longer need to maintain ids and
passwords in our ILS, and ILLiad, and do not need to validate certificates in
EZproxy.
4. Simplified technical environment. Central computing already has an
infrastructure for authentication. Let them do it instead of managing systems that do it for each application |
From Matthew Bockol (Carleton)
Our library website contains a directory of the various services we subscribe to or otherwise recommend. The site offers an EzProxy login link for external users which essentially proxies the entire library site, allowing users to use resources through the proxy. We're currently using the default EzProxy login, and would like to change that to our Shibboleth IdP login page. Ultimately, services would be affiliated with InCommon and we could bypass the proxy entirely.
|
Simplifying users' login experiences by extending campus single signon to EzProxy and other services. We don't anticipate a hard-sell as most of our users will log in to just about anything presented to them. By building a single signon infrastructure we can hopefully get them out of that habit. |
From John Kiser (U of Penn)
Use case: 1
Name: Proxy Patron - Current
Description: Present flow for interaction between library patron and EZproxy
Primary actor: Library patron
Precondition: -
Trigger: Patron attempts to access restricted resource
Basic flow: Via web browser, patron attempts to access proxy-protected resource. By virtue of either IP-based access rules or successful AuthZ, access to resource is granted
Alternate flow(s):
1. Patron accessing from IP address external to "included" range is routed through library managed AuthN/AuthZ service before obtaining access.
2. Patron unaffiliated with university, unable to provide valid credential, access denied.
Use case: 2
Name: Electronic resource librarian workflow - Current
Description: Present flow for electronic resources librarian accessing EZproxy admin web UI
Primary actor: Librarian
Precondition: Inclusion in appropriate AuthZ group
Trigger: Librarian attempts to access /admin URL
Basic flow: Authorized EZproxy admins use shared generic credential local to EZproxy
Alternate flow(s): -
Use Cases for Desired Workflows
Use case: 3
Name: Proxy Patron - Desired
Description: Desired flow for interaction between library patron and EZproxy
Primary actor: Library patron
Precondition: -
Trigger: Patron attempts to access restricted resource
Basic flow: Via web browser, patron attempts to access proxy-protected resource. By virtue of either IP-based access rules or successful AuthZ, access to resource granted.
Alternate workflow(s):
1. Patron accessing from IP address external to "included" range is routed through university IdP for AuthN, AuthZ negotiated through EZproxy configured rules, which inspect attributes returned in AuthN assertion.
2. Patron affiliated with InCommon Federation member institution attempts accessing from IP address external to "included" range is routed through home institution/organization's AuthN/AuthZ service, routed to target.
3. Patron affiliated neither with university nor InCommon member institution/organization denied access.
Use case: 4
Name: Electronic resources librarian workflow - Desired
Description: Desired flow for electronic resources librarian accessing
EZproxy admin web UI
Primary actor: Librarian
Precondition: Inclusion in appropriate AuthZ group
Trigger: Librarian attempts to access /admin URL
Basic flow: Librarian attempts to access admin area of EZproxy, is redirected to AuthN. If AuthN successful, EZproxy consults its configuration and authorizes access
Alternate flow(s): Authorized EZproxy admins use shared generic credential local to EZproxy |
|