Endeavor – Yale Partnership: Network Security Program Interface

Phase 1: Patron Web Service Authentication Requirements



The Orbis 2 system will be providing worldwide web access to patron information considered sensitive by the library and its patrons. The system will also provide web access to patron initiated activities, previously requiring staff intervention. The services must be provided in such a way as to assure patrons of their privacy, and assure the library that only legitimate patrons are being served.

A limited working system for access to patron information, based on the NOTIS Patron Empowerment product is currently in use by the library, and presently provides an acceptable level of privacy and authentication. The new system must meet or exceed the expectations set by the current system. Specifically:

  1. Transmission of sensitive information is protected via SSL encryption.
  2. Authentication does not require a unique form of identification for each service used.
  3. The library does not need to maintain a unique database of authenticated patrons.
  4. Authentication is only required once per session.
  5. Authentication can be performed at public terminals, which do not allow cookies, and/or at off campus sites, where application specific software cannot be installed or verified.

Finally, it is essential that the Orbis 2 authentication system make use of, and interoperate with the infrastructure of authentication services maintained by the university, which extends the features mentioned above to multiple secure computer services in a common way.



The library authentication system must work with the standard form of identification supported by the university, if provided. This form is designated the "netid". Where the standard form of identification is not available (as with temporary patrons), a single additional form of identification, administered by the library must be supported.



The model used by the current library authentication system, and extended by the university authentication infrastructure is the "trusted third party" with secure access to university supplied authentication information.


Common Infrastructure:

The university maintains a central database, which contains identification information about university students, faculty, and staff, and a trusted service, designated the "Central Authentication Service," (CAS: http://www.yale.edu/tp/auth/ ) which provides secure access to that information.



In order to made use of the CAS, a potential user or service must have web access, and support the https protocol. Information is passed between the user’s browser, the web service, and the CAS server in the "POST" form of https requests..

  1. A user may optionally pre-authenticate a particular browser/IP address, by contacting the CAS via https, responding to a netid – password challenge, and receiving back a (memory cache) cookie (encoded for the unique netid and IP address), that can be used to bypass future challenges for a limited period of time. The CAS uses the university provided Kerberos service to authenticate the netid.
  2. A service requiring authentication (specifically Orbis 2 patron services), first redirects an initial http service request ("login") to the CAS, adding a parameter representing its own service address.. The user’s browser will "POST" this request to the CAS, and transmit the previously encoded cookie if present.
  3. The CAS, on receiving the redirected request, will either retrieve its copy of the encoded cookie to verify that a previous challenge has been met , or will challenge the user to provide a netid and password ( a cookie is encoded and stored at this time). The CAS then redirects the browser a second time to the url provided by the service, adding as "POST" data, a one-time key representing the authentication of THIS user for THIS service, which it also stores locally.
  4. The service receives the packet containing the authenticated key from the browser, and retransmits the key (via https)(note: this secure socket session will be used over and over, and should not be started and stopped for every request) to the CAS, which compares it to the local copy, which it saved at step (1) or (3) above. At this point the CAS returns the validated netid (extracted from the key itself) to the service as a response (or "no" if the key is not valid, or has expired).
  5. Once the netid has been validated, the service may now use the id as an index to whatever information the user is seeking to retrieve or set, and the one time key (or combination of university id and browser IP address which it represents) as a token representing authenticated access for the remainder of the session. In particular, it could compare the netid, with the netid stored in the patron record as an "institutional identifier". However, netids are not consistently represented in the present library patron files. For initial implementation, an external database must be consulted (Yale will provide specifications for access control and syntax of the data)(see also extendability).

The library system must also support direct entry of library patron identification without use of the CAS. This is necessary for patrons, such as visiting scholars, who do not have an institutional identifier. The library will generate, and supply to those patrons, barcode numbers that do not, in themselves represent sensitive information. Patrons with such library generated identification will use the standard Voyager sign in process, which will, however, be encrypted to prevent snooping.



It is likely that as other institutions develop their own authentication schemes, and as various public authentication services come into existence, it will be possible or necessary to include them in the preceding process. Therefore, although a single authentication service is described, the implementation should make it possible for each patron, or patron class to be authenticated by a different service. This will also entail the ability to initiate secure sessions with more than one authenticator.


Production Notes:

Relative to the existing Voyager interface for web security, it is possible to list some changes that will be required to implement the preceding process:

  1. An initial authentication screen must be built to precede and redirect the existing login screen (which becomes the "service" referred to above).
  2. The login screen must not accept entries that to not include validation tickets. (this could be combined with (1) by generating the redirect if no ticket is present)
  3. The validation process will require the correlation of server responses with patron session requests. This may require either temporary work files, or additional state information passed as shttp parameters. As noted the server session should most likely be a persistent session itself.
  4. Additions will be needed in the System administration client to configure and modify the parameters supplied by Yale.

Return to Orbis2 Implementation Site