This section takes you through the process of restricting user access to documents on your Web site. The sections following this one describe in detail each option available when using access control. Keep in mind that most access control rules use only a subset of the available options.
There is also a section of examples on restricting different resources. You can review these examples in Restricting Access to the Entire Server.
To create an access-control rule:
From the Web Manager home page, click Enterprise Web Server servername > Server Preferences > Restrict Access.
A form appears on which you select and edit an existing access control rule or specify a new rule by either choosing the resource you want to apply to the rule (the file, directory, or wildcard pattern you want to control) or typing a name to assign to the ACL. There are three sections to this main form:
In the section you want to modify, from the Editing field select the part of your Web site (the resource) that you want to control.
For example, you can select Entire Server to set up access control for your entire server.
HINT: Refer to Table 18 at the end of this procedure for an example list of resources that are typically given limited access control.
Click Edit Access Control.
Click New Line.
Click Deny to select the action you want to apply to the rule.
The bottom frame displays a form where you can select whether you want to allow or deny access to the users, groups, or hosts you'll specify in the following steps. Select the option you want > click Update.
Click Anyone to specify User-Group authentication listed under the Users/Groups column.
Select the options you want > click Update.
See Specifying Users and Groups for more detailed information about each option.
Click Anyplace to specify the computers you want to include in the rule.
Select the options you want > click Update.
See Specifying Hostnames and IP Addresses for more information about each option.
Click All to specify the access rights you want to include in the rule.
Check the access rights in the bottom frame > click Update.
Click X under the Extra column to enter a customized ACL entry if you are familiar with ACL files.
This area is useful if you use the access control API to customize ACLs.
Click Update.
Check the appropriate box in the Continue column if you want the access control rule to continue in a chain.
This means the next line is evaluated before the server determines if the user is allowed access.
Check Access Control Is On.
See When Access Control Is On for more information.
Check Response When Denied if you want the user to be redirected to another URL if their request is denied.
Select Respond with the Following URL > type the URL in the field.
Click Update.
See Responding When Access Is Denied for more information.
Repeat steps 8 through 17 for each rule you need.
Click Submit to store the new access control rules in the ACL file.
If you click Revert, the server removes any changes you made to the rules from the time you first opened the two-frame window
WARNING: Be cautious when using Revert because you cannot restore your edits. In most cases, it is probably better to delete the rule lines individually.
Click Save and Apply.
Table 18. Example List of Resources That Are Typically Given Limited Access Control
The following sections describe the options that appear in the bottom frame of the access control window.
You can specify the action the server takes when a request matches the access control rule.
The server goes through the list of ACEs to determine the access. For example, the first ACE is usually to deny everyone. If the first ACE is set to continue, the server checks the second ACE in the list. (If Continue is not checked, everyone would be denied access to the resource.) If the second entry matches, then the next ACE is used. The server continues down the list until it reaches either an ACE that doesn't match or that matches, but is set to not continue. The last ACE that matches is used to determine if access is allowed or denied. For example, any user in the database can view a file (read access), but they must be in the Pubs group if they want to publish a file to the server.
You can restrict access to your Web site based on the user who requests a resource. With user and group authentication, users are prompted to enter a username and password before they can access the resource specified in the access control rule.
The Web server uses a list of users, who might be sorted into groups, to determine access rights for the user requesting a resource. The list of users (and the groups they are included in) are stored either in a database on the Web server computer or in an LDAP server, such as the Netscape Directory Server. You should make sure the database has users and groups in it before you set access control.
You can allow or deny access to everyone in the database, or you can allow or deny specific people by using wildcard patterns or lists of users or groups.
To configure access control with users and groups, follow the general directions for restricting access. When you click the Users/Groups column, a form appears in the bottom frame. The following list describes the options in the form:
If the username they enter isn't in the database, the access control rule won't apply to them. However, if the rule says Deny and then a group is listed, that group is denied, but everyone else in the database could be allowed depending on if there is another ACL that matches their request.
You can list the users and groups of users individually by separating the entries with commas. Or you can enter a wildcard pattern. To use this option, you must also select Authenticated People Only.
You can restrict access to your Web site based on which computer the request comes from. You specify this restriction by using wildcard patterns that match the computers' hostnames or IP addresses.
To specify users from hostnames or IP addresses, follow the general directions for restricting access. 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 or a comma-separated list. The wildcard notations you can use are specialized; you can only use an asterisk (*). Also for the IP address, the asterisk must replace an entire byte in the address. For example, 198.95.251.* is acceptable, but 198.95.251.3* is not. When the asterisk appears within an IP address, it must be the right-most character. For example, 198.* is acceptable, but 198.*.251.30 is not.
For hostnames, the asterisk must also replace an entire component of the name. For example, *.novell.com is acceptable, but *sers.novell.com is not. When the asterisk appears in a hostname, it must be the left-most character. For example, *.novell.com is acceptable, but users.*.com is not.
You can set access rights to files and directories on your Web site. In addition to allowing or denying all access rights, you can specify a rule that allows or denies partial access rights. For example, you can give people read-only access rights to your files, so they can view the information, but not change the files. This is particularly useful when you use the Web publishing feature to publish documents.
When you create an access control rule, the default access rights are set to all access rights. To change access rights, click the appropriate link in the Rights column in the top frame, then check or uncheck the access rights you want to set for a particular rule. The following list describes each access right you can check.
You can enter custom expressions for an ACL. You can use this feature if you are familiar with the syntax and structure of ACL files. There are a few features available only by editing the ACL file or creating custom expressions. For example, you can restrict access to your server depending on the time of day, day of the week, or both.
The following customized expression shows how you could restrict access by time of day and day of the week. This example assumes you have two groups in your LDAP directory: the Regular group gets access Monday through Friday, 8:00 a.m. to 5:00 p.m. The Critical group gets access all the time.
allow (read)
{
(group=regular and dayofweek="mon,tue,wed,thu,fri");
(group=regular and (timeofday>=0800 and timeofday<=1700));
(group=critical)
}
For more information on valid syntax and ACL files, see the Help.
You can turn off access control for any part of the server that a user accesses. For example, you could create an ACL that restricts access to the resource .HTML. You could then have an ACL for the entire server that is turned off. In this case, the only time access-control is used is when a user requests any file or directory in the *.HTML extension.
When you uncheck the option, you'll get a prompt asking if you want to erase records in the ACL. When you click OK, the server deletes the ACL entry for that resource from the ACL file.
If you want to deactivate an ACL, you can comment out the ACL lines in the file GENERATED-HTTPS-SERVER-ID.ACL by putting pound signs (#) at the beginning of each line.
You can choose the response a user sees when denied access. You can vary the message for each access control object. By default, the user is sent a message that says the file wasn't found. The HTTP error code "404 Not Found" is also sent.
To change what message is sent for a particular ACL:
In the ACL form, click Response When Denied.
In the lower frame, select Respond with the Following URL.
In the text field, type a URL or URI to a text or HTML file in your server's document root that you want to send to users when they are denied access.
Make sure the file doesn't contain references to other files, such as style sheets or images, because they won't be sent.
Click Update.
IMPORTANT: Make sure any users who get the response file have access to that file. If you have access control on the response file and the user is denied access to both the original resource and the response file, the server will send the default denied response.
Click Submit in the top frame.