[11321] in Public-Access_Computer_Systems_Forum
Patron Authentication - Summary of Responses. (fwd)
daemon@ATHENA.MIT.EDU (Monica Kulaski)
Thu May 22 20:11:46 1997
Date: Thu, 22 May 1997 16:12:51 -0500
From: Monica Kulaski <kulaski@astro.ocis.temple.edu>
To: PACS-L@LISTSERV.UH.EDU
Reply-To: Public-Access Computer Systems Forum <PACS-L@LISTSERV.UH.EDU>
----------------------------Original message----------------------------
As promised I have brought together the eight responses that I received
as a result of my inquiry a few weeks ago on patron authentication. From
what I received it is clear that a lot of us are facing this problem and
those responding have used different ways of addressing their unique
situations.
IMMEDIATELY BELOW IS THE MESSAGE THAT I HAD ORIGINALLY SENT OUT ON 4/29:
We would like to find out what other sites are doing regarding
patron authentication. Our situation at Temple is as follows. We
are providing numerous electronic journals and databases via our
Web page. Now our users want to access these resources from home
and the university has set up PPP access which authenticates our
users and allows them entry into these licensed databases.
However those users with their own internet providers want to use
this rather than Temple's PPP access, thus avoiding long distance
charges. Has anyone set up mechanisms where users can use their own
ISP's and still be authenticated in some fashion so that those
authorized are provided access? However, we do not want to get into
the business of handing out accounts/passwords, etc. and handling
each user on an individual basis. Thanks for any ideas that you
might have for us. I would be happy to summarize for list should I
receive some interesting responses.
*****************************************************************
RESPONSE #1:
Date: Wed, 30 Apr 1997 08:07:34 -0400
From: Bill Trefzger <billt@nist.gov>
To: KULASKI@astro.ocis.temple.edu
Subject: Re: Patron Authentication/Restricted Electronic Resources
Monica,
Here at the NIST, on our "NIST Virtual Library" web site, we have
implemented CGI scripts which check IP numbers, and deliver either
an internal or external file depending on where they are coming
from. The internal files contain links to "premium" databases and
journals we are paying for.
The scripts also do some other special functions, such as logging
all sessions on these premium services, and password protecting
some services when accessed from public terminals on our campus.
The main script uses a list of IP numbers, because in addition to
our main campus network, we have several affiliated locations which
also need access.
We currently do not do this, but it would not be a stretch to have
users provide their at home IP numbers into a form available only
from your campus network, and a have script add that new IP to the
list of approved numbers. This assumes that users have a static IP
number at home, not always the case.
A simplier (for users) but less secure method would be to issue a
password automatically in the same fashion, i.e., from a form
accessible only on campus. In either case, the need to automate the
whole process would make it less secure. I would recommend some
regular checking of the whole thing, including usage patterns for
at home users, and possibly adding some additional requirements,
e.g., only sening passwords out via e-mail to campus accounts, etc.
Good luck, there are probably numerous other valid approaches, but
you should be able to do what you want to. Keep in mind that some
offsite services you subscribe to might also use IP restrictions,
which would effectively keep these people out.
Bill
Bill Trefzger
NIST Electronic Information phone:(301)975-2146
& Publications Program fax:(301)869-8071
Bldg 101, Room E106 mailto:billt@nist.gov
Gaithersburg, MD 20899 http://nvl.nist.gov/
*****************************************************************
RESPONSE #2:
Date: Wed, 30 Apr 1997 11:47:26 -0400 (EDT)
From: Douglas Morton <dhmorton@library.uwaterloo.ca>
To: KULASKI@astro.ocis.temple.edu
Subject: Re: (FWD) Patron Authentication/Restricted Electronic
Resources
Monica
One of our mailers did rude things to your original post but the
words are there... We're in the throws of something similar. We use
a proxy server for some applications (eg restricting telnet
sessions from public terminals) but are now looking into the bigger
problem of authenticating our users. It's grown from a library
effort to a campus-wide effort; Bill Oldfield, the person who sent
the comment, is on the committee. He might also be able to provide
more details on how our proxy server is configured.
Within the Library we had identified some sites of interest. Since
the page was on our restricted access StaffWeb I've attached the
source listing which, if we're lucky, will help.
Doug Morton *
Reference & Selector - Civil & mechanical Engineering *
Online Searching - all subjects *
Davis Centre Library, University of Waterloo *
x2648 DHMORTON@LIBRARY.UWATERLOO.CA *
http://library.uwaterloo.ca/~dhmorton/doug.html *
---------- Forwarded message ----------
Date: Wed, 30 Apr 1997 09:26:47 -0400
From: William Oldfield <wroldfie@library.uwaterloo.ca>
To: Douglas Morton <dhmorton@library.uwaterloo.ca>
Subject: Re: (FWD) Patron Authentication/Restricted Electronic
Resources
Doug...
You could tell them to try a proxy server that requires logon. If
people use a local IPS and then set their browsers in proxy mode
where logon is required they can then access all local resources
because all their requests would come from the local proxy server.
William Oldfield
Networked Information Research Associate
University of Waterloo Library
wroldfie@library.uwaterloo.ca
http://www.lib.uwaterloo.ca/~wroldfie/home.html
----------
> From: Douglas Morton <dhmorton@library.uwaterloo.ca>
> To: Authentication sub-committee -- Douglas Morton
<dhmorton@library.uwaterloo.ca>; Susan Moskal
<srmoskal@library.uwaterloo.ca>; Bill Oldfield
<wroldfie@library.uwaterloo.ca>; Richard Pinnell
<rhpinnel@library.uwaterloo.ca>; Charles Woods
<wcwoods@library.uwaterloo.ca>
> Subject: (FWD) Patron Authentication/Restricted Electronic
Resources
> Date: Wednesday, April 30, 1997 8:51 AM
>
> FYI from PACS-L. Looks like we aren't alone
> Doug
*****************************************************************
RESPONSE #3:
Date: Wed, 30 Apr 1997 07:49:08 -0400
From: Steve Cavrak <sjc@lemming.uvm.edU>
To: V2038A@VM.TEMPLE.EDU
Subject: Remote authentication
Been doing it for several years - all electronic access is
passworded; if user doesn't enter University ID name and University
ID pin, they are limited to public databases. The authentication is
via the same mechanism that allows a patron to borrow a book; a
small routine was written to manage this access.
- you can try it at telnet:sageunix.uvm.edu
- the systems librarian is Paul.Philbin@Uvm.Edu
Steve
Stephen J. Cavrak, Jr. URL: http://www.uvm.edu/~sjc/
Assistant Director for E-Mail: Steve.Cavrak@Uvm.Edu
Academic Computing Services Phone: 802-656-1483
University of Vermont Fax: 802-656-0872
Burlington, Vermont 05405 North: 44o 28' 33"
West: 73o 12' 45"
NOTE: Steve contacted me later to say that they have recently begum
experimenting with a Java based authoriztion module. They are not yet sure
where it will fit in the scheme of things. The Java applet communicates
with a kerberos-like security server. (5/22/97)
*****************************************************************
RESPONSE #4:
Date: Wed, 30 Apr 1997 08:37:42 -0500 (CDT)
From: David P Atkins <notdpa@unix1.sncc.lsu.edu>
To: Monica Kulaski <V2038A@VM.TEMPLE.EDU>
Subject: Distributing Login Information (fwd)
Hello Monica,
Here's a copy of a message I posted to web4lib the other day.
David
David P. Atkins
Electronic Reference Services Librarian
Middleton Library email: notdpa@unix1.sncc.lsu.edu
Louisiana State University voice: (504) 388-6823
Baton Rouge, LA 70803-3300 fax: (504) 388-6825
---------- Forwarded message ----------
Date: Thu, 24 Apr 1997 18:05:27 -0500 (CDT)
From: David P Atkins <notdpa@unix1.sncc.lsu.edu>
To: web4lib <web4lib@library.berkeley.edu>
Subject: Distributing Login Information
Hello,
I've taken much from the list. Now I'd like to contribute. The
body of this message deals with one method of managing LogIn IDs
for off-campus WWW services. If you are lucky enough to have
unique patron ID validation of services, this is old hat. If not,
it may be useful.
Thanks,
David Atkins
For those folks who are interested in distributing Login
Information for WWW services via the WWW, the LSU Libraries now has
an Off-Campus Gateway Service (http://www.lib.lsu.edu/gateway/).
As we have WWW resources available to LSU patrons wherever they are
on the Internet but we do not have unique patron ID validation, we
still must distribute a global ID that allows folks into WWW spaces
formerly restricted to LSU campus access only. With htaccess on
our webservers, if the server receives a query from a non-LSU IP
address , the server prompts the user for an ID.
Many LSU patrons use private Internet providers for their personal
web access. The LSU campus contracted PPP Internet provider
services with IBM. As non-LSU affiliates can also use this service
(e.g. alumni), we could not use IP validation from this contracted
provider. We'd let folks in who are by vendor contract not
eligible to receive some services. The other option: Global ID
opening up services from anywhere on the WWW. The patrons who use
text based access have been using campus email/internet accounts
for years. Now we have something for the graphical folks.
While it's far from ideal, we use a global ID available to any LSU
person with an LSU email account. To automatically distribution
and to exercise security in that distribution, LSU patrons register
to use the Gateway via a simple CGI form. The form only recognizes
LSU email addresses. Once a person registers, the login
instructions are emailed to his/her email account. If you have an
LSU email account, you must be eligible for all these services
available from the Gateway.
I hope it stays fairly self explanatory, making corrections and
additions as experience dictates. If folks have questions, we route
them first to the WWW pages. We don't give out the ID over the
phone. If a person forgets the ID, they simply re-register. It's
of the Web, by the Web, & for the Web.
I receive a copy of the completed registration form in my email
with which I extract the person's email address, creating a
distribution list for service announcements, ID changes, etc. To
keep this list of email address current, we'll purge the list each
Fall & ask folks to re-register. Creating a listserv would have
been preferred but was an option administratively unavailable
(euphemism).
We still have bugs/shortcomings/issues. We have yet to get our
login screens generated by the Library server to match exactly with
our vendor's server login screens. This will require some
development. Also, this ID does not work on vendor sites which
still rely on IP validation for authorization (get with it
Cambridge.).
Folks are welcome to copy the CGI script, etc. Have at it. If you
have any questions please let me know.
Happy webbing,
David
*****************************************************************
RESPONSE #5:
From: "Jerry V. Caswell" <jvc@iastate.edu>
Organization: Parks Library Iowa State University
To: v2038a@vm.temple.edu
Date: Wed, 30 Apr 1997 12:29:38 CST
Subject: Authenticating Local Users
I saw your posting about authenticating local users for access to
electronic resources on the pacs-l newsgroup.
If the resources your users are trying to access are accessed
through CGI interfaces, you can probably have a Unix programmer
develop an authentication step (e.g., kerberos) prior to their
executing the CGI programs. My institution has done this to
enhance access to seventeen locally mounted SilverPlatter databases
and twenty-two remote FirstSearch databases. Before the CGI
interfaces to these databases are executed, the IP number of the
requesting browser is checked. If it is from off-campus, an
authentication script is executed which asks users for their
university ID number. The number is checked against an extract from
our NOTIS patron database and, if valid, allows the search
interface to come up. If not, the user cannot progress further.
While this is not a total solution (most remote publisher's sites,
for example, validate only on IP number), it facilitates access to
core databases.
* Jerry V. Caswell * Email: jvc@iastate.edu
* Assistant Director *
* for Automated Systems *
* Iowa State University Library * Phone: (515) 294-5704
* Ames, IA 50011-2140 * FAX: (515) 294-5525
*****************************************************************
RESPONSE #6:
From: bnielsen@merle.acns.nwu.edu (Brian Nielsen)
Subject: Re: Patron Authentication/Restricted Electronic Resources
A proxy server will take care of this. Northwestern has done this;
take a look at http://www.library.nwu.edu/help/proxy/
Brian Nielsen
Brian Nielsen, Ph.D.
Manager, Learning Technologies
Group
Academic Technologies
Northwestern University
2129 N. Campus Drive
Evanston, IL 60208-2850
phone: 847 491-2170
fax: 847 491-3824
internet:b-nielsen@nwu.edu
http://www.nwu.edu/people/b-nielsen>
*****************************************************************
RESONSE #7:
From: Sue Martin <SKMARTIN@guvax.acc.georgetown.edu>
Subject: Re: Patron Authentication/Restricted Electronic Resources
Georgetown is struggling with the same issue, with a slight
difference. Rather than setting up PPP access into university
resources, the university has contracted with an outside firm to
provide access for faculty and students to the Internet for all
off-campus access. The IP addressing is dynamic, and is not
authenticated.
We have been working with the computing center on a solution. The
current proposal on the table is to establish a proxy server to
allow people to come into the university from off-campus, be
authenticated, and then gain access to the licensed resources.
However, this alternative does not come cheaply, so no decision
has yet been made.
Also, Novell has a Radius server in beta test, which would allow
authentication of information found in Georgetown's NDS tree. It
sounds promising, but we haven't worked through all the issues yet.
Not to mention that it IS still just in beta testing.
We found it difficult to convince the computing center that we were
not able to simply persuade publishers of electronic data bases to
use a mechanism other than IP address to define a user community.
I think they now understand, and I'm looking forward to an early
solution. I also would like to hear what others have done.
Sue Martin
University Librarian
Georgetown University
*****************************************************************
RESPONSE #8:
From: Earl_Balch@UCSDLIBRARY.ucsd.edu
Date: Thu, 8 May 1997 12:30:00 -0700
To: V2038A@VM.TEMPLE.EDU
Subject: Re: Patron Authentication/Restricted Electronic Resources
You may be able to use a proxy server. We were successful in a
test where we could cause Netscape to go through a proxy server on
campus. This fell apart when the ISP began to force its users
through their proxy server.
--Earl
ebalch@ucsd.edu
