ACRL News Issue (B) of College & Research Libraries 6 9 8 /C&RL News Im proving v a lid access to site-licen sed resources By P atrick Y o tt an d C. H. Hoebeke Remote service authentication using a local patron database I f the term lib ra ry w ithou t w alls no longer circulates among the profession’s freshly minted catch phrases, it evokes nevertheless a concept o f information service more relevant today than when it was first coined. Among colleges and universities, at least, it is the rare library that does not make its catalog available via local dial-in, or even via the Internet, where it is accessible from virtually anywhere in the world. The phalanx o f stand-alone worksta­ tions, dedicated to a single CD-ROM or online database and operating on the principle o f o n e p ro d u c t, o n e u ser a t a time, has been largely replaced by networked products that support multiple users simultaneously, and allow ac­ cess to multiple resources from a single work­ station, very often from outside the library con­ fines, in offices and dorm rooms and through dial-up connections. But as far as w e’ve come, users who have acquired a taste for such convenience have already developed an appetite for more. They are beginning to ask why, if resources can be accessed from the office or dormitory, must there be any geographical limits at all? The faculty member on sabbatical, the graduate stu­ dent who commutes from outside the local calling district but resides near a public library with Internet access, or any o f the valid users who purchase private Internet accounts are beginning to wonder why access from outside the college or university is typically limited to the basic catalog. What about databases, dic­ tionaries and encyclopedias, and the scores of informational Web sites that can be accessed on or by dialing into campus? The reason, o f course, is that library site licenses for these resources are usually pro­ tected by restricting access on the basis of the institution’s IP domain. Every computer linked to the Internet has a unique IP address. D e­ pending on local policies and configurations, the addresses might be permanently assigned to each machine or temporarily assigned for the particular session in which the computer is connected to the Internet. Either way, all of these unique numerical addresses fall within a range or group of ranges that is assigned to the college or university. When a library pur­ chases a site license, it gives the vendor a range o f valid IP addresses in the campus domain. Users who try to access an IP-restricted re­ source from outside the domain— for example, from CompuServe or America Online— will be denied access, ev en i f they h a p p e n to b e f a c ­ ulty o r stu den ts o f th e institu tion th a t h a s p u r ­ c h a s e d th e site license. In other words, though the perimeter has expanded, the library walls have by no means been removed. A p p ro ach e s to authentication A number o f institutions have been nudging vendors to com e up with alternative means of validating users, or have devised their own. One method is to establish a go-between server that requires the user to log in with ID and passw ord, and that, in e ffe ct, sp o o fs the vendor’s computer into thinking that the re­ mote user is actually in the valid domain. An­ other solution has been the implementation of 239-50 systems allowing users to log in to a P a t r i c k Yott is c o o r d i n a t o r o f s o c i a l s c i e n c e s d a t a s e r v ic e s a t th e U n iversity o f V ir g in ia L ib r a r y ; e - m a i l: p m y 2 n @ p o e .a c c .v i r g i n i a . e d u . C. H . H o e b e k e is a s s is t a n t d ir e c t o r , in t e r lib r a r y s er v ic es , a t t h e U n iversity o f V ir g in ia ; e - m a i l : c h h 4 n @ s e r v e r l . m a i l .v i r g i n i a . e d u mailto:pmy2n@poe.acc.virginia.edu mailto:chh4n@serverl.mail.virginia.edu N ovem ber 1 9 9 7 / 6 9 9 client machine that, upon successful log-in, will send a hidden ID and password to the vendor’s system. Both of these solutions require consider­ able computing sophistication and investment, and have their limitations. The go-betw een server can be slow because every transaction between the user and the remote service must travel through an interm ediary com puter. Z39-50 requires that the desired resource have a Z39.50 server, and while this solution has the advantage o f allowing libraries to provide a common interface for all databases that are mapped to the Z39.50 client, achieving the “common denominator” often entails the sac­ rifice o f power search techniques available in the database’s native interface. And because Z39.50 is based on the MARC format, it does not lend itself to searching and displaying full text. A third option that has been devised in get­ ting around the restraints o f IP restrictions is a simple cgi script that validates users against a local database; for example, that maintained by the registrar and personnel offices. At the University o f Virginia, numerous Web forms take advantage o f such a database, authenti­ cating log-ins and passing on needed personal information so that users can make Web-based interlibrary loan requests, suggest purchases, and, in a few instances, access site-licensed databases. This approach has been used for nearly a year now by our health sciences li­ brary in providing access to OVID, and has b e e n re c e n tly ad ap ted fo r use w ith the university’s UnCover gateway. This method gets more complicated in cases where only a certain portion o f users— faculty and graduate students in specific departments, for example— are allowed access to a remote resource. In this scenario, the standard IP pro­ tection is seriously flawed. Not only would it prevent the professor on sabbatical from hav­ ing access to a service to which he or she is entitled, it would also permit access to any person off the street, solely b e c a u s e th a t p e r ­ s o n h a p p e n e d to b e sitting a t a te r m in a l w ith a v a lid IP address. The challenge in this scenario is not only to verify institutional affiliation, but to restrict usage to an authorized subset o f the library’s normal user population. One solution in re­ cent years has been to provide the vendor with a file o f all legitimate users, and let the vendor validate the patron on the host end. Since this model necessitates frequent updating, new stu­ dents and employees will more than likely in­ cur delays, depending on how often the ven­ dor is willing to make updates and on how often the library or systems staff can take the time to extract and submit the updated data. Furthermore, submitting patron files to ven­ dors raises serious privacy issues. Any kind of automated validation requires a “unique ID ,” and one that is reasonably private. For conve­ nience many institutions rely on the Social Se­ curity number, or some modified version o f it, for all manner o f automation tasks, since it is guaranteed to be unique and, in theory, at least, is known only to the user and to those staff who have a need to know. Unfortunately, providing som eone’s Social Security number to a third party without con­ sent is o f dubious legality. But even if the pa­ tron file does not contain Social Security num­ bers, there is still a privacy issue. The fact that a student or faculty member is eligible for a particular service does not mean he or she will want to partake o f it. A library is not there­ fore warranted in releasing, en masse, the per­ sonal data o f its users. On both counts, then, timeliness and pri­ vacy, local validation has the advantage over submitting patron files to the vendor, because authentication is performed against a database that is updated on the spot as the need arises, and because whatever personal information is used is explicitly or implicitly authorized by the patron when he or she initiates the log-in to use the service. D o w n , d i r t y , a n d e f f e c t i v e — o n e lib ra ry 's a n s w e r In the following example, members o f a valid subset o f the university population are authenticated against a local database, a whois server maintained by the university’s central computing division, then logged in to a site- licensed service, without in any way limiting access on the basis o f IP. A Web form prompts users to provide both their last name and uni­ versity ID. Forms subm itted w ithout both pieces o f information automatically cause the authentication to fail. Both pieces o f data are required in order to provide a modicum of security and to eliminate the accidental match on a common name, such as Jo n es or Smith. O nce the program has received both pieces o f data, it runs that data through our local whois server, and based upon the result o f that lookup, processes the user accordingly. 70 0 /C&RL News Executing a whois lookup from the prompt yields the following information (this is the result o f configuration at the University o f Vir­ ginia— your results may vary): N am e: Patrick M. Yott M a ilid /H a n d le : pmy2n Unix Uid: 4 1 3 3 5 C lassificatio n : Faculty Department: Aid Lib-Social Sci. Svcs. O ffice Phone: (8 04 ) 9 8 2 -2 6 3 0 Registered A ddr.: p m y 2 n @ V i r g i n i a . E D U p m y 2 n @ p o e .a cc.v irg in ia .e d u The script used for this validation is writ­ ten in PERL, and it is quite likely that there are individuals at your campus (if not your library) that are currently writing PERL code. O nce the validation script has determined that both pieces o f information have been pro­ vided, it executes a whois lookup and reads the resulting information into an array (list). Each line returned by the whois lookup is an item (elem ent) o f that array. We then evaluate various items to confirm the user’s status and university affiliation (he or she must be a UVA faculty member or graduate student not asso­ ciated with a professional school). An element o f an array is identified by its place in the list (subscript value). Therefore, to evaluate the line containing classification we examine the fourth item in the list (subscript 3), and to evaluate departmental affiliation we examine the fifth item in the list (subscript 4). To pass this validation test, the fourth item in our list ($array[3i) must contain (=~) either the term Faculty or Grad, and the fifth item must not contain (!~) any o f the professional schools. Let’s assume that our user has passed the whois validation. At this point our script re­ turns HTML code to the client’s browser, re­ sulting in a blank page with a submit button. By clicking on that button, the now authenti­ cated user is taken to the remote service, and is correctly logged in to the restricted system. If our user supplied both pieces o f infor­ mation, but failed the whois lookup, we need to return some text explaining the problem. Again, our script returns some rudimentary HTML to the client’s browser. Finally, we need to return a polite admon­ ishment for those who failed to provide both pieces o f the required information. This particular script, with slight modifica­ tions, has any number of applications, and in­ deed, Web forms with input boxes for “last name” and “University ID“ are appearing on more and more Web pages throughout our campus. Naturally, the technical resources at hand will largely determine to what extent the validation scheme used by the University of Virginia can be employed by other institutions. Conclusion In terms of the larger issue o f local validation, neither the programming language nor the type of user database is o f critical importance. What is important is that the database is accessible via the Internet, that it contains data that can be used to include or exclude users on what­ ever criteria are called for, and that it contains a unique identification value for each indi­ vidual, a value that is known to the user but is not available to the general public. O f at least equal importance is the coop­ eration of vendors, too many of whom protect their site licenses on the basis of IP. Until more libraries insist on the liberation offered by lo­ cal validation, the walls remain. ■ (B en c h m a rk in g cont. fr o m p a g e 69 4 ) spent at the desk by “extra” librarians (i.e., not just the two who were scheduled) and the dif­ ference between the number of questions re­ corded on the statistics sheets and the number of users who come to the desk. The extra li­ brarians contributed 10 percent of the time that was recorded; 15 percent more people were helped at the desk than were recorded on the statistics sheets. The study’s greatest value has been to give us figures that we can use to bolster our arguments for maintaining at least current levels of staff. Notes 1. G e rald L. B a lm , B e n c h m a r k i n g : A P ractition er’s G u ide f o r B ecom in g a n d Staying Best o f the Best (Schaumburg, 111.: QPMA Press, 1992), 16. 2. Jo a n n e G. Marshall and Holly Shipp Buchanan, “Benchmarking Reference Services: An Introduction,” M e d ic a l R efe ren c e Services Q uarterly 14, no. 3 (1995):59-73. 3. Susan Greco and Chris Caggiano, “Soft­ ware Support: Please Hold for Customer Ser­ vice,” Inc. 13, no. 8 (199D :96. 4. Karen L. Katz, Blair M. Larson, and Richard C. Larson, “Prescription for the Waiting-in-Line Blues: Entertain, Enlighten, and Engage,” Sloan M an agem en t Review 32, no. 2 (1991):44-53 ■ mailto:pmy2n@Virginia.EDU mailto:pmy2n@poe.acc.virginia.edu