Web-Based Proxy Server

A web-based proxy works by rewriting the URL to the resource to include the proxy URL's syntax. Examples of web-based proxy servers include EZProxy, III WAM, and HAN. Summon fully supports web-based proxy systems by rewriting the URLs of Index-Enhanced Direct Links to include your library's proxy syntax, and by rewriting the URL in the Authentication Banner. A web-based proxy is currently the only mechanism for rewriting the URL in the authentication banner in order to redirect users to the results page.

For details and setup instructions, see this document. Also, make sure to include the proper resource domains in your proxy configuration file. These domains are listed here.

Virtual Private Network (VPN) or Browser-based Proxy Server

A VPN creates a connection between the user's computer and the library's network by providing the user with an IP address in the institution's range, regardless of where the user is physically. Essentially, the VPN client makes it appear as though the user is on campus, and subsequent access to content is via IP authentication.

Browser-based proxy servers are those that require the user to alter the settings in his/her computer's browser to connect to the library's IP range. (These differ from web-based proxies, which direct the user to a web-based login page by rewriting the resource URLs, and do not require browser configuration.) In that it allows a network user experience based upon IP authentication, a browser-based proxy works similarly to a VPN. An example of a common browser-based proxy server is Squid.

For a more seamless user experience using Summon with these authentication methods, your library's web site may be designed to encourage or require the user to log in to VPN or configure their browser before issuing a search in Summon. This way, the user will be able to access the links to content via IP authentication, without further login challenges.

If you use a VPN system, we encourage you to configure remote access by customizing the URL or text (or both) of the authentication banner in the Summon results page:

If you use a browser-based proxy, we encourage you to link the authentication banner to an informational page about how to set up a browser to connect via your system.

Alternatively, the library can choose to remove the authentication banner.

Limitations of Athens and Shibboleth

Within the architecture of remote-user authentication, Athens and Shibboleth are identity providers and not end-to-end single-sign-on solutions. If your library uses Athens or Shibboleth, you will still need to use a web-based proxy server for the best remote-user experience in Summon. The US-based Shibboleth federation, has published an excellent Best Practices document that explains the Shibboleth/EZProxy hybrid model in detail

If your library is using Athens or Shibboleth but has no web-based proxy server, your patrons will encounter challenges in three areas: authentication banner, index-enhanced direct links, and OpenURL linking through 360 Link.

Referring URL Authentication

The Summon service supports Referring URL for remotely authenticating users into your library's subscribed content, but Support is required for configuration.

No Remote Authentication Method

If there is no method of remote authentication configured in your library's Summon service or in your library's systems, then remote users of Summon will be directed to vendors' login pages instead of accessing their subscription content when they click Index-Enhanced Direct Links, because the vendors will not recognize that the user is affiliated with your organization. Also, the authentication banner should be removed or customized to serve as a custom link if desired.