Contents:
The server provides two mechanisms for controlling access to URLs:
The authorization domain contains the following elements:
The HTTP protocol provides the following authentication schemes:
It is important to remember that neither secure subnets nor password schemes are able to keep a determined and sophisticated snoop from monitoring network traffic and gaining access to access controlled information. The only way to prevent such access is by using suitable cryptographic techniques.
Nevertheless, the digest authentication scheme is pretty good, provided the user password never travels over the network when first assigned or whenever changed. There is a small window of vulnerability to replay attack that depends on the time window during which a nonce remains valid. If this window is short, or digest authentication is combined with subnet security, reasonable access control can be assured. (See http:*digest-authentication-nonce-life-time*)
Given these considerations, several pages explain how to use the access control facilities in CL-HTTP.
When you first set up a server, you need to perform the following one-time initializations:
(http:save-authentication-object
(http:intern-user :server "Webmaster"
:personal-name "Common Lisp Wizard"
:password "xxxxxxx"
:email-address "user-id@my-host.domain"))
This account allows you to perform server maintenance over the Web, for example, modifying user accounts. But, remember never to set this password over the network because the new password would travel in clear text that could potentially be intercepted. When editing user accounts, you are best advised to combine subnet security with password protection and to not set passwords from beyond the local network. For maximum security, set passwords for Digest authenticated realms only from the server console. This does not matter for basic passwords because they use no cryptographic techniques and therefore provide no security against unauthorized access.
After the user of an access controlled URL has been authenticated, the server instance (bound to http:*server*) contains the user object and the authentication method. These can be accessed with:
Most major methods on user objects are defined on server objects. Additionally, Common Log File entries for CL-HTTP record all authenticated users by qualified name (e.g., "realm|user-name"). In the usage of user properties and logging, service providers should strictly respect people's privacy.
The examples use clear text passwords in lisp files for pedagogical purposes only. For best security, all production sites should use the following functions to save and restore password data:
If you use these functions to save password data, only an MD5 digest of the passwords is saved with associated user objects. Nevertheless, access to the file containing the authentication data compromises security. It is therefore important to ensure the security of your authentication data.
The following operations are available on authenticated users and other authorization object:
HTTP methods such as PUT and DELETE change the state of your web server. A webmaster may wish to impose a security policy that provides an appropriate level of authentication for users to PUT or DELETE URLs. Each security policy imposes minimum the requirements to invoke these methods. The security policy can be selected via the server configuration interface or by setting the variable http:*accept-write-methods*.
The following security policies are available: