[WEB4LIB] Authentication Scripts, Tricks and Traps

Tue Jul 13 13:47:06 EDT 1999

On Tue, 13 Jul 1999, Karen G. Schneider wrote:
>Hi, for my next column in American Libraries, I am doing an overview of
>current authentication technologies.  Part of me wishes I had a Real Audio
>of the LITA IG on this topic held at ALA Annual I could turn over to my
>editor with the comment, "they post for me" (with additional voice-over by
>Tim Kambitsch), but failing that...
>
>1) I would like to hear from libraries that have developed (and by
>inference also rejected) solutions for allowing patrons to log in to
>subscription databases and other "premium" or limited-access resources, or
>for authenticating patrons per se for using Internet workstations
>
>2) I'd like to hear some of the constraints libraries considered when they
>developed this access--e.g. were they concerned about lower-end browsers,
>visually-challenged users, etc., and how did this affect their decisions
>
>4) I'm interested in what libraries do to balance access, accountability
>and privacy 
>
>5) Painful war stories, lessons-learned, and heart-warming anecdotes are
>always welcome 
>

Karen,

I know we have spoken before, but I am willing to speak again.  The
question is how much do you want.....

I've been designing, implementing, testings, living and breathing remote
patron authentication since 1993.  I've had several incarnations of
systems, most of those I've scrapped are where many companies are now
(copy the patron database every N (days/hours)), and as far as I know,
thanks to me, Delaware is the ONLY place where remote patron
authentication is done in BOTH real-time and across several ILS systems.

But, its been a long strange trip....

Back in 1993, I was working at the State Library, putting the final nails
into the coffin of our Delaware Union Catalog (DUC) on CD product.  The
Wilmington Public Library had had a ILS (Carl) for several years, but it
sorely needed upgrading.  So, with a lot of effort, we secured state
funding to help in Fed. LSCA matches, for 4 years, to automate the public
libraries in Delaware.  

The concept was simple.  Wilmington (an independent library) had a couple
of branches.  New Castle County had 11 branches, roughly half were (at
that time) county-run, the other half were independent city or board-run.
Sussex County was similar in number (15) and division.  And Kent County
had 4 independent libraries, the State Library, and the Kent County
Library Bookmobile.  The "ILS" divisions were agreed upon, and some of the
county <-> independent bickering was resolved.  

We knew we needed a network to interconnect all the libraries.  Our State
Information people were not running TCP/IP at the time, something I
insisted on.  So, I went to, and made friends with, the local Community
College, who already had a statewide 56K Network between their 4 campuses,
AND the Internet (Web?  What Web????).

Within weeks, we had a connection, and then an agreement between the State
Library and Delaware Technical & Community College (DTCC) to provide
network connections to each library, for the price of 2 network cards.
Originally, only the central sites of each ILS would attach to the DTCC
network - each library would be fanned out from each ILS in turn. But, it
also meant that users of one system could telnet from their local system
to another....

I installed gopher as a login on one of the two up-to-then installed
systems, but needed a way to control access.  I lived by one of the
decrees from DTCC that I still adhere to:  No Anonymous Access....

I reverse-engineered, sort of, the Dynix Patron File, and wrote a program
that would read the file, and get valid Barcodes & PINs, which were already
in place to reserve books, etc.  The process took hours to run, and
nowhere near perfect (people would appear and disappear from the compiled
list, randomly), but it was a start.  I did this against those two
systems, once a week....

Several things precipitated a change in late 1994, early 1995:
1) The WWW started to get a lot of press, and a text-based browser called
Lynx was now available to "surf the web".
2) The errors in my RE program were getting out of control.
3) People didn't want to wait a week to get access after they got their
library cards.
4) I needed some kind of parental control for children's access.
5) The next two systems were due to come up shortly, and I didn't want to
copy "a mess".

I contacted Dynix, who seemed to be the vendor-of-choice for the 4 library
systems, to write me a simply program that would be resident on each
system.  "INFO", as it is still called, is a program that, if the user is
locally logged into each library system, into the correct account, will
take a barcode, and return a field of information back from the patron
record, as requested, by field number.

That was all I needed to get the ball rolling - that missing link of Dynix
code I knew nothing about at that time.

I then wrote a wrapper program called chkpind (check PIN daemon), which
basically calls that program internally, emulating the keyboard and
console, and transfers it to TCP/IP socket calls.  It would pass in the
barcode to INFO, and pass out error messages (no such barcode, "lost",
etc), check whatever local field was used for denying Internet Access
(some systems use a PSTAT, some use the start of the guardian name field)
and return an error if denied, or, encrypt the now-valid-user's PIN using
one-way encryption back to the requester.  The requester _should_ be the
central brain.  (Actually, I have added several safeguards to make sure it
is the central brain, after someone tried (unsuccessfully) to crack my
system way back when)...

I wrote the central brain program (sia - start internet access) that would
look at a barcode, do some quick sanity checks (checksum, length, etc),
check a MASTER "non-allowed list"  (for patrons who break not only a local
Acceptable Use Policy, but the State Acceptable Use Policy), figure out
(by the library identification field of the barcode) which library to send
the query to, and send off the query.  The central site, which is now a
separate machine from the ILS systems, processes & logs all of the
requests and replies.

Although chkpind (the remote ILS program) hasn't changed much in the last
few years, I am now on version 53 (increment by 1) of sia.  I used to have
separate versions for all the different types of authentication I was
running - I had Lynx, Vista, and was working on Netscape in-library
authentication.  Now, I have merged them into 1 source code & two compiled
versions that can handle any number of authentication requests, due to the
fact that it is now entirely table driven.  

Today, the system appears to the user as the barcode & PIN prompt for:
1) Lynx access from the Dynix Gateways menu
2) Netscape authentication from PCs in libraries (more on this below)
3) Licensed Resource Authentication, using referring URL method, for
several vendors' licensed resource, with several entry points for each
(depending on browser level)
4) Who knows what is next....

As I said, it is now table driven, and it takes all of about 5 seconds (3
of which are enforced "delays" to prevent cracking) to authenticate a user
for any of the above in our state.  The central system is maintained at
the State Library, and continues to be upgraded to bigger & better Web
access, deliver more statistics, etc.  The remote chkpind and associated
user (Fred) is fairly static, and only causes us concern whenever Dynix
does system upgrades, and they inevitably delete or fail to include the
Fred account in the process.

GUIs:

The Graphical User Interface (GUI) Access Project built upon this system,
but also took on a life of its own.

Whereas the basic authentication is the same, a couple of special hooks on
the central sides needed to be put into place in the tables, so that the
standard headers and footers for our website wouldn't be put on the top of
each page presented.....

See, the GUI authentication screen had been java-scripted to remove all
toolbars, buttons and menus, and the local PC security system removed
control keys and other temptations.  Just a clean grey slate to put a
barcode & pin field in, and some messages about the system's use.  If I
had to return an error page (invalid PIN), I didn't want to return a
standard header to our pages, since they contained active links to other
sections of our web site.  So, a special code & non-functional headers
were designed to be presented to GUI users if their barcode or PIN was
incorrect.  If the barcode & PIN was correct, the authentication program
would send back an html page full of javascript that turned all the menu
bars and buttons back on, within reason. 

To be honest, the hardest part of providing WWW access to Delaware Public
Library Patrons has been the securing of the local PC, since I had already
solved the authentication problem years before.

And that's where we are today.

I have heard of several companies that are still using "database pulls" of
barcodes and pins, something I dropped years ago.

Recently, Dynix introduced a new Pac4Win which has some of my system's
functionality (real-time authentication), but limited to only to the local
ILS.  It has other good features, such as time-outs, SUPPORT, which are
things that the State Library can't promise (what if I get hit by a truck
one day...).

Those are all things out there on the horizon.

Things I have learned:

If you make decisions, THINK about them first, and make sure EVERYONE
involved understands why the decisions were made the way they were.

-> We made a decision that if a parent said "No Internet Access", that
meant no access to the WWW, Internet, or any of our across-the-wire
licensed databases.  Why - Technically, the databases are across the
Internet, and two, we change databases annually.  We can't re-poll each
parent every year to find out if this database is OK, but not this one,
etc.  And last - most new databases have links to the WWW anyway...  How
do we police this use in a WWW environment?

-> The library cards identify which library the person initially got their
card from.  If the person moves, and retains their card in a new system
(say they move across counties), and either A) if they use a new PIN in
the new system,  or B) their card expires at their original system, then
everyone gets confused and upset when that person no longer has access
privileges.  It seems I can re-iterate this one until I am blue in the
face, and it doesn't seem to help.

Make your system either 100% comprehensive or 100% flexible.
-> The reason that the remote chkpind hasn't had to be touched is that it
does everything now.  Since it can answer any request that the central
server kicks to it, I haven't had to change *IT*, just the central server.

-> I learned after making 40+ code version changes that rewriting the
whole thing to use tables "on-the-fly" didn't dramatically increase the
time needed, nor CPU resources, but it made making new authentication
entry/exit points TRIVIAL.

Access vs. Privacy... 

There is a state law making all patron library records private, and
requiring a court order to release.  This has lead to some problems where
our users have used Lynx to send nasty mail to remote websites.  I have
hacked Lynx to include their barcode as part of the From: field in mail,
and have some rather adamant requests by some people to get a name and
address.  I have included in the authentication system the ability to put
a message to a specific barcode, to be displayed the next time the user
requests access.  Being able to tell an irate webmaster that I can't tell
him who the local abuser of his website is at least partially offset by
the fact that I can at least assure them that *I* can talk to the user,
and restrict / suspend that user's access if they don't abide by our
Acceptable use Policy.

 - - - - 

Whew,  what a mail.

If you need more information, please feel free to let me know.

I hope this helps you and other librarians...

James Cayz

+--------------------------------------------------------------------------+
| James Cayz  #  cayz at lib.de.us #  DelAWARE homepage: http://www.lib.de.us |
| Network Processing Administrator #  302-739-4748 x130 # Fax 302-739-6948 |
| Delaware Division of Libraries # 43 S. DuPont Hwy / Dover, DE 19901-7430 |
+--------------------------------------------------------------------------+