I included some general information on the Libraries' authentication issues, extracted from the 1997 Information Technology Plan (p. 55). To that overview, I would add the technical requirement that a central authentication system must support the widest range of platforms and must be able to provide authentication to Internet-based services.
"Authentication: The University Libraries have an increasing number of electronic services that are contractually restricted to sub-sets of the University community. We have a variety of locally-developed authentication schemes that attempt to meet our contractual obligations. In order to expand services to the University population, we foresee a need for a centrally-administered authentication system, which identifies users with a Network ID. Such a system would facilitate our ability to implement: fee-based document delivery; access to individuals' library records; access to fee-based database and current awareness services; distributed printing of electronic text; and others."
Also, last March, as part of authentication discussions, I sent Rick Ellis a number of documents regarding the conceptual operation of authentication (web documents from Yale, MIT and CMC, I think). I can re-send those to you if that seems useful.
The needs and issues we would expect to test against a prototype system include the following areas.
For the most part, these capabilities require authentication of Internet-based services.
We pay commercial information vendors license fees based on negotiated
criteria for "valid users". The criteria vary from vendor
to vendor. When we pass users through Spirit to an external commercial
vendor, those vendors often use the IP to validate users' authenticity.
Clearly IP-based validation is limited and disadvantages UConn
community with non-UConn PPP accounts, since the vendor is looking
for 137.99.xx.xx. Other vendors not only want to ensure that users
are in the UConn domain, but also their specific academic status.
For example, our contract with Lexis/Nexis dictates access for
only teaching faculty and students. As part of our license agreements,
we are obligated to prove to the vendors that we are maintaining
our contractual obligations for usage of their resources.
We require the ability to identify classes of users that are eligible
to use particular services at the point they access specific services/products.
We would expect an authentication system to perform the eligibility
screening. This can be done in a number of ways. The Library currently
employs jury-rigged methods that use a "go-between"
server authentication that passes validation data to the vendors'
servers.
Our preferred authentication method would be that users log into a central server that establishes their eligibility for a variety of Library and University services The server: must be Internet accessible; must have the flexibility to include or exclude users based of flexible criteria and must have a unique identification for each individual user.
We require an authentication system that can both validate eligibility for a service and also manage fees. Examples would include access to and charges for laser printing, copying, scanning (perhaps in conjunction with a SMART card). It is critical that revenues generated from these services are appropriately directed. (Currently we sell our own VendaCards for use in Library machines only).
There are other fee-based services that require user validation/authentication, for example, some of our information database vendors will also provide full-text articles to specific groups of users for a fee. Users must be validated for the service and chargeback capabilities must be present.
Beyond our commercial vendor products and fee-based services, we also provide services that are restricted to specific members of our user population. An example includes access to Electronic Course Reserve. Copyright/fair use practices require that we restrict usage of the information, in some cases to members of a specific class. This is currently handled by a manual password kludge.
We also anticipate user requests to perform library functions without staff mediation (e.g., renew their own books, even from home), place Interlibrary Loan requests, place orders for new library books, review their own user records etc.
We currently distribute Library-client software (e.g. the Lexis/Nexis client, WinSpirs) via FTP download from Library servers. Again, we need a method other than IP address to ensure the authenticity of the requester.
Further, we are developing non-public areas of our Web server(s) that would be restricted to specific classes of University staff (e.g., web-based service request/help desk system ).
Last, the Culpeper Microlab could utilize authentication services as part of the login to facilitate access to other University servers/resources that students want to access in conjunction with their Microlab activities (e.g. applications servers/services; print servers/services; other University servers).
On previous occasions, other University system and server administrators have expressed interest in an authentication system that would provide increased network security: password security; secure e-mail and data security.
Clearly there is also a University interest (as expressed in UCFORUM or UCFAC-L) in an authentication system that works in conjunction with a SMART card (or similar vendor) system.
Many areas of the University seem interested in providing authenticated
user access to grades, course scheduling, degree audits, outstanding
fee information, etc.
Fritzi Batchelor, Head Information Technology Services Homer Babbidge Library, U-5SY 369 Fairfield Road Storrs, CT 06269-1005 Phone: 203-486-5397 Email: hbladm11@uconnvm.uconn.edu Homepage: http://www.ucc.uconn.edu/~hbladm11