Zeus Server provides a high-performance API to allow third parties to completely customise the access control performed by the server. The API allows the server to delegate its access control policies for portions of its document tree to a separate authentication server. The interface utilises the TCP/IP socket abstraction, allowing the authentication server to be running on a physically different machine from the server, and multiple Zeus Servers to share a centralised authentication server. It also allows the authentication server implementation to be in any programming language which can interact with sockets.
Sites running online subscription magazines for example have very complicated access control policies, requiring external database lookups on every request. On receiving a request, Zeus Server can be configured to connect to an authentication server to check whether the request should be satisfied or requires a password etc. The authentication server can do whatever is required to validate the client, for example perform some SQL query into a central database on a mainframe where all of the subscription records are kept. Such as design allows for complete flexibility.
Setting up Zeus Server to perform access control via its authentication API is split into two stages.
Firstly, an authentication server needs to be running. The authentication server is the third-party program which handles the authentication checking on behalf of the server by communicating with the server via this API.
Secondly, Zeus Server needs to be configured to delegate access control for the necessary portions of the document tree to the authentication server. This second stage involves using the administration server to edit the server configuration. The required page can be found on the database configuration section, called “socket authorisation”. Here you supply details of the authentication server to use ( the machine and port number which it is running on ), the portion of the document tree which is to be protected in this way, e.g. entering /secure would specify that the server contact this authentication server for all requests beginning with /secure, and the realm. The realm is the textual message which is displayed in the dialogue box when a userid / password is required from the user, so that the user has some idea of what he / she is authenticating themselves for, e.g. “NetX Online Subscription Magazine”.
A sample authentication server is supplied with the server distribution, in the scripts directory called “authd”. This is a simple authentication server written in Perl, and demonstrates how to interact with the authentication API. It receives requests from Zeus Server for authentication information, and checks the user details supplied in a separate text-file containing its authentication database. For more details see the information in that file.
The authentication server receives requests from Zeus Server by means of a TCP/IP interface. The server should bind to a specific port and listen for incoming requests from the server. An authentication request contains information about the client which is requesting access to a controlled portion of the document tree. The authentication server can use this information to determine whether the user should be allowed access, whether a password is required, or an invalid password was supplied.
The format of a request is similar in structure to a HTTP request, with a text basis consisting of tuples separated by a `\r\n' line terminator and a final `\r\n' request terminator. The request / response structure is shown as follows:
Input:
Hostname: (DNS name|IP address)\r\n
URL: url-requested\r\n
Method: (GET|POST...)\r\n
Password: (NULL|userid:password)\r\n
Cookie: (NULL|cookie)\r\n
\r\n
| Hostname | Contains the hostname of the client, as either a domain name, or a textual representation of their IP address, e.g. “10.0.0.5”. |
| URL | Contains the URL which the client has requested. |
| Method | Contains the method with which the client is trying to access the URL. |
| Password | If the user has supplied authentication details, then this field contains the userid and password of the client separated with a `:', otherwise contains “NULL” |
| Cookie | If the client provides a cookie for this URL, then the cookie information is available in this field, else contains “NULL”. |
Output:
(NO|YES|PASSWORD)\r\n
| NO | Access is forbidden. The server will display an page to the client explaining the forbidden access. |
| YES | Access is granted, the server will send the page to the user as if nothing special had happened. |
| PASSWORD | Either the user did not supply a password and a password is required, or the user supplied the wrong password. In either case the server will respond with a HTTP return code to cause the browser to open a dialogue box on the client's machine to allow them to (re)enter their authentication details. |