Netscape Compass Server Administrator's Guide

Chapter 9
Controlling Access to the Server

You can control who accesses the Compass Server. This chapter discusses the various methods you can use to determine who has access to what resources on your Compass Server. If you want to control who can configure the Compass Server itself and who can access the server configuration files, see Managing Netscape Servers.

What Is Access Control?

Access control lets you determine who can access the server. You can use two attributes for controlling access:

User-Group requires users to enter a username and password before accessing the server.

Host-IP requires the user to access the Compass Server from a specific computer, where the server recognizes the computer by either its hostname or its IP address.

User-Group Authentication

You can require users to authenticate themselves before getting access to your server. Authentication means that users verify their identity by entering a username and password.

If you require users to enter a username and password to get access to your server, you store the list of users and groups in an LDAP database, which can be either a file stored on the server computer or an LDAP server on a remote computer (for example, a computer running Netscape Directory Server).

When users attempt to access a file or directory that has User-Group authentication, the web browser displays a dialog box asking the user to enter a username and password.

After entering the information, the user either sees the file or directory listing requested or a message denying access. (You can customize the access-denied message that they see.) Figure 9.1 shows the authentication window. This window shows a custom message.

Figure 9.1 Users see this window when authenticating themselves to the server.

NOTE: If your server doesn't use SSL encryption, the username and password that the end user types are sent unencrypted across the network. Someone could intercept the network packets and read the username and password being sent to the server. For this reason, User-Group authentication is most effective when combined with SSL encryption or Host-IP authentication, or both.

Host-IP Authentication

You can limit access to files and directories on your Compass Server by making them available only to people using specific computers. You specify hostnames or IP addresses for the computers that you want to allow or deny. You can use wildcard patterns to specify multiple computers or entire networks. If you want to use this feature, you must have DNS running in your network and your computer must be configured to use it.

End-user access to a file or directory using Host-IP authentication appears seamless. Users can access the files and directories immediately without entering a username or password. If the computer doesn't have access, the user will get a message denying access. (You can also customize this message.)

NOTE: It's possible for more than one person to have access to a particular computer. For this reason, Host-IP authentication is most effective when combined with User-Group authentication. If both methods of authentication are used, the end user will have to enter a username and password before getting access.

Access Control Files

When you use access control on your server, the settings are stored in a file with the extension .acl. Access control files are stored in the directory server_root/server_typeacl where server_type is the name of the server. For example, the administration server uses the directory adminacl. Netscape Compass Server uses compassacl.

The main ACL file name is generated-compass-server-id.acl; the temporary working file is called genwork-compass-server-id.acl. If you use the Server Manager forms to restrict access, you'll have these two files. However, if you want to do more complex restrictions, you can create multiple files and reference them from the magnus.conf file. There are also a few features available only by editing the files. For example, you can restrict access to the server depending on the time of day or day of the week.

You also manually create and edit .acl files if you want to customize access control. For example, you might want to use an Oracle or Informix database of users instead of an LDAP database. To do this type of customizing, you need to use the access control API to program a hook into the server's access control structure. This API is written in C. For more information on the API, see the Netscape DevEdge Online site at http://developer.netscape.com.

How Does Access Control Work?

You can control access to the entire server or to parts of the server (that is, directories, files, file types).When the server evaluates an incoming request, it determines access based on a hierarchy of rules called access-control entries (ACEs), and then it uses the matching entries to determine if the request is allowed or denied. Each ACE specifies whether or not the server should continue to the next ACE in the hierarchy. The collection of ACEs is called an access-control list (ACL). When a request comes in to the server, the server looks in obj.conf for a reference to an ACL, which is then used to determine access. By default, the server has one ACL file that contains multiple ACLs.

Restricting Access

This section takes you through the process of restricting access to the Compass Server. 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.

To create an access-control rule, do the following:

Specify the part of your Compass Server (the resource) that you want to control. For example, you can select Entire Server to set up access control for your entire server.
Click the Edit Access Control button. The right frame divides into two frames that you use to set the access control rules. If the resource you chose already has access control, the rules will appear in the top frame. The following figure briefly describes the form elements.

Figure 9.2 The ACL form contains links that, when clicked, display another form in the bottom frame (not shown).

Click the New Line button. This adds a default ACL rule to the bottom row of the table. You can use the up and down arrows in the left column to move the rule, if needed.
Select the action you want to apply to the rule by clicking the Deny link. The bottom frame displays a form where you can check if you want to deny or allow access to the users, groups, or hosts you'll specify in the following steps. Check the option you want, and then click Update.
Specify User-Group authentication by clicking the "anyone" link listed under the Users/Groups column. The bottom frame displays a form for configuring User-Group authentication. By default, there is no authentication, meaning anyone can access the resource.
Check the options you want, and then click Update.
Specify the computers you want to include in the rule by clicking the "anyplace" link. The bottom frame displays a form where you can enter wildcard patterns of host names or IP addresses to allow or deny.
Check the options you want, and then click Update.
Specify the access rights you want to include in the rule by clicking the "all" link. Check the access rights in the bottom frame, and then click Update.
If you are familiar with ACL files, you can enter a customized ACL entry by clicking X under the Extra column. This area is useful if you use the access control API to customize ACLs.
Check Continue 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. When creating multiple lines in an access-control entry, it's best to work from the most general restrictions to the most specific ones.
Repeat steps 4 through 10 for each rule you need. If you want the user to be redirected to another URL if their request is denied, check "Response when denied." Click the link to specify the URL for redirection.
Click the Submit button 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. Be cautious when using Revert because you can't restore your edits. In most cases, it's probably better to delete the rule lines individually.

The following sections describe the options that appear in the bottom frame of the access-control window.

Setting Access-Control Actions

You can specify the action the server takes when a request matches the access-control rule.

Allow means the people or computers can access the requested resource.

Deny means the people or computers cannot access the resource.

The server goes through the list of ACEs to determine what the access is. 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, in Figure 9.3 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.

Figure 9.3 You can combine Deny and Allow statements in an ACL.

Specifying Users and Groups

You can restrict access to your Compass Server based on the user who requests a resource. The Compass 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 Compass Server computer or in an LDAP server, such as 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 field, a form appears in the bottom frame. The following list describes the options in the form.

Anyone (No Authentication) is the default and means anyone can access the resource. However, the user might be denied access based on other settings, such as host name or IP address.

Authenticated people only means all users requesting the resource will have to enter a username and password before getting access. 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.

All in the authentication database matches any user who has an entry in the database. To use this option, you must also check "Authenticated people only."

Only the following people lets you specify certain users and groups to match. 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 check "Authenticated people only."

Group matches all users in the groups you specify.

User matches the individual users you specify.

Prompt for authentication lets you specify message text that appears in the authentication window. You can use this text to describe what the user needs to enter. Depending on the operating system, the user will see about the first 40 characters of the prompt. Netscape Navigator and Netscape Communicator cache the username and password and associate them with the prompt text. This means that if the user accesses areas (files and directories) of the server that have the same prompt, the user won't have to retype usernames and passwords. Conversely, if you want to force users to reauthenticate for various areas, you simply need to change the prompt for the ACL on that resource.

Specifying Hostnames and IP Addresses

You can restrict access to your Compass Server based on which computer the request comes from. You specify this restriction by using wildcard patterns that match the computers' host names or IP addresses. For example, to allow or deny all computers in a specific domain, you would enter a wildcard pattern that matches all hosts from that domain, such as *.netscape.com.

To specify users from hostnames or IP addresses, follow the general directions for restricting access. When you click the From Host field (the link called "anyplace"), a form appears in the bottom frame. Check the "Only from" option and then type either a wildcard pattern or a comma-separated list of hostnames and IP addresses. 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 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.

Setting Access Rights

You can set access rights to files and directories on your web site. That is, 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 Rights link in the top frame, and 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.

Read access lets a user view a file. This access right includes the HTTP methods GET, HEAD, POST, and INDEX.

Write access lets a user change or delete a file. Write access right includes the HTTP methods PUT, DELETE, MKDIR, RMDIR, and MOVE.

Execute access applies to server-side applications, such as CGI programs, Java applets, and agents.

Delete access means a user can delete a file or directory.

List access means the user can get directory information. That is, they can get a list of the files in that directory. This applies to Web Publisher and to directories that don't contain an index.html file.

Info access means the user can get headers (http_head method). This is mainly used by the Web Publisher.

Writing Customized Expressions

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:00am to 5:00pm. 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 online help.