FirstSearch in Your Nighty


By Karen G. Schneider
American Libraries Columnist 

Director of technology for the Shenendehowa Public Library in Clifton Park, New York.
kgs@bluehighways.com

Column for September 1999


With many database vendors offering good pricing schemes for off-site use, our patrons can access FirstSearch in their underwear, retrieve full-text magazine articles in the wee hours before a class paper is due, and spend all day logged in to a session on their home computer without anyone reminding them that their time is up. And all the patron has to do is log in to a Web page, using a library barcode and maybe a PIN

There’s just one little hitch: You need a mechanism to ensure that your authorized patrons—and only your authorized patrons—can access the premium resources you have shelled out some very big bucks for.

Authentication tools provide methods for patrons to log in to subscription databases offered by libraries, usually with library barcodes and sometimes PINs, ideally from anywhere they happen to be, at any time. These tools work around the limitations of the authentication methods used in-house, such as user name/password and IP (Internet protocol) authentication. (An IP address is the numeric address assigned to an Internet site, such as 199.245.81.67 for ALA’s Web site.) Even if you could manage the administrative overhead of distributing user names and passwords or collecting IP addresses for all of your patrons, managing the upkeep on these would be overwhelming.

Homespun authentication

Many librarians have developed authentication tools and procedures and shared them with their colleagues. The level of authentication in these tools ranges from modest to stringent. At minimum, scripts perform simple calculations to verify that the library barcode falls in a range accepted by the vendor. Sometimes an additional script checks a list of barcodes that are denied access. Some vendors require that libraries verify patrons are current borrowers; in this case, a script might open a session to the online catalog and tap the patron database.

James Cayz, network processing administrator at the Delaware Division of Libraries, described remote access for his state’s libraries. It sounds like a Rube Goldberg device, but it works for them. A small program called Sia does the initial analysis of the patron’s barcode and then passes a request to a program called chkpind, which does its thing and then talks to another small (Dynix-based) program called INFO, which analyzes the patron’s status. If the barcode passes all these checks, the patron accesses the database; otherwise, he or she sees an error message.

There are trade-offs and pitfalls for each approach. The more scripts you run, and the more servers you tap, the higher the security, but the more likely it is the routine will fail somewhere. Some scripts that automate logging in with user names and passwords don’t hide this information very well, making the scripts more vulnerable to abuse. Dan Lester, network information coordinator at Boise (Idaho) State University library, points out that “some vendors solve this potential problem by also checking on their end for the page from which the user was redirected,” which at least prevents the form of abuse where miscreants set up sites with links to databases they have gained access to.

Quite often a combination of access methods is needed. Mary Elise Haug, system administrator for Indiana’s Inspire database, explained how they make the service available to everyone in Indiana, whether or not they have a library card. Schools, libraries, and local ISPs have access through IP authentication; for AOL and national-ISP users, patrons can gain remote access through a digital certificate after sending proof of residency by old-fashioned snail mail. (People in Indiana must be more patient than they are in New York.) Digital certificates have their own drawbacks, though, including that they are associated with machines, versus users—so if you are at Mom’s house, and she isn’t set up for Inspire, you are out of luck.

Some libraries also want to ensure that patrons go through their Web gateways. “Our solution was to program a proxy Java servlet running on a Linux box,” wrote Danielle Langlois, Web developer/information specialist at the Canada Institute for Scientific and Technical Information. The Java servlet also keeps the user name and password hidden from the patron.

Commercial solutions

Homegrown solutions seem cheap, but not everyone wants to expend the labor to support them. Commercial tools, of course, put the support issues on the vendor’s shoulders. Stacy Pober of Manhattan College Libraries, Bronx, New York, has been evaluating EZproxy, a product mentioned by several librarians, which is scheduled to go into full production in early August. “I admire those who program from scratch, but I just didn’t have the time to become a programmer just for this project,” Pober told me.

So far, Pober is pleased with what she sees. EZproxy can authenticate against a live patron database, a static file, or against DRA’s Web2 database. The session length before time-out can be customized. Another product, Obvia, looks intriguing, but several librarians I spoke to said their price quotes had given them severe sticker-shock.

You aren’t going to be able to support every potential platform; just know who you are serving and what your method can’t do. Find out what the tool doesn’t support and what is required of the user. Sometimes this is obvious: The tool may require browsers enabled for cookies or Java, or expect the patrons to fiddle with the settings in a browser. But other limitations are subtle: An authentication routine that causes the browser to redirect many times may exclude patrons using old AOL browsers, or a particular routine may not work for Linux users.

Find out if the authentication method is compatible with all your existing and anticipated databases, and your existing or imminent hardware and software. Some databases don’t work with some authentication methods. One library system found that it had to reassign PINs to its patrons because the 3M Self-Check machine keypad only supports numeric PINs, and theirs were alphanumeric. There’s a fun surprise!