Authentication Tokens in SRW

Version 1.1, 12th January 2004

Introduction

SRW does not define any method to distinguish among concurrent users, but some business models may impose requirements, for example, to ensure that one user does not modify another's resultsets, to allow a server to restrict a user to a pre-determined number of searches before charges are imposed, or to limit the number of concurrent searches for a user or number within a certain time frame. Or, on the other hand, if it can be demonstrated that a search has led directly to a sale, then the user may receive a commission. Another example is to enable the service to track how different users use the system, possibly to enforce acceptable usage policies.

This document aims to discuss the various methods in which different users may be authenticated in an interoperable way. In a stateless environment, or one where the ability to track individual users is not important, this can be ignored without peril.

There are several technical methods by which distinct users may be identified, from IP address to additional header information to SSL. The different methods create additional requirements and function at various levels of success.

IP Address
Users may be differentiated by the IP address from which they are connecting to the SRW/U server. Unfortunately this is unreliable at best due to the increasing use of web proxy systems -- there may be many users all of which appear to be coming from the same IP address due to a proxy. The advantage is that it is completely transparent to the client and hence the user, so for a small service may be appropriate.

Basic Authentication
Basic Authentication is the fairly simple method used in many web servers to authenticate users against a list or database -- the client is required to send a username and password. This is a very easy-to-configure method to authenticate users, however it does not allow for users that are not authenticated -- every request must have a valid user and password sent or it will be rejected. This model is appropriate for a paid-for service or one which is used only by a set of known individuals, but is less appropriate for a service which may be used by anyone.

Secure Sockets
SSL is an encrypted version of HTTP (https) and hence is more secure than basic authentication alone as the traffic cannot be easily intercepted. For financial transations using SRW/U then this is certainly appropriate as the user is already known in advance and every care for the data must be taken. However for every day services that may be used by anyone, it is a very complex solution.

Additional Message Data


The preferred method for identifying users while still allowing non-authenticated access is by the inclusion of an additional field in the extraRequestData and extraResponseData fields. This method allows the server to chose when authentication is required (for example only if a resultset is needed) and when it can continue to act in a stateless fashion. This may be appropriate for any sort of transaction with the exception of cases when the data should be conveyed in an encrypted fashion, in which case SSL should be used as well.

The recommended name for this field is authenticationToken, and hence x-authenticationToken when it is passed on the URL for SRU. If the server sends back one of these tokens with a response, then the client should return it in the same fashion in any subsequent request to allow the server to know that the requests should be considered to be from the same user.

Further business logic may be required to manipulate these tokens. For example a separate SOAP service may be required to distribute the tokens on request, to delete tokens when they've finished being used or to enable the sharing of such tokens between users to allow shared access to result sets. No best practice guidelines are currently available for such models, but any interested parties are asked to bring up their requirements on the SRW mailing list so that some may be drafted.