The server provides two mechanisms for controlling access to URLs:
- Subnet Security: IP access control is specified by the
read-subnets and write-subnets arguments to http:export-url.
- User Passwords: The rest of this page describes how to set up password
controlled pages.
Both subnet security and password control can be combined.
The authorization domain contains the following elements:
- Realms define a space which is authenticated by means of an
authentication scheme. Authentication schemes refer to the
security or cryptographic techniques used to determine the identity of a
user. All users, groups, and access controls can belong only to single
realm. Because no elements are shared across realms and each realm uses
a single authentication scheme, the level of security for a realm cannot
be compromised by elements using a weaker authentication scheme.
- Users contain personal names and email addresses for users as
well as properties such as user-id and password specific to
authentication schemes.
- Groups aggregate users and groups into named entities that can
be authorized to access specific resources.
- Access Controls aggregate users or groups and specify the
HTTP methods which they are authorized to invoke on a URL. Access
control objects are linked to URLs and govern all accesses to
URLs after a client has passed any IP address restrictions.
The HTTP protocol provides the following authentication schemes:
- Basic Authentication is a very weak scheme that merely
encodes the user-id and password with base 64 encoding. It is useful
only because it is widely deployed in many clients, but the reliance on
base 64 encoding merely keeps honest people honest. One way to use basic
authentication with slightly more confidence is by combining it with
subnets security. See discussion in Hypertext Transfer
Protocol.
- Digest Authentication is a moderately strong scheme that uses a
one-way function (MD5) to encode the username, password, and a transaction
token. Replay attacks are prevented for different URLs and different IP
addresses, assuming network packets are not intercepted in realtime. As long
as password assignment does not involve sending the clear-text password over
an insecure network, this authentication scheme is dramatically better than
basic authentication. See Internet RFC 2069 An Extension to HTTP : Digest
Access Authentication and the draft
revision, which is required extension for HTTP 1.1.
It is important to remember that neither subnet security 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:
- Random Seed: Evaluate the form (http:digest-authentication-random-seed
t) sixteen times by hand. Manual evaluation allows the time variability
of exactly when you execute the form to increase the randomness of the seed.
By ensuring that the random seed starts off with sufficient randomness, this
initialization makes your Digest Authentication passwords most secure.
- Maintenance Password: Give the Webmaster account a
password in the Server realm (Digest Authentication) by evaluating
the form:
(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.
- Password Directory: Secure the password directory (HTTP:PW;) against unauthorized access. For maximum
security (and best performance), the password directory, should reside on the
same machine as the server runs. In the final analysis, your CL-HTTP server
is as secure as this directory, the access to the binaries or images that the
server runs, and obscurity of Common Lisp for mainstream crackers.
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:
- Access-Controlled: Requires URLs to restrict users via either user
authentication or subnet security.
- Authenticated-Users: Requires URLs to restrict users only via user
authentication.
- Authenticated-Users-on-Write-Subnets: Requires URLs to restrict users
via both user authentication and write subnet security.
- Local-Host: Requires users to be on the local host running the server.
- None: No users can invoke side-effecting methods.
- Remote-Host: Requires URLs to control access, but respects any global or
URL level access controls.
- Write-Subnets: Requires URLs to restrict access to hosts trusted for write operations.