4BA2 Web Project - WWW Access Control Mechanisms - Examples of Access Control


We are going to see 3 main examples of access control. Those 3 examples are the following :

CERN server access protection

The CERN server access protection mechanism is controlled by a number of files, included the server configuration files. User and group name files are defined in password and group files (respectively). Those names are used in ACL ( Access Control List) files and protection set-up to restrict access to certains documents.

Protection set-up

Protection set-up defines a sets of files that are protected in a common way. The Protect and DefProt configuration directives are used to set up associations between protection set-up and set of files to be protected.

The DefProt directive associate a default protection set-up with a file template, but does not activate protection. The protection is acivate by the Protect directive. The syntax for those 2 instructions is :

DefProt template setup [user.group]
Protect template [setup [user.group]]

The User and group parameters specify the UNIX user and group ID with which the server process should run. This allows the UNIX file protection mechanism to be used to restrict access. If the parameters user and group are omitted, the default is nobody and nogroup.

Server password files

Server password files defines set of users and contains the encrypted password associated with each user. Different protection set-up may use different password files, specifying a ServerID identifier to differentiate the different kinds of protection on the same server (realms). Duplicated user names contained in different password files need not necessarly be related to one an other.

The CERN server password files are maintained with the htadm program, which is part of the server distribution. This program is used to perform operations such as creating a new password file, add a new user, change user password ... Here is a few example of htadm syntax.

htadm -create password-file
htadm -adduser password-file [username [password [realname]]]

server group files

Server group files categorize individual users into groups. The groups may then be used in ACLs and protection set-up.

A group definition consist of a group name, followed by a colon and a list of users, separated by commas that make up a group. The syntax is as follows :

group-name: { user-name | group-name} [, ...]

User name within the list may be qualified with a host-name or Internet address specification, preceded by the @ sign.

If the user is omitted and just an address specified, this is interpreded as meaning all user of this address. Both the user and host specifiers can consist of lists separated by commas within parentheses. For exemple :

marketing: (rosemary,penelope)@192.168.0.* sales : chris@(192.0.2,, marketing, @

Access Control List Files

ACL files specify access restrictions for the directory in which they are located. The files must be named .www_acl and consist of a set of rules, one per line. Each rule specifies the restriction on files matching a template. The syntax of a rule is :

template : method-list : user-list

The template specifies files to be matched by the rule. It only consider the files in the current directory. The method-list defines the HTTP methods that are allowed for the rule. The user-list is a list of user or groups which are allowed to access the files identified.

When an access control file is consulted to check the restriction on a file, all rules are tested for a possible matching with the filename. Access is permitted if any rule matches.

Files in a directory that is protected by an ACL file, but not mentioned in the ACL rules, are considered to be inaccessible for everybody and won't therefor be served.

NCSA server access protection

The NCSA server access protection are in result similar to the CERN server protection, but the detail of the configuration is different.

Access Configuration Files (ACF)

Those files are used to to restrict access to directories. You can have one global ACF and each directory can have it's own ACF that overwrites some of the option of the global ACF.

Directories ACF are quite similar to the CERN server's ACL but can also define additionnal type and encodding mappings, and set configuration option for the directory, overwriting the other ACF. This facility can be restricted on a per-directory basis in the global ACF. Obviously, access to ACF must be restricted to prevent users from changing those files.

Directives in the global ACF must be enclosed within a Directory sectioning directive, to indicate the directory path to which they pertain. This is only allowed in the global ACF and is formatted like an HTML container element with a start and end tag, for example :

Directory /www/project/docs
AuthName project-docs
AuthUserFile /usr/local/etx/NCSA/conf/project-passwd
AuthGroupFile /usr/local/etx/NCSA/conf/project-group
AllowOverride None
Option None

Configuring directory options

The feature within individual directories may be controlled with the Option directive, but only to the extend what is explicitly permitted by the AllowOverride directive in the global ACF.

Authorization configuration

The following authorization configuration directive are allowed in the global ACF. If use of the AuthConfig feature is permitted by AllowOverride directive in the global ACF, these directive are also allowed within directories ACFs.

The AuthUserFile specifie the absolute path of the user password file to be used for authentication. The AuthUsergroup specifie the absolute path of the group file used to define groups of users for authentification. The Authname directives specifies an authorization realm idendification (equivalent to the ServerID on the CERN server), which is used to distinguish between sets of files on the same server using different password files. The AuthType directives specifies the HTTP authorization scheme used.

Limiting Directive

The Limit directive is a sectioning directive used to specify limits on access in the directory. It is legal in the global and directory ACF (if allowed be the AllowOverride directive), and iapplies to the HTTP methods listed in the directive.

GN server access protection

Most WEB server will serve all documents in directories within the WEB directory hierarchy, possibly limiting access to some documents according to an access configuration mechaninism (CERN or NCSA server). By contrast, the GN server will only serve documents that are explicitly specified in a .cache file in the same directory as the document.

We can specifie the user or group ID by using -k or -K command line. If we use that option, all .cache file must be owned by a user or a group. This user or group ID must be different from the server process group or user id. This is useful if all cache files are normally created by a single user or group, and precludes the inadvertent use of spoof cache files. When a request is made to the server, it checks the ownership of the cache file that control the information being requested.

To enhance security the GN server should run with a user ID that has a few permissions as possible. The server should have sufficient permission to write to its log file and read the files it is to serve, but preferably be enable to write any other files.

Host access control files

GN permits access control on the basis of host-name or Internet adress, if it is started with the -a or -A option. The list of hosts allowed or denied is taken from a .access file.

Each line in the access file consists of a host-name pattern. If the line starts with an exclamation mark then the hosts machining the pattern are denied access to the files, otherwise they are permitted access. The pattern * matches all hosts and if used in a deny rule will deny access to all hosts. For example :


Return to the introduction