Authentication Tokens
SRU 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 manner. 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 SRU 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 SRU 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 SRU mailing list so that some may be drafted.
The URI for the namespace for this extension is info:srw/extension/2/auth-1.0