Desired or Improved method of Proxy Patron
(Also known as seamless proxy)
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?
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:
- find the Shibboleth logon link
- select your Shibboleth federation
- select your institution
- enter your ID/password
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.
Business Case
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 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.