Controlling access to your server

ou can restrict access to your entire server or any part of it. You can specify that only certain people can see certain files, or that everyone except certain hosts can see certain files. Note that this access restriction applies only to files and directories that your server can send to a client. It does not have anything to do with allowing people to administer your server.

For example, suppose you keep confidential employee records on your server, and you want to allow only the Personnel department to see them. You could keep all these records in a directory called records and specify that only a group of people you call Personnel can see the files in that directory. When users try to access a restricted document, they are prompted for a name and password. If they enter a name and password that correspond to a name-password pair in your private list of people in Personnel, they are allowed to see the requested document. Otherwise, they are told they didn't enter a valid name or password.

If your server has SSL enabled, the user's name and password are sent encrypted. Otherwise, names and passwords are sent openly, and can be intercepted.

When changing access control on files or directories on your server, you usually follow this process:

  1. Create a user database if needed.
  2. Enter one or more users into the appropriate user database (discussed on page 74).
  3. Choose the files or directories whose accessibility you want to change (discussed on page 81).
  4. Specify the default access (everyone allowed or everyone denied) for that resource (discussed on page 81).
  5. Specify which users are exceptions to the default access (discussed on page 81).

Creating and removing databases

The users and groups that you specify when setting access control are all stored in one or more databases. A database is a list of users and groups.

Netscape servers use a high-speed database format called Berkeley 4.4 DB format. This format can search a large database with one file system read (normal files search the database linearly).

Important
Although Netscape servers support multiple databases, you might need only one database for all your users. The main reason for maintaining multiple databases is if you have different servers installed on the same computer. A mail server might have a completely different database than a news server or a web server.

If you're only maintaining one server on your computer, however, you'll find it's easier to keep track of your users if they're all in the same database. If you need to separate your users, use the grouping features described on page 76. (Netscape servers support multiple databases because older server programs did not have grouping capabilities.)

The server stores its databases in authdb in the root server directory. When specifying a database, use only its name, not its directory path.

Using the Manage User Databases form, you can perform the following tasks with databases:

Creating a database

To create a user database for your server:

  1. In the Server Manager, choose Access Control|Manage User Databases. The Manage User Databases form appears.
  2. Click the New Database radio button.
  3. In the New Database field, type a name for the database. Don't type a path because all databases are stored in the authdb directory, in your server root directory. The database name can be up to 256 characters.
  4. Click the Create New Database button, and confirm your changes.

Removing a database

To remove a user database:

  1. In the Server Manager choose Access Control|Manage User Databases. The Manage User Databases form appears.
  2. Click the This Database radio button.
  3. Choose the database from the drop-down list to the right.
  4. Click the Remove Database button, and confirm your changes.

Creating, removing, and editing users

There are two types of users that you deal with in access control: users specifically entered into a database you maintain, and users from specified domains or IP addresses. This section deals with the first kind--users in a database you maintain. For more information on controlling access based on domain or IP address, see "Denying access to a resource" on page 82 and "Allowing access to a resource" on page 83.

You can have any number of users in your database, and you can put them into as many groups as you like. For example, you might want to separate your users into a Personnel group and a Sales group. You can put a user into more than one group.

You can also maintain multiple databases, but it's much easier to keep track of your users if they're in one database. (Multiple databases are remnants of older server programs that did not have grouping capabilities.)

You can create users, remove them, or change their passwords. You can also list all the users in your database.

Creating a user

To import users from an existing database, see "Importing users" on page 79. To add a user manually:

  1. In the Server Manager, choose Access Control|Create User. The Create User form appears.
  2. If needed, choose the database you want to add the user to.
  3. In the Login Name field, type the login name the user will use. This is the name the user will type when prompted for a name by the server. It can be up to 254 characters.
  4. In the Full Name field, type the user's full name. The user never sees this. It is to help you keep track of your users.
  5. In the Password field, type a password for the user. It can be up to 8 characters. Type it again in the next text field to ensure accuracy. The user will type this password when prompted by the server.
  6. Choose which group to place the user into. If you don't want the user in a group, choose None. When you create a user, you can only place them in one group. To add the user to another group, see "Editing a group" on page 78.
  7. Click the OK button. Confirm your changes, and the information is added to the selected database.

Removing a user

To remove users from a database:

  1. In the Server Manager, choose Access Control|Remove User. The Remove User form appears. Or choose List Users, and choose the Remove User link for the user you want to remove. (For more detailed information about the List Users form, see page 76.)
  2. In the Login Name field, type the login name of the user you want to delete.
  3. Choose the database that contains the user that you want to remove.
  4. Click the OK button. Confirm your changes.

Editing a user

To change any of a user's information:

  1. In the Server Manager, choose Access Control|Edit User. The Edit User form appears. Or choose List Users, and choose the Edit User link for the user you want to edit. (For more detailed information about the List Users form, see page 76.)
  2. In the Edit User field, type the login name of the user you want to edit.
  3. Click the Get User Data button. The information about that user appears in the appropriate fields of the form.
  4. Change any of the information in the fields. If you want to change the password, make sure to type the new one in twice. Remember that the password can be up to 8 characters long.
  5. Click the OK button. Confirm your changes.

Listing users

When you want to remove or edit a user, it's often easier to select that user from a list than to type in their exact login name. To see a list of users in a database:

  1. In the Server Manager, choose Access Control|List Users. The List Users form appears.
  2. Choose the database containing the users you want to list.
  3. In the Filter field, type any wildcard pattern you want to use as a filter for usernames in the database. For example, if you only want to list users whose login names begin with D, type d* into the Filter field. For more information on wildcard patterns, refer to "Understanding wildcard patterns" on page 42.

  4. Click the Show Users button. The user list appears in the form. To the right of each login name are two links: Edit User and Remove User.

Creating, removing, and editing groups

A group is a collection of users. Using groups saves time when you set access control for parts of your server. Since you can specify that a named group is allowed or denied access, you don't have to go through the tedious process of adding each individual user to an access control list (see page 83). For example, say you have several directories on your server that you want the Sales department to see, but not the Marketing department. You create a group for each department and specify that only the group Sales has access to the directories. Now, if someone moves from Marketing to Sales, you only have to take them out of one group and put them into the other. You don't have to change any of the access control specifications.

To save even more time, you can also put other groups into a group. For example, your Sales and Marketing groups could both be part of the group Business. A group may belong to multiple other groups.

The members of a group must all be within the same database. It's recommended that you use only one database for all your users, since your users are easier to keep track of that way, and you can more fully exploit the power of grouping. Also, user databases are shared across all servers that are installed (web servers, mail servers, news servers, and so on), so you may want to have a different database for each server to avoid confusion.

If you need to separate your users, use the grouping features. Netscape servers support multiple databases because older server programs did not have grouping capabilities.

You can create or remove groups, or edit their contents. You can also list the contents of groups.

Creating a group

To create a group:

  1. In the Server Manager, choose Access Control|Create Group. The Create Group form appears.
  2. Choose the database that you want the group to be a part of.
  3. In the New Group field, type the name of the new group.
  4. If you want this new group to be a part of another group, choose that other group from the list of groups. Otherwise, choose None.
  5. Click OK. Confirm your changes.
Once you have created a group, you can add a user to it by editing that user. (See page 75.)

Removing a group

Removing a group does not remove the individual users in the group from the database. To remove a group from a database:

  1. In the Server Manager, choose Access Control|Remove Group. The Remove Group form appears. Or choose List Groups, and choose the Remove Group link for the group you want to remove. (For more detailed information about the List Groups form, see page 79.)
  2. In the Group field, type the name of the group you want to remove.
  3. Choose the database that contains the group you want to remove.
  4. Click the OK button. Confirm your changes.

Editing a group

To change a group's members:

  1. In the Server Manager, choose Access Control|Edit Group. The Edit Group form appears. Or choose List Groups, and choose the Edit Group link for the group you want to edit. (For more detailed information about the List Groups form, see page 79.)
  2. From the Group drop-down list, choose the group you want to edit.
  3. Click the Get Group Data button. The information about that group appears in the appropriate fields of the form.
  4. You can change what other groups are part of this group and what users are part of this group. To change any of the information in the lists, reselect different names.
    Note
    The groups and users are not selected unless they are highlighted.

  5. Click the OK button. Save and apply your changes.

Listing groups

When you want to remove or edit a group, it's often easier to select that group from a list than to type in its exact name. To see a list of groups in a database:

  1. In the Server Manager, choose Access Control|List Group. The List Groups form appears.
  2. Choose the database you want to list the groups of.
  3. In the Filter field, type any wildcard pattern you want to use as a filter for usernames in the database. For example, if you only want to list groups whose names begin with S, type s* into the Filter field. For more information on wildcard patterns, see "Understanding wildcard patterns" on page 42.

  4. Click the List Groups button. The group list appears in the form. To the right of each login name are two links: Edit Group and Remove Group.

Importing users

Instead of entering users manually one at a time, you can import users from an existing database into your server's user database. Your existing database must be in one of two formats: text or NCSA-style. The difference between the two styles is that the passwords in the NCSA-style database are encrypted. No matter which file type, the format of the file should be something like this:

user1:password1
user2:password2
user3:password3
To import users from an existing file:

  1. From the Import Into Database drop-down list, choose the database you want to import the new users into.
  2. In the Import From Text File field, type the path and name of the file you're importing from. This file can reside locally, or on any network drive your computer can access.
  3. Your server automatically stores users' passwords in encrypted form. If you are importing from a database whose users' passwords are already encrypted (NCSA-style database), you don't need your server to do this for you, and you should click the No button under the Encrypt the Passwords heading. If the users' passwords aren't already encrypted (for example, text format database), click Yes to encrypt them during the transfer.
  4. If the database you're importing from includes users' full names, you can import this information also by clicking the Yes button under the Extract Full User Names heading. When importing full users' names, use the following format: user1:password1:x:x:Full User Name 1

    If you have user or group identification numbers, you can use those instead of x:x.

    If you are directly importing Unix password files, x:x would be replaced with the numeric user and group IDs.

  5. Sometimes a user in the destination database has the same login name as a user in the file you're importing from. If you want to replace such users in the destination database, click the Yes button under the Overwrite Existing Users heading. If you don't want to import users with duplicate names, click No.

Restricting access

After you have created the users you want to use in access control (see "Creating, removing, and editing users" on page 74), you use the Restrict Access form to restrict users' access to specified files. For example, say you have created two groups: Sales and Marketing. You want the Sales group to be able to see and change all the files in a directory called contacts. You don't want Marketing (or anyone else) to see the files. Using your server's access control, you specify that by default, the contacts directory is not available for any kind of access to anyone. Then you specify that the Sales group is an exception to the default access. You further specify that not only can they read the files in that directory, but they can also change them.

To change the access control for part of your server:

  1. Choose Access Control|Restrict Access. The Restrict Access form appears.
  2. Using the Resource Picker, specify the part of the server to change access control for.
  3. Turn access control on or off for the specified files by clicking the button named either Turn off access control or Turn on access control.
  4. For each type of access--read and write, set the default accessibility--Allow or Deny. Read access allows a user only to view the file. Write access allows the user to change or delete the file, assuming they also have access to the file through your server computer's operating system. (Technically, read access includes these HTTP methods: GET, HEAD, POST, INDEX. Write access includes these: PUT, DELETE, MKDIR, RMDIR, MOVE.)

    When you set these access defaults, they will apply to everyone attempting to read or write to the files or directories you specified earlier.

  5. Specify which users are the exceptions to the default accessibility for each access type by clicking the appropriate Permissions button. If the default access is Allow, the Deny Access to a Resource form appears (see page 82). If the default access is Deny, the Allow Access to a Resource form appears (see page 83). After using either of these forms, the Server Manager returns you to the Restrict Access form in the state you left it.
  6. Choose the response a client will see when access is denied. Under the Access Denied Response heading, click the Respond "Not Found" button to send a message to the client saying the requested file was not found. Alternatively, you can click the Respond with this text file button, and specify absolute path and filename of a text or HTML file to send instead. Whether you specify a file or not, the server also sends the HTTP error code 404 Not Found.
  7. Click OK, and confirm your changes.

Denying access to a resource

In the Restrict Access form described on page 80, you set the default read and write access of a resource (a directory or group of files). If you set read or write access to allow all access by default, you can specify exceptions by clicking the Permissions button. The Deny Access to a Resource form appears.

When determining the exceptions who are denied access, you can specify users from specified hostnames or IP addresses.

First you must specify how hostnames are processed. If you want to deny users from only the exact hostnames you'll specify below, click Include specified names only. However, if you also want to deny users from alias domains of your specified hostnames, click Include aliases of specified names.

To deny users from specific hostnames or IP addresses, type a comma-separated list of hostnames or IP addresses in the text fields. Restricting by hostname is more flexible than by IP address--if a user's IP address changes, you won't have to update this list. Restricting by IP address, however, is more reliable--if a DNS lookup fails for a connected client, hostname restriction cannot be used.

The hostname and IP addresses should be specified with a wildcard pattern, and/or a comma-separated list. The wildcard notations you can use are specialized; you can only use the *. Also, for the IP address, the * must replace an entire byte in the address. That is, 198.95.251.* is acceptable, but 198.95.251.3* is not. When the * appears in an IP address, it must be the right-most character. For example, 198.* is acceptable, but 198.*.251.30 is not.

For hostnames, the * must also replace an entire component of the name. That is, *.netscape.com is acceptable, but *sers.netscape.com is not. When the * appears in a hostname, it must be the left-most character. For example, *.netscape.com is acceptable, but users.*.com is not.

Allowing access to a resource

In the Restrict Access form described on page 80, you set the default read and write access of a resource (a directory or group of files). If you set read or write access to deny all access by default, you can specify exceptions by clicking the Permissions button. The Allow Access to a Resource form appears.

When determining the exceptions who are allowed access, you can specify two types of users:

You specify both types of users in this form.

If all types of user authentication are used, the server checks the user's information in the following order (if the criteria in step 1 or 2 are met, the client skips the other steps and is allowed access):

  1. Is the client's IP address automatically allowed?
  2. Is the client's hostname automatically allowed?
  3. Is the client identified (through password or valid certificate) as a one of the allowed users from your database?
  4. Is the client's IP address allowed if the user is one of the allowed users from your database?
  5. Is the client's hostname allowed if the user is one of the allowed users from your database?
When a request comes in for a document, the server knows the IP address that the request is coming from. Once it has this address, it uses DNS to look up the hostname that corresponds to that IP address.

After this step, the server tries to match the incoming hostname with any hostnames specified in this form. If the client passes, the document is served. If the client fails the test, the server then checks its IP address against the restriction IP addresses. If it passes, the document is served. If it fails, then the server sends the message specified in the Restrict Access form (see page 80).

If you will be specifying hostnames to allow users from, decide how you want the hostnames processed. If you want to allow only users from the exact hostnames you'll specify, click Include specified names only. However, if you also want to accept users from alias domains of your specified hostnames, click Include aliases of specified names.

To allow users from specific hostnames or IP addresses, enter a wildcard pattern of hostnames or IP addresses in text fields. Restricting by hostname is more flexible than by IP address--if a user's IP address changes, you won't have to update this list. But on the other hand, restricting by IP address is more reliable--if a DNS lookup fails for a connected client, hostname restriction cannot be used.

If someone is allowed access by virtue of their hostname or IP address (as in steps 1 and 2 on page 83), they are not prompted for a login name or password (or their certificate). All other users are asked for that information. To allow access to the users listed in your database, follow these steps:

  1. Choose the user database containing the users you want.
  2. Choose whether to allow everyone from that database, or only certain groups and users.
  3. Using a comma-separated list, specify the groups in the Groups field, and/or the users in the Users field. For example, if your database contained Bob, Fred, Mary, and Joe, but you only wanted Bob and Mary to have access to this section, you would enter Bob,Mary. If you leave this entry blank, all users from the database are allowed access.
  4. To further restrict access, specify any additional hostnames or IP addresses the users in the database must connect from. These Hostnames and IP Addresses fields can be left blank if your database users can be from any hostnames or IP addresses.
  5. Specify the information that the user sees when asked for a login name and password by typing it in the Login Prompt field. For example, if you typed Sales information, users would see the following when they tried to the restricted pages: Enter the username for Sales information at [servername]

  6. Click Done.
  7. Click OK in the Restrict Access form when you have finished modifying access control for part of your server.

Using user-database utilities

In addition to using the Server Manager to work with access control databases, you can use the command-line database utilities that are included in extras/database in your server root directory.

You can use the command-line database utilities to create, edit, and remove access control users and groups.

Converting user databases

Use the cvuser command to convert a Netsite 1.1 NDBM database or NCSA-style database to the Berkeley DB format. The cvuser command requires that ndbmdump, which converts a Netsite 1.1 NDBM database to an NCSA-style database format, be in your PATH. You can set up a cron job to user cvuser to regularly update a version 2.01 server user database from another database.

To run cvuser, type the following command and options at the command prompt:

cvuser [-i ncsa-file|-d ndbm-file] [-cfhu] outputdb
The following describes the syntax. (You can also get this information online by typing mkuser -h.)

-i ncsa-file

Specifies an NCSA-style database as the input file.

-d ndbm-file

Specifies an NDBM file as the input file.

-c

Using this option encrypts input file passwords. You should only use this option if the passwords in the input file are not currently encrypted.

-f

Using this option extracts full user names from the input file.

-u

Use this option to update the existing output database. If a user in the input file is already in the output database, the -u option will replace the user information in the existing output database with the information in the input file.

outputdb

Specifies the output database name.

Managing database users

Using the command-database utilities to create, edit, and remove users is equivalent to using the Server Manager forms to manage database users.

Creating a user

Use the mkuser command to create a user in a database. To run mkuser, type the following command and options at the command prompt:

mkuser [-n real-user-name] [-p encrypted-password] [username] 
[authdb-directory]
The following describes the syntax. (You can also get this information online by typing mkuser -h.)

-n real-user-name
User's real name

-p encrypted-password
User's password

To create a username of jdoe for John Doe in the marketing database, type the following at the command prompt:

mkuser -n `John Doe' -p"mb!i12mo" jdoe /usr/ns-home/authdb/marketing

Editing a user

Use the chuser command to edit an existing user in a database. To run chuser, type the following command and options at the command prompt:

chuser [-a new-username] [-n real-user-name] [-p encrypted-password] [-u user-id] [username] [authdb-directory]

The following describes the syntax. (You can also get this information online by typing chuser -h.

-a new-username
New username for existing user

-n real-user-name
User's real name

-p encrypted-password
User's password

-u user-id
Use the -u option to specify the user ID rather than the username

To change the username for John Doe from jdoe to johndoe in the marketing database, type the following at the command prompt:

chuser -ajohndoe -n `John Doe' jdoe /usr/ns-home/authdb/marketing
To specify the user ID rather than the username of johndoe and change the password, type the following at the command prompt. (You can get the user ID by using the shuser command, which is described in the "Showing information about an existing user" section.)

chuser -u263 -pmgi28mo /usr/ns-home/authdb/marketing

Removing an existing user

Use the rmuser command to remove an existing user from a database. To run rmuser, type the following command and options at the command prompt:

rmuser [-u user-id] [username] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing rmuser -h.)

-u user-id
User ID, used instead of username

To remove the username for John Doe from the marketing database, type the following at the command prompt:

rmuser jdoe /usr/ns-home/authdb/marketing

Showing information about an existing user

Use the shuser command to show information about an existing user in a database. To run shuser, type the following command and options at the command prompt:

shuser [-u user-id] [-N] [username] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing shuser -h.

-u user-id
User ID, used instead of username.

-N
Use this option to show the numeric group ID.

username
The username of the user you want to see information about. You can also use a shell expression (for example, using "*" will match all users in the database).

To show information about John Doe (jdoe) from the marketing database, type the following at the command prompt:

shuser jdoe /usr/ns-home/authdb/marketing
Information about the user John Doe appears:

Username:  jdoe
Password:  AOFoNlqb
User id:   249
Flags:     0x0
Real name: John Doe
The following describes the information you see.

Username

The username of the user.

Paword

The password for the user

User id

The User ID for the user.

Flags

Reserved (currently unused)

Real name

The user's name.

To show information about all the users in the marketing database, type the following at the command prompt:

shuser "*" /usr/ns-home/authdb/marketing
Output similar to the following appears:

jdoe:pmgi28mo:::John Doe
chris:34dwvez:::Chris Smith

Managing database groups

Using the command-database utilities to create, edit, and remove groups is equivalent to using the Server Manager forms to manage database groups.

Creating a group

Use the mkgroup command to create a user in a database. To run mkgroup, type the following command and options at the command prompt:

mkgroup [-d group-description] [-g group-list] [-u user-list] 
[group-name] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing mkgroup -h.

-d group-description
Description of the group

-g group-list
List of groups

-u user-list
List of users

group-name
Name of the group you want to see information about. You can also use a shell expression.

To create a group called domestic in the marketing database, type the following at the command prompt:

mkgroup -d `Engineering group' domestic /usr/ns-home/authdb/marketing

Editing a group

Use the chgroup command to edit a group in the database. To run chgroup, type the following command and options at the command prompt:

chgroup [-ar] [-d group-description] [-g group-list] [-u user-list] [-i 
group-id] [group-name] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing chgroup -h.)

-d group-description
Description of the group

-g group-list
List of groups

-u user-list
List of users

To edit a group called domestic in the marketing database, type the following at the command prompt:

chgroup -d `domestic marketing' domestic /usr/ns-home/authdb/marketing

Removing a group

Use the rmgroup command to edit a group in the database. To run rmgroup, type the following command and options at the command prompt:

rmgroup [-i group-id] [group-name] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing rmgroup -h.)

-i group-id
Use this option to specify the group ID rather than the group name.

To remove a group called domestic in the marketing database, type the following at the command prompt:

rmgroup domestic /usr/ns-home/authdb/marketing

Showing information about a group

Use the shgroup command to show information about an existing group in a database. To run shgroup, type the following command and options at the command prompt:

shgroup [-i group-id] [-N] [group-name] [authdb-directory]

The following describes the syntax. (You can also get this information online by typing shgroup -h.)

-i group-id
Group ID, used instead of group name.

-N
Use this option to show the numeric group ID.

group-name
The name of the group you want to see information about. You can also use a shell expression.

To show information about the domestic group in the marketing database, type the following at the command prompt:

shgroup domestic /usr/ns-home/authdb/marketing
Information about the group domestic appears:

Group name:  domestic
Group id:    250
Flags:     0x0
The following describes the information you see.

Group name

The username of the user

Group id

The password for the user

Flags

Reserved (currently unused)

To show information about all the groups in the marketing database, type the following at the command prompt:

shgroup "*" /usr/ns-home/authdb/marketing
Information about the groups appears in the following format:

group-name:group-description:member-group-list:member-user-list
Note that the member-group-list and the member-user-list are comma-separated lists of member group names and usernames, respectively. These lists might span multiple lines, and therefore contain spaces and newline characters.

Access control list files

An access control list (ACL) file is a text file that contains lists used to control access to server resources. Each list has its own name and a set of specific access control rights it controls. The list specifies information about which clients are allowed or denied access and how to authenticate users. Note that an ACL file does not contain information about which server resources are affected; the directives in the obj.conf file contain references to ACLs that are defined in the ACL file.

When you use the Server Manager to restrict access control, the changes are added to a file called genwork.httpd-[servername].acl, which is located in the httpacl directory in your server root directory; this file contains changes that you have made but not saved and applied yet. After you save and apply your changes, the information you entered is added to a file called generated.httpd-[servername].acl, which is also located in the httpcl directory.

The following is an example of the generated.httpd-[servername].acl.

ACL httpd-server1_formgen-READ-ACL-allow-2898 (GET, HEAD, POST, INDEX) {
Default allow anyone;
}
ACL httpds-server1_formgen-WRITE-ACL_deny-2898 (PUT, DELETE, MKDIR, 
RMDIR, MOVE) {
          Default deny anyone;
}
ACL httpd-server1_formgen-WRITE-ACL_deny-2249 (PUT, DELETE, MKDIR, 
RMDIR, MOVE) {
          Default deny anyone;
          Default authenticate in {
                    Database "/usr/ns-home/authdb/default";
                    Method basic;
          };
          Default allow all;
}
ACL httpd-server1_formgen-READ-ACL_allow-2249 (GET, HEAD, POST, INDEX) {
          Default deny anyone;
          Default authenticate in {
                    Database "/usr/ns-home/authdb/default";
                    Method basic;
                    Prompt "Database users";
          };
          Default allow all;
}
You can have more than one ACL file for your server by specifying multiple ACLFile directives in the magnus.conf file. If you have multiple ACL files, make sure that the ACL names defined in your files, including the generated ACL file, do not conflict with each other. For more information about ACL file syntax, see the "ACL file syntax" section.

For example, you would include the following lines in your magnus.conf file if you wanted to use a generated ACL file and an ACL file called engineer.acl.

ACLFile /usr/ns-home/httpacl/generated.httpd-server1.acl
ACLFile /usr/ns-home/httpacl/engineer.acl
The following is an example of what a directive in the obj.conf file might look like.

<Object ppath="/usr/docs/private/*">
PathCheck fn="check-acl"
          acl="read-private"
          path="*.doc"
          bong-file="/usr/docs/errors/deny.htm"
</Object>
By specifying path="*.doc" the ACL would only be applied to files with a .doc extension. The file specified for bong-file is what is sent to the client if access is denied.

ACL file syntax

You can use letters, numbers, hyphens, and underscores in the ACL file; identifiers, which include ACL names, access-control rights, usernames, and group names, must begin with a letter. Usernames, group names, and database names are case-sensitive; other identifiers are not case-sensitive. You can use spaces, tabs, and newline characters in an ACL file. Comments are specified with # at the beginning of the line and with a newline character.

An ACL file contains a list of ACL definitions, which specify an ACL name, access control rights that are controlled by the ACL, and ACL statements. An example of an ACL definition:

ACL acl-name access-rights {
        acl-statements
}
The following defines the parts of the ACL definition.

The following are items to keep in mind when creating ACL files:

ACL definition examples

ACL specs (GET, HEAD) {
     Default authenticate in {
          Database "engineers";
          Method basic;
     };
     Default allow all at *;
     Default deny jdoe at *;
}
In the first ACL statement in the previous example, the database named engineers is being used to store access-control user and group definitions. Basic authentication, which requires that users enter a username and password, is being specified as method used to verify users.

The second ACL statement specifies that all users in the engineers database have GET and HEAD access rights as long as they provide a valid username and password, which are stored in the database.

The last ACL statement specifies that the user jdoe will be denied access, even after entering a username and password.

ACL specs (GET, HEAD) {
     Default authenticate in {
          Database "engineers";
          Method SSL;
     };
     Default deny anyone at *;
     Default allow all at *.netscape.com;
     Default deny temps at *.netscape.com;
}
In the first ACL statement in the previous example, the method of authentication specified is SSL. Only users who can authenticate themselves using an SSL client certificate will be allowed access.

The second statement denies access to everyone at any host. The third statement allows access to everyone in the engineers database who connects using a system with DNS names ending with netscapst statement denies access to any users in the group called temps.