Access Authorization Methods
Gale Group Online Product Distribution

Gale uses three protocols to authenticate access to InfoTrac/SearchBank databases: source IP authentication, dialup authentication (passwords and cookies), and remote patron authentication. Source IP and dialup authentication are intended for use inside the library; remote patron authentication is intended for use by patrons outside the library. With a few variations, these methods are also used by other vendors offering similar modes of access to online databases, and are discussed later in this outline.

In contrast, corporate division products (Insite and ComputerSelect Web) utilize basic authentication only; IP authentication capabilities are limited and require client side implementation.

Source IP authentication

This is the most common form of authentication used by libraries to access IAC databases (and was the only method used by IAC when SearchBank was first released). It is available to institutions that have been assigned one or more blocks of unique IP addresses by their internet service provider (ISP). To use source IP authentication, the institution must have exclusive use of the address space assigned to them; an address or addresses cannot be shared with other non-subscribing institutions or user communities.

Once these numbers have been obtained by IAC, they are recorded in an account administration database used by the SearchBank servers to profile online access privileges (also referred to as 'RLIS'). The database servers 'see' the source IP address of the user's web browser, Windows95 client, or character based client, matches it with the numbers recorded in the institution's RLIS record, and permits direct access to the database search engine. In this way, users enjoy pseudoanonymous access to licensed content without having to present credentials to the service provider (IAC).

Dialup authentication

Many customers, especially in the K-12 and small public library markets, cannot afford the expense of being directly connected to the internet, and rely instead on dialup access (via modems and telephone lines) to their internet service provider. Under these circumstances, a site is assigned an address on an as-needed basis from a pool of shared IP numbers. These IP addresses are assigned when the user's system first dials in to their internet service provider and are, in most cases, shared among subscribing and non-subscribing institutions. IP authentication would require capturing the entire range of numbers in the IP pool and, without further validation methods, would allow access to unauthorized users.

Dialup authentication, like source IP authentication, is intended to allow the library users access to licensed content without having to present credentials, and is currently available only to user accessing IAC via the web, and works this way: when a browser first connects to the SearchBank URL on the IAC server, the server first attempts to do source IP authentication. When this fails, (presumably because no IP addresses have been recorded for the site), the server checks for a dialup authentication profile. If a profile exists, the server asks the browser client for an IAC authentication cookie. If a user is connecting to SearchBank for the first time, the cookie, naturally, is not available. The server will then prompt the user for a password (logged in the dialup profile) which, if submitted correctly, authorized the server to send a cookie to the browser. This cookie will then be used to authenticate subsequent sessions.

A couple things to note about IAC authentication cookies. First, authentication cookies have a limited lifetime; a cookie is usually set to expire 35 days after it is acquired by the browser. This lifetime is variable and can be adjusted in the dialup profile by IAC installers. For example, a cookie's lifetime may be set to last for the duration of the institution's subscription period, or until the end of a school year. A shorter lifetime is preferred in case the password used to acquire the cookie is compromised by an unauthorized user. If necessary, the password used to acquire the cookie can be changed. Therefore, the lifetime of the cookie determines the length of time the unauthorized user will have access before the cookie must be re-acquired using a modified password.

Second, cookie authenticators are often used even though sites may have a direct connection to the internet, and a stable IP address space has been assigned to the site. However, browsers at some institutions, such as schools and city libraries, may have their IP addresses hidden behind a firewall or proxy device that uses its own IP address to mask all traffic traversing the node; all of the hosts behind the node appear to have the same IP address. This has the undesirable effect of secluding browsers belonging to non-subscribing users or institutions, as well as paying customers. Under these conditions, cookies can and should be used instead of source IP authentication.

In both cases, cookie authenticators let the site administrator determine which browser(s) should have access to IAC databases by setting cookies on just those machines; administrators are implored to initialize each browser by connecting to the SearchBank servers, submitting the password and acquiring the cookie, so that end-users are not confronted with the password prompt.

Credentials and Credential-Proxy Hybrids

IAC's Library and Corporate divisions have created two different authorization methods based on user credentials. The Library's method (dubbed RPAS) uses a single credential and relies on the institution to authenticate the credential against a local database. The corporate division's method uses basic authentication (username / password) and maintains these credentials on application server's account administration database. A critical difference between the two is the scope of their application; RPAS has traditionally been reserved for use by library patrons who are outside the library, i.e., they cannot expect to use source IP authentication because they are using an anonymous dialup connection to an unknown ISP (e.g., AOL, Netcomm, Delphi). The user is expected to provide a credential that demonstrates s/he is a card holding member of the library whose licensed content the user is attempting to access.

The corporate division's basic authentication requires the user to submit a username and password each time a session is started. No other form of authorization is currently available for corporate products; the LRTI (Login Request Ticket Issuer) protocol can be used to automate the login process, bypassing the user authentication dialog, but this scheme still uses credentials formed from a username and password and merely hides this information from the user during login.

RPAS (Remote Patron Access Service)

RPAS is quite different from basic authentication methods. Basic authentication prompts the user for a username and password. In most cases, these credentials are stored and maintained by the online service provider requesting the authentication. RPAS, on the other hand, will only prompt the user for a single credential, typically a patron or student ID, or password. Normally, RPAS credentials are stored on the client's web server, and requests for authentication are forwarded by the InfoTrac servers to client's server (see the RPAS Protocol Specification).

This method has several advantages for both the vendor (TGG) and the customer:

• The credentials database is stored and maintained locally, usually as part of the library's OPAC patron file
• Eligibility can be determined using any number of patron attributes stored in the patron database, e.g., access could be denied if the patron has overdue books or owes fines
• The library maintains complete control and updates can occur in real time, as patrons are added or removed from the patron file
• The library's patron file is secured on the library's own servers; updates do not have to be transmitted to, or maintained on a foreign (such as the vendor's) server, enhancing security and currency

Some libraries are unable, however, to implement the protocol in it's classic form. The two most common reasons being:

In addition, the customer's expectations may have formed a separate set of requirements for a remote access solution. This is usually the case when other online services have already been deployed at the site, or if competitive evaluation reveals to the customer a simpler or lower cost method.

Authorizing pre-authenticated access to InfoTrac

An increasing number of library are implementing their own authentication methods. These methods fence off links to licensed content and perform authentication locally before allowing users access to these links. These conditions require that the customer and vendor negotiate a protocol whereby the local system presents the remote user to the vendor's application and supplies to the vendor one or more credentials indicating that the user is authorized to access the service. Although TGG's authentication suite has not been tailored to meet this requirement, RPAS can be used in conjuction with local authentication so that users are not confronted with a second authentication request by TGG servers.

Background

When a user connects their browser to the InfoTrac servers, and IP authentication has failed, they are presented with a simple HTML form which, when submitted with the patron's ID or other credential, takes the form of a simple HTTP GET request. E.g.,

The same effect would be achieved if the user simply typed the entire sequence into the Location/Address box of their browser, or if a web administrator created a static HTML link from the library's web page. E.g.,

The InfoTrac web servers will treat this request as though an RPA authentication form had been submitted and, using the information in the location's RPP record, forward the credential (e.g., foobar) to an RPA script.

Methods

The same request can be made using