|
|
Endeavor Implementation Project |
What is a proxy server? According to the internet.com Webopedia, a proxy server is a server that sits between a client application, such as a Web browser, and a real server. It intercepts all requests to the real server to see if it can fulfill the requests itself. If not, it forwards the request to the real server.
Proxy servers have two main purposes, to improve performance and to filter requests. The UH Manoa Library is considering a proxy server for the latter purpose, that is, to block or filter user access to certain web sites. The kinds of sites involved include chat rooms, free Web email accounts and restricted access (licensed) remote databases.
First - THANKS to Randall for showing us some possibilities on a "real live proxy server". I hope everyone else found it as useful to see in a concrete way how the options might work.
From my notes, here's what I believe was discussed/decided - let me know what I missed or got wrong.
* Rather than going the route of many sites investigated by Steph (where each copy of a browser has to be set up with proxy configurations - and we'd have to help endless numbers of users configure their home and office browsers) - it was decided to use one or more proxy servers located in the library. The former method was called "application proxy server" and the latter method "mechanical".
* Randall demonstrated a proxy server set up to block "forbidden words" and specific URLs. This method will most likely be implemented within the libraries in the near future, after a) PSH has made an advisement to Library Admin concerning email use, express search workstations, etc. b) specific IP addresses of public workstations to route through the "forbidden word proxy server" are identified and given to DNS and c) current proxy server is upgraded from Linux OS to Unix OS (for enhanced security against hackers) This type of proxy server is what Kapiolani CC Library is currently using.
* Randall demonstrated the use of EZProxy server software - the demo used a small manually-input list of license-controlled URLs and a list of patron IDs and names. If this system is implemented "for real" it would require a) higher powered server equipment b) special programming to pass information to and from the Voyager application server and to compare the data passed from the EZProxy server against the Voyager patron database.
* The advisability of including two URL addresses in each Voyager bib record describing license-controlled databases (and on web page descriptions of same) was discussed. (Connections passed through the proxy server slow down the response speed and put a greater burden on the network.) One URL would be for use by in-house/on-campus/hawaii.edu domain connectees, the other would be used for remote connectees from domain addresses other than hawaii.edu and would be passed through the proxy server. This issue would have to be taken up as a policy question by Coll Svcs Division and/or PSH and/or DHG.
* The use of the WRLC Perl script to control login access was discussed as an option to consider as either an adjunct to, or intermediate step toward use of EZProxy with Voyager patron file data. Phil Boyer of WRLC sent me a copy of the login script which I forwarded on to Systems (most recently on August 15), he describes the system they are using this way:
We currently are using both perl, for proxy server authentication, and java to look up patrons in the patron file. These lookups occur outside of WebVoyage. Our perl authentication is using a socket connection to communicate with the proxy server. This example uses oraperl. We also have a version of it which uses the DBI interface. If you would like a copy of that, please let me know.
* URL links that currently use login/password forms of authentication rather than IP address checking are not solved by either of the 2 types of proxy servers demonstrated. [NOTE: Darren has reported that he "found a cgi script that house the actual URLs in a text file that resides in the cgi bin, so the URLs would be protected" and he will be testing it out on the "Image Server". If it works, then that script can be used for databases like RIA and RLG Archival Resources that use login/password forms of security.]
* In order for the EZProxy software to work, a list (table?) of URL addresses of license-restricted sites needs to be created for the software to reference. This list could be probably be generated relatively painlessly by the ERL (electronic resources librarian, aka Steph) from her existing Access database.
* Preliminary specs for how the software Jerard would have to write in order to use EZProxy to authenticate against the Voyager database:~ Program should use ACTIVE barcode, last name, patron record expiration date and patron group code to validate patron.
~ EZProxy form would accept input from patron of barcode (10 characters) and name (defined number of characters?) and then pass this information along with the URL of the database to which the patron is trying to connect (info from the link clicked or the list/table used by EZProxy) to the Voyager server.
~ Program on Voyager server would
a. match barcode against appropriate barcode data in patron database, if match, continue, if no match return an error message to EZProxy server and to screen of patronb. match last name against appropriate name data in patron database, if match, continue, if no match return an error message to EZProxy server and to screen of patron
c. check expiration data in patron database, if date is greater than (>) today's date, continue, if date is less than (<) today's date return an error message to EZProxy server and to screen of patron
d. locate patron group code in patron database for the validated patron, match the requested URL information against a table of URLs with associated "allowed" patron group codes@. If patron group of validated patron is allowed to access URL requested, continue. If patron group is not allowed to access the requested URL, return an error message to EZProxy server and to screen of patron.
e. If all steps of validation return "true" then pass a "Y" back to EZProxy and URL link request is passed out to the network
ERL in conjunction with Access Svcs Head would have to create the table of URLs and patron groups and provide updates to Systems if changes in license agreements affect this step of the validation.
CONCLUSIONS:
1. DNS waits for PSH/Library Admin to come to a decision about email, chat rooms, etc. before taking further action on the "forbidden word" server.
2. Any further development of EZProxy will depend on whether Jerard can write the program(s) necessary to use the Voyager patron database for authentication.
Comments to Wil Frost, Head, Library Information Technology Division, University of Hawai'i at Manoa Library, 2550 The Mall, Honolulu, Hawaii 96822 USA. Last modified: September 18, 2000.