deanwar ramsey valena
Graziana Getz
EZproxy - A functional EZproxy installation which makes use of the authentication methods listed in the EZproxy user authentication documentation as well as an EZproxy administrator familiar with EZproxy configuration.
These EZproxy ILLiad integration instructions make use of the RemoteAuth ILLiad authentication method and one of the EZproxy authenticate user methods. Please read the documentation related to these methods before you proceed.
If you do not need to place the ILLiad definition elsewhere in the configuration file (due to a Groups statement, or the like), please make sure to include the 'IncludeIP 0.0.0.0-255.255.255.255' statement at the top of the definition.
Note: OCLC Hosted service subscribers: If you also have an OCLC FirstSearch or OCLC WorldCat local definition, you will need to make sure your ILLiad definition is placed before either of those.
The same Starting Point URL that is used for your login ( = ) will be used to populate the ILLiad system address when you send emails to your patrons (e.g. When you notify them that an article .PDF is ready for viewing).
I remembered an article I read a while back about how to turn EZProxy into a single sign-on system. Written in 2009 by Brice Stacey, it was more of a proof-of-concept article than a documentation of working code, but the snippets he provided were enough to get me started.
Since all of our internal login systems require a session variable for the username, I figured we could use EZProxy to generate the user session variable we could replace our existing login system with EZProxy3.
OCLC's EZProxy is a service which allows authorized patrons to access publisher content remotely which would otherwise be behind a paywall on the open web. We provide the IP address to our proxy server to all publishers so that once patrons authenticate into the server, their web traffic is shown as coming from a valid UMass Amherst IP address which grants them full access to our subscribed content. When patrons attempt to access subscribed content on the open web from home (via Google or directly at publisher sites) they are not recognized as an authorized user and see only a paywall. EZProxy is used by the rest of the Five Colleges and is the authentication for the majority of our eResources.
During the renewals process, stanzas should be checked against the OCLC documentation to make sure that the most recent version is being used. The best way to tell if the stanza doesn't work is trying to access a resource from off campus (or via Opera w/ VPN installed) which will trigger a Need Host page if the stanza no longer works. If a resource is cancelled or ceased and we do not retain post-cancellation/perpetual access, then the stanza should be removed from the config file.
Instructions for how to perform these tasks, including links to OCLC documentation, are included in user.txt. Since the temporary credentials we create in user.txt are not issued by OIT, the SSO login screen will not work. Instead, users with these credentials will need to bypass the SSO login screen. When creating temporary credentials, please provide the following information to the recipient:
As of version 7.1, rules can be set that when patrons trip them will cause their NetID to be logged and/or blocked. Currently the only rules which will block a patron relate to how many gigabytes of content are download, if a NetID access EZproxy from 4 or more countries, or if they access EZProxy from 20 or more IP addresses. There are additional rules which will log a NetID instead of blocking them.
Since a typical EZproxy server may run with limited memory (1 Gigabyte Random Access Memory or less) and ELK requires more memory to run smoothly, it is not practical to run ELK and EZproxy on the same server. Fortunately, Logstash-forwarder [6] is able to run with limited memory and ship logs out of the EZproxy server without significantly decreasing the level of performance of the existing EZproxy server. Figure 1 shows how ELK works with an existing EZproxy server.
Basically Logstash-forwarder works with an EZproxy server and monitors any changes of the log file of the server and sends new log entries to the monitoring server. On the monitoring server, LogStash listens for new messages (log entries) from the Logstash-forwarder and indexes them into Elasticsearch. Kibana visualizes the indexed logs and presents them to administrators.
Logstash-forwarder is a log shipper that collects logs locally in preparation for processing elsewhere. The Logstash-forwarder is written in Go language [8] developed by Google and can be compiled into one executable binary file. It is rather simple to run:
The LogStash-Forwarder running on the EZproxy server watches for any additions to the ezproxy.log file and sends newly added entries to the LogStash. The LogStash service receives new entries and indexes the entries in Elasticsearch. Kibana loads changes in the Elasticsearch indexes and visualizes in real time.
Visualization can be viewed using any modern browser. Kibana provides many ways to configure preferred views. The following bar diagram displays the amount of access from January 29th to February 3rd , 2015 at Lakehead University.
The following is a combined view of top 10 users and top 10 IP addresses. One of the top 10 IP address has been selected, shown in the bottom pie diagram and the users who used this IP address shown in the upper diagram. It is clear enough to spot high volume traffic of a user or one IP address in either top 10 users or IP addresses diagrams. Usually, high volume may indicate potential problems.
Although this approach makes easier to visualize log entries and to spot potential problems, it still requires attention to check continually. Fortunately, raw log entries have been converted into structured indexes. More proactive approaches can be developed to detect anomalies or retrieve usage counts during a period of time. For example, the following query retrieves the users associated with 2,000 or more log entries and their corresponding IP addresses:
The author would like to thank the editors and reviewers for their valuable comments and suggestions. Special thanks to Moira Davidson (Head of Technical Services at Lakehead University Library) for her suggestions to improve this article and working closely with the author to develop this approach.
QING ZOU is a systems librarian at Lakehead University and a PhD candidate at the School of Information Studies at McGill University, Canada. His research interests are integrated library systems, institutional repositories, metadata, ontology, knowledge organization systems, and digital archives.
What if a every student in a statewide, multi-type consortium could log into consortium databases with their school-issued Google or Microsoft email address? Except the 600,000 student email accounts are administered by 171 different districts, and you're a staff of two, and you're self-hosted, and you don't know your SP from your IDP?
Join the Kentucky Virtual Library as we explain how we went from What if? to That Was EZ! with the help of a patient school district IT team, EZproxy support docs, and the generous assistance of EZproxy listserv colleagues from Boston to Australia. We'll focus on nuts-and-bolts implementation steps and provide extensive documentation, including model login page html and JS to seamlessly direct users to the right authentication server, for those who want to try this at home!
A proxy server is a service that libraries use to authenticate their users to provide access to many online databases and publisher websites. Using a proxy service allows library resource vendors to authenticate users from a single point-of-access regardless of where they are located, on-campus or from their home computer.
As you perform a search or click on links on a database or publisher site, you are submitting your requests to your EZproxy server which passes them on to the original website. Data is returned to the EZproxy server which sends it back to your browser. That is why the post-proxy URL ends with .ezproxy.yourlib.org (ignoring the path).
For each resource you access through EZproxy, you must configure it separately in a block of code called a stanza. In the stanza for a database or publisher website you must specify at the minimum a Title (T) and starting URL (U). Other basic stanza directives are Host (H), HostJavaScript (HJ), Domain (D), and DomainJavaScript (DJ). Below is a basic database stanza:
The Title directive is used to identify the resource (and is used for the link text on the default EZproxy list page). The URL is used to match the EZproxy request link with the appropriate stanza to apply. Once accessed, any further links on the resource site will be compared to any D or DJ lines and if there is a match, will be proxied and given access (including any JavaScript if a DJ line is encountered).
If a database or publisher website includes multiple domains or subdomains or uses both HTTP and HTTPS, you need to add Host (H) or HostJavaScript (HJ) directives to account for them. More advanced directives are used to manage website cookies, set domains that should never be proxied, find and replace HTML code, and many others. OCLC publishes an EZproxy Reference Manual to list these directives.
c01484d022