Chapter 14 Controlling Access to Your Server

This chapter discusses the various methods you can use to control access to the Administration Server and to the files or directories on your web site. For example, for the Administration Server, you can specify who has full control of all the servers installed on a machine and who has partial control of one or more servers. Before you can use access control on the Administration Server, you must enable distributed administration from The Distributed Administration Page and set up an administration group in your LDAP database. This chapter assumes you have already configured distributed administration and have defined users and groups in your LDAP database.

• What Is Access Control?
• How Access Control Works
• Restricting Access to Your Web Site
• Access Control Examples
• Access Control For Web Publishing

• User-Group. This method requires users to enter a username and password before accessing the server. The server compares the information in a client certificate or the client certificate itself with a directory server entry. This methods requires the use of a directory server. If you choose to use client certificates, you should increase the value of the AcceptTimeout directive in magnus.conf.
• Host-IP. This method requires the user to access the web server from a specific computer, where the web server recognizes the computer by either its hostname or its IP address. This methods does not require a directory server.

• Setting ACL User Cache Time
• User-Group Authentication


• Host-IP Authentication


• Access Control Files

• The server can use the information in the certificate as proof of identity.
• The server can verify the certificate itself if certificates are published in an LDAP directory.

1. When the browser sends the certificate, the server checks if the certificate is from a trusted CA. If not, the server ends the transaction, and the authorization fails.
2. If the certificate is from a trusted CA, the server maps the certificate to a user's entry using the certmap.conf file. See Using the certmap.conf File for more information on setting up the certificate mapping file.
3. If the certificate maps correctly, then the web server checks the ACL rule specified for that user. Therefore, even though the certificate maps correctly, if the ACL denies the user access, the rule can deny the request.

Note. Only the SSL authentication method requires modification to the certmap.conf file. Allowing client authentication for all connections to the server does not.

In order for a client to successfully gain access to a SSL authenticated resource requiring client certificates, the client must install a certificate on their browser which is from a certificate authority trusted by the web server. It may be necessary to have the same client certificate published in a directory server if the web server's certmap.conf file is configured to compare the entire certificate between the client's certificate in the browser and the client certificate in the directory server entry. However, the certmap.conf file can be configured so that it only compares selected information from the certificate to the entry in the directory server. For example, you can configure the certmap.conf file so that the server only compares a user ID and an email address in the browser certificate with the directory server entry. In such a case, it would not be necessary to publish the entire client certificate to the directory server since only the user ID and email address must match to gain access.

AddLog fn="flex-log" name="access" iponly=1

# The following "es-internal" rules protect files such
# as icons and images related to iPlanet Web Server.
# These "es-internal" rules should not be modified.

acl "es-internal";
allow (read, list, execute,info) user = "anyone";
deny (write, delete) user = "anyone";

# The following "default" rules apply to the entire document
# directory of iPlanet Web Server. In this example, the rules
# are set up so that "all" users in the directory server are
# allowed to read, execute, list, and get information.
# The "all" users are not allowed to write to or delete any files.
# All clients that accesses the document directory of the web
# server will be required to submit a username and password
# since this example is using the "basic" method of
# authentication. A client must be in the directory server
# to gain access to this default directory since "anyone"
# not in the directory server is denied, and "all" in the
# directory server are allowed.

acl "default";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny (all)
(user = "anyone");
allow (read,execute,list,info)
(user = "all");

# The following rules deny access to the directory "web"
# to everyone not in the directory server and deny everyone
# in the directory server who is not in GroupB.
# Only the users in GroupB are allowed read, execute, list,
# and info permissions. GroupA can not gain access to the
# directory "web" even though (in the ACL rule below) they
# can access the directory "my_stuff". Furthermore, members
# of GroupB can not write or delete files.

acl "path=/export/user/990628.1/docs/my_stuff/web/";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny (all)
(user = "anyone");

allow (read,execute,list,info)
(group = "GroupB");

# The following rule denies everyone not in the directory
# server and denies everyone in the directory server except
# user with the ID of "SpecificMemberOfGroupB". The ACL rule
# in this setting also has a requirement that the user
# connect from a specific IP address. The IP address setting
# in the rule is optional; it has been added to for extra
# security. Also, this ACl rule has a Customized prompt
# of "Presentation Owner". This Customized prompt appears
# in the username and password dialog box in the client's
# browser.

acl "path=/export/user/990628.1/docs/my_stuff/web/presentation.html";
authenticate (user,group) {
database = "default";
method = "basic";
prompt = "Presentation Owner";
};
deny (all)
(user = "anyone" or group = "my_group");
allow (all)
(user = "SpecificMemberOfGroupB") and
(ip = "208.12.54.76");

# The following ACL rule denies everyone not in the directory
# server and everyone in the directory server except for
# GroupA and GroupB access to the directory "my_stuff"

acl "path=/export/user/990628.1/docs/my_stuff/";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny (all)
(user = "anyone");
allow (read,execute,list,info)
(group = "GroupA,GroupB");

If someone requests the following URL:

http://server_name/my_stuff/web/presentation.html

• Administration Server
• Server Manager

1. From the Server Manager, choose the Preferences tab.
2. Click the Restrict Access link.

The Access Control List Management Page appears. There are three parts to this page:

• Pick a resource allows you to specify a wildcard pattern for files or directories to restrict access to (such as *.html), or you can choose a directory or a filename to restrict. You can also browse for a file or directory by using the Browse button.
• Pick an existing ACL lists all the ACLs you have enabled. Even if an ACL exists, if you have not enabled it, it will not appear in this list.

Do not delete all the ACL rules from the ACL files. At least one ACL file is required to start the server, and the ACL file must have at least one ACL rule. If you delete all the ACL rules in the ACL files, and try to restart the server, you will see a syntax error.

• Type in the ACL name allows you to create named ACLs. Use this option only if you're familiar with ACL files and the obj.conf configuration file—you'll need to manually edit obj.conf if you want to apply named ACLs to resources.

Figure 14.2    The Restrict Access page has three sections.



3. Specify the part of the server (the resource) that you want to control in the Pick a resource section.

For example, you can select Entire Server to set up access control for the entire server. The drop-down list contains an entry for each ACL resource defined in the server root.

For some common examples of resources you might use for access control, see Table 14.1.

4. Click Edit Access Control.

The page 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 ACL for iPlanet Web Administration Server, begins with two non-editable deny statements by default. The following figure briefly describes the page elements.

Figure 14.3    The ACL page contains links that, when clicked, display additional information in the bottom frame
(not shown).



5. Click New Line.

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.

6. Select the action you want to apply to the rule by clicking Deny.

You can specify whether to deny or allow access to the users, groups, or hosts specified in the following steps in the bottom frame. Select the option you want, and then click Update.

7. Specify User-Group authentication by clicking "anyone" listed under the Users/Groups column.

The bottom frame allows you to configure User-Group authentication. By default, there is no authentication, meaning anyone can access the server resource. Select the options you want, and then click Update.

8. Specify the computers you want to include in the rule by clicking anyplace.

You can enter wildcard patterns of host names or IP addresses to allow or deny in the bottom frame. Select the options you want, and then click Update.

9. Specify the access rights you want to include in the rule by clicking all. Select the access rights in the bottom frame, and then click Update.
10. Specify the programs you want to restrict. Programs are the forms in the Server Manager for the server you selected. For example, you can restrict access to all forms for configuring the administration server by checking the "All Programs" radio button. If you want to restrict access to one or two sets of forms, choose the categories in the drop-down list. If you want to restrict access to one form in a category, type the name of the form in the "Program Items" field. For example, to restrict access to the access control form, type distacl in the Program Items field. For more information, see Access to Programs.

Click Update to add the programs options to the rules for the line you're editing.

11. 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.

12. Select 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.

13. Repeat steps 5 through 11 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.

14. 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 page. 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.

• Allow means the users or systems can access the requested resource.

• Deny means the users or systems cannot access the resource.

• Anyone (No Authentication) is the default and means anyone can access the resource without having to enter a username or password. However, the user might be denied access based on other settings, such as host name or IP address. For the Administration Server, this means that anyone in the administrators group that you specified with distributed administration can access the pages.

• 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." For the Administration Server, the users you specify must also be in the "administrators" group you specified for distributed administration.


• 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. For the Administration Server, the users in the groups you specify must also be in the "administrators" group you specified for distributed administration.
• User matches the individual users you specify.

• Prompt for authentication lets you specify message text that appears in the authentication dialog box. 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.

• Authentication Methods specifies the method the server uses when getting authentication information from the client.



• Default uses the default method you specify in the obj.conf file, or "Basic" if there is no setting in obj.conf. If you check Default, the ACL rule doesn't specify a method in the ACL file. Default is the best choice because you can easily change the methods for all ACLs by editing one line in the obj.conf file.
• Basic uses the HTTP method to get authentication information from the client. The username and password are only encrypted if encryption is turned on for the server.


• SSL uses the client certificate to authenticate the user. If you use this method, SSL must be turned on for the server. If you have encryption on, you can combine Basic and SSL methods.


• Other uses a custom method you create using the access control API.

• Authentication Database lets you select a database that the server uses to authenticate users. The default setting means the server looks for users and groups in an LDAP directory. However, you can configure individual ACLs to use different databases. You can specify different databases and LDAP directories in the file server_root/userdb/dbswitch.conf. Then, you can choose the database you want to use in the ACL by selecting it in the drop-down list. If you use the access control API to use a custom database (for example, to use an Oracle or Informix database), you can type the name of the database in the "Other" field in the User/Group window.

• 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. To delete a file, a user must have both write and delete privileges.
• Execute access applies to server-side applications, such as CGI programs, Java applets, and agents.
• Delete access means a user who also has write privileges 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.

1. From theAdministration Server, choose the Global Settings tab
2. Choose Restrict Access.
3. From the drop-down list, choose the server whose administration access you want to restrict. The administration server is labeled "https-admserv." Other servers are labeled with their type and their server id (for example, https-mozilla).

When you select a server to restrict, you are restricting who can view the Server Manager pages and which pages they can use to configure that server. For example, you might allow some administrators to configure the Users & Groups section of the administration server and not allow them access to the Global Settings.

4. Click Edit ACL. The web server displays the two-frame access control pages.
5. Each ACL begins with two deny lines (the default setting), one that restricts access to only those users in the "administrators" group set for distributed administration, and another that restricts access to all users. If you want to change either of these lines, you need to manually edit the ACL file. Click New Line to add a rule to the ACL. Each rule you create allows access to the server. By specifically allowing access for users, you reduce the risk that you'll allow access to users you don't want.
6. Choose the users, groups, hosts, and IP addresses you want to apply to this access control rule.
7. By default, administrators have access to all programs for a server. Click the All link under Programs in the top frame. The bottom frame displays a page that lists the programs for the server type you selected.
8. Select Only the following, and then select the Program Groups you want to apply to the rule. You can choose multiple groups by pressing the Control key and then clicking the groups you want.

The Program Groups listed use the same name as the buttons in the top frame of the Server Manager for the server type you selected. For example, in the administration server, there are tabs labeled Preferences, Global Settings, and so on. When an administrator accesses the administration server, the server uses their username, host, and IP to determine what pages they'll see. If they have access to only one or two pages, they will only see those pages.

9. You can control access to a specific page within a tab. Type the name of the page in the Program Items field.

To determine the name of a page, place your pointer over the link in the left frame of the Administration Server and then view the text in the status bar on the bottom of your browser. The last word after the last %2b is the name for that page.



For example, suppose you have one person who administers a Netscape Directory Server and you want that person to have access only to the "Configure Directory Service" page. In this case, you would set up a rule that applies to them (host, IP, and so on), and then you would enter dsconfig in the Program Items field.

10. Click Update and then click Submit to save the access control rule.

For more information on valid syntax and ACL files, see ACL File Syntax and Referencing ACL Files in obj.conf.

1. In the ACL page, click the Response when denied link.
2. In the lower frame, check the Respond with the following file radio button.
3. 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. The server must have read access to this file, so you should consider putting the file in the document root.

Make sure the file does not contain references to other files or images because they will not be sent.

4. Click Update.

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.

5. Make sure you submit the access control rule by clicking Submit in the top frame.

• Restricting Access to the Entire Server
• Restricting Access to a Directory (Path)


• Restricting Access to a URI (Path)


• Restricting Access to a File Type


• Restricting Access Based on Time of Day

1. In iPlanet Web Server, choose Server Preferences.
2. Click the Restrict Access link.

The web server displays the Access Control List Management page.

3. In the section called Pick a Resource, select "The entire server" from the Editing drop-down list and then click Edit Access Control.

The two-frame page appears.

4. Click New Line.

The default rule appears, which denies all access to the server. Typically, you should deny all access to your server, and then allow specific access to users, groups, and computers; however, you might change this if you want to deny access only to a small group of users or groups. Click New Line again to create a second rule.

5. Click the Deny link in the second rule. In the bottom frame that appears, check Allow, and then click Update.
6. Click the "anyone" link in the second rule. In the bottom frame, type the group you want to have access to the server.

For this example, type employees in the Group field. Note that the two options called "Authenticated people only" and "Only the following people" are checked automatically. Click Update.

7. Click the "anyplace" link in the second rule. In the bottom frame, type a wildcard pattern for the host names of the computers you want to allow.

For example, type *.emp.mozilla.com in the Host Names field. Click Update.

8. Unselect Continue in the top frame, and then click Submit.

The frame should look like the one in Figure 14.5.

9. Submit your changes.

Figure 14.5    Restricting access to the entire server

# File automatically written
#
# You may edit this file by hand
#

version 3.0;
acl "default";
authenticate (user,group) {
prompt = "Web Server"
}
deny (all)
user = "anyone";
allow absolute (all)
(group = "employees") and
(dns = "*.emp.netscape.com");

1. In the Server Manager, choose Server Preferences.
2. Click the Restrict Access link.

The web server displays the Access Control List Management page.

3. In the section called Pick a Resource, click the Browse button.

In the page that appears, click the link for the directory you want to restrict. The directories listed in this page are in the servers document root. Once you click a link, the Editing drop-down list displays the absolute path to the directory.

If you want to view all files in your server root, click Options and check the box labeled List files as well as directories and then click OK.

4. Click Edit Access Control.

The two-frame pages appear.

5. Click New Line twice to create two rules.

Don't edit the default values for the first rule—they deny all access to the directory. You'll edit the second rule to allow read access to the "executives" group.

6. Click Deny in the second rule. In the bottom frame that appears, check Allow, and then click Update.
7. Click anyone in the second rule. In the bottom frame, type the group you want to have access to the server. For this example, type executives in the Group field. Click Update.
8. Click all in the top frame. Uncheck the Write and Delete access rights.

This means the users in the executives group can't add or remove files, but they can view them and run any applications in the directories. Click Update.

9. Click New Line to create a rule for the "ceo" user. Check Allow for the third rule.
10. Click anyone. In the bottom frame, type ceo in the User field. Click Update.
11. Uncheck Continue for both the second and the third rules.

This means that the server ignores any ACLs for directories or files under the directory you specified in Step 3. The frame should look like the one in Figure 14.6.

Figure 14.6    Restricting access to a path in the server



12. Click Submit and save and apply your changes.

acl "path=/usr/netscape/server4/nes/docs/senior-staff/ ";
deny (all)
user = "anyone";
allow absolute (read,execute,list)
group = "executives";
allow absolute (all)
user = "ceo";

1. In the Server Manager, choose Server Preferences.
2. Click the Restrict Access link.

The web server displays the Access Control List Management page.

3. In the Type in the ACL name section, type the URI you want to control. For example, type uri=/my_directory.
4. Click Edit Access Control.

The two-frame pages appear.

5. Click New Line to create the first rule that allows all users read access.
6. Click the Deny link. In the bottom frame that appears, check Allow, and then click Update.
7. Click the all link in the top frame. Uncheck the Write and Delete access rights.

This means users cannot add or remove files, but they can view them and run any applications in the directories. Click Update.

8. Click New Line to create a rule for the owner of the directory. Check Allow for the second rule.
9. Click anyone. In the bottom frame, type me in the User field. Click Update.
10. Uncheck Continue for both the first and second rules.

This means that the server ignores any ACLs for other URIs, directories, or files under the URI you specified in Step 3. The frame should look like the one in Figure 14.7.

Figure 14.7    Restricting access to a URI (path) in the document root



11. Click Submit and save and apply your changes.

acl "uri=/my_directory";
allow absolute (read,execute,list,info)
user = "anyone";
allow absolute (all)
user = "me";

1. In the Server Manager, choose Server Preferences.
2. Click Restrict Access.

The web server displays the Access Control List Management page.

3. In the Pick a resource section, click Wildcard. In the prompt that appears, type *.cgi and click OK.

This wildcard pattern matches any request that contains a file or directory with the .cgi extension.

4. Click Edit Access Control.

The two-frame pages appear.

5. Click New Line to create the first rule that will allow all users read access.
6. Click Deny. In the bottom frame that appears, check Allow, and then click Update.
7. Click all in the top frame. Uncheck the Write and Delete access rights.

This means users can't add or remove files or directories with the .cgi extension. Click Update.

8. Click New Line to create a rule that allows write and delete access to the "programmers" group. Check Allow for the second rule.
9. Click anyone. In the bottom frame, type programmers in the Group field. Click Update.

The frame should look like the one in Figure 14.8.

Figure 14.8    Restricting access to a file type—in this case, to files with the .cgi extension



10. Click Submit and save and apply your changes.

1. Pathcheck functions in obj.conf. For example, these could be wildcard patterns for files or directories. The entry in the ACL file would appear as follows: acl "*.cgi";
2. URIs. For example, a path relative to the document root. The entry in the ACL file would appear as follows: acl "uri=/my_directory";
3. Pathnames. For example, an absolute path to a file or directory. The entry in the ACL file would appear as follows: acl "path=d:\netscape\suitespot\docroot1\sales/";

acl "*.cgi";
allow (read,execute,list,info)
user = "anyone";
allow (all)
group = "programmers";

1. In the Server Manager, choose Server Preferences.
2. Click Restrict Access.
3. In the Pick a Resource section, select "The entire server" from the Editing drop-down list. (You can select any resource.) Click Edit Access Control.

The server displays the two-frame pages.

4. Click New Line.
5. Click the Deny link. In the bottom frame that appears, check Allow, and then click Update.
6. Click the all link in the top frame. Uncheck the Write and Delete access rights.

This means that if a user wants to add, update, or delete a file or directory, this rule won't apply and the server will search for another rule that matches. Click Update.

7. Click New Line to create a rule that restricts the write and delete methods. Check Allow for the second rule.
8. Click the X link to create a customized expression. In the bottom frame, type the following lines:

user = "anyone" and
dayofweek = "sat,sun" or
(timeofday >= 1800 and
timeofday <= 600)

You might want to select the entire text element and copy to memory—if there are errors, you'll have to reenter the text. Click Update. The top frame will display "Unrecognized expressions" in the Users/Groups and From Host fields because you created a custom expression.

9. Click Submit. If you made any errors in the custom expression, you'll get a JavaScript alert. Correct any changes and click Submit again.

acl "uri=/publisher/";
allow (read, execute, list, info) user = anyone;
allow (write, delete) user = owner;

Web Publisher has many operations that are restricted to the broad category of valid server user. Many ACL rules, such as that for agents services, simply require a user to be valid for the server. That is, users who are defined in the server's users database.