Complete Contents
Introduction
Chapter 1 Using Netshare
Chapter 2 About Web Server Publishing
Chapter 3 Installing and Configuring
Chapter 4 Web Publisher Quickstart
Chapter 5 Services and Menus
Chapter 6 Search
Chapter 7 Access Control
PreviousContents




Chapter 7 Controlling Access

You can control who accesses your Web Publisher documents and directories and what operations different users or different groups of users can perform upon them. You can completely prohibit access to a file or folder or you can restrict access to certain authenticated users.

Note
You can display or modify access control only for your own files or folders. If you want to define the access permissions for a file or folder that has no owner, you must first go to the Web Publisher Services page and use the Properties form to assign ownership to yourself. See the section, "Ownership of Files and Folders," for more information about this topic.

Access control is based on a hierarchy of rules that specify certain restrictions. A set of rules is called an access control list (ACL). The access control hierarchy is based on the URL Path or file path, with ACL rules cascading from the top down through each progressively lower layer of directories and subdirectories until it reaches the file. When a request for access is made, the server goes in turn through each rule, continuing until it encounters a rule that prevents it from continuing or comes to the last rule for that resource.

This chapter discusses these topics:

    • User Authentication

    • Web Publisher Access Permissions

    • Ownership of Files and Folders

    • Setting Access: An Example

    • Access Control: The Details

    • The Access Control Window

    • Additional Options

User Authentication
You identify yourself by entering your user name and password in a dialog box or by using a client certificate installed in your web browser, such as Netscape Navigator or Netscape Communicator.

If your server isn't handling authentication for you with certificates, you must be defined in the server's users and groups database, which can be either a file stored on the web server computer or an LDAP server on a remote computer (for example, a computer running Netscape Directory Server).

When you attempt to access a file or directory that has User-Group authentication, the web browser displays a dialog box asking you to enter your user name and password. Figure 7.1 shows the default iPlanet Web Server authentication dialog box.

Figure 7.1    The authentication dialog box.

After entering the information, you are either allowed to access the file or directory listing requested or you are denied access. You can be denied access because you are not in the Users and Groups database, and are therefore unknown to the server, or because you have been specifically denied access in an access control rule.


Web Publisher Access Permissions
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.

When you start Web Publisher, you are immediately prompted with the user name authorization dialog box. You can leave this blank and operate as an anonymous user, but as soon as you attempt to perform an operation restricted to a valid user, you are again prompted for your user name. At this point, you are also asked to enter your password, and only authenticated users can continue with the operation.


Ownership of Files and Folders
Web Publisher files and folders can be owned by individual users. Only the owner of a file or folder can define its access control definitions or reassign its ownership. If a file or folder has no owner, no one can modify its access control. As discussed in the sections "Setting Access: An Example" and "Setting Users and Groups," you can define an access control definition that restricts certain operations to the user who is the current owner of a file or folder, even when ownership is reassigned.

Your server administrator can do a bulk ownership assignment for you, you can assign ownership for an individual file or folder through the Web Publisher properties page, or you can become the owner of a file or folder as a result of an automatic assignment by Web Publisher when you perform certain actions.

Note
Locked files have a lock owner, which is not the same as being the file's owner. All a lock owner owns is the lock placed on a file. Only they can unlock their lock, with one exception: the server administrator can unlock any file lock.

Manually Assigning Ownership
You can use the properties page that is part of the Web Publisher Services form to manually assign ownership of a file or folder. You an only modify the Owner property is two cases:

Setting Access: An Example
You can restrict access to the files and folder that you own. This section takes you through an example of restricting access to the owner of a file. In the example, the chosen file is the index.html file for the default document directory. The steps given are the same ones you would use for defining access control rules for any file or folder.


Access Control: The Details
The Web Publisher access control interface allows a wide and flexible range of access definitions. The interface has two frames, with the top part displaying the ACL rules that are being updated with new or modified data from the several different forms that are shown in the bottom part. The top frame has several icons and checkboxes that you can use to customize your access control.

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

The Access Control Window
There are some special graphical elements in the ACL window that help you rearrange and delete individual rules. There is also a checkbox that allows you to redefine what users see when they are denied access to a resource.

Moving Rules Up and Down
Rules are applied in the order in which the server encounters them. Once you define a rule, you can use the arrows on the left of each rule to rearrange the sequence of rules for a resource. This is especially useful when you want to temporarily define an absolute rule that blocks access to later rules. By moving the rule up in the sequence, you don't need to delete the rule and recreate it later. Just place it below the absolute rule, and the server never checks it.

Deleting ACL Rules
When you uncheck the "Access control is on" option, you are prompted to confirm if you want to erase records in the ACL file. When you click OK, the server deletes the entire set of access control rules for that resource.

A less drastic way of deleting an access control rule is to click the Trash can icon at the end of each line to delete a single rule.

Response When Access is Denied
You can choose the response a user sees when denied access. You can vary the message for each file or folder. By default, the user is sent a message that says the file wasn't found (the HTTP error message 404 Not Found is also sent). In general, do not change this setting without consulting with your server administrator.

To change the message that is sent for a particular resource when access is denied:

Note
Make sure any users who get the response file have access to that file. That is, 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 sends the default denied response.


Additional Options
Most users do not need the additional ACL features described in this section, but there may be cases where you need these features to provide the desired level of control for a file or folder. For example, you may need special restrictions on personnel directories in the HR group or confidential files belonging to the CEO of a company.

Using the Continue Option
By default, an access control rule has the Continue option checked. This allows lower-level files and folders to have their own ACL rules, which can contradict already defined ACL rules. For example, even though an earlier ACL rule allows anyone to read all files in a directory, you can define a rule for your files in this directory that denies access to everyone but yourself.

You could, however, set an ACL rule for a folder that prevents its files from having ACL rules that defined access in a different way. This is referred to as absolute control, and you set this option by unchecking the Continue checkbox. When the server evaluates the access control rules for a resource, it stops whenever it encounters a rule that does not have Continue checked.

For example, suppose someone requests the following file:

http://www.mozilla.com/docs/Project-X/presentation.html

The server checks all ACL rules that affect the object. First it checks any overall permissions for the server, then it checks the permissions for the /docs directory and then those for the /Project-X subdirectory. The server continues checking ACL rules until it reaches the ACL for the requested URL (in this case, the file presentation.html) or until it reaches an ACL rule that has the Continue option unchecked.

Once an absolute rule is encountered, the ACL defined as of that point is the only operative access control rule. You cannot define less restrictive rules for files or folders at lower levels of the document tree.

Specifying Host Names and IP Addresses
Although you probably won't need to do this, you can limit access to files and folders by making them available only to people using specific computers. 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.

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 has to enter a user name and password before getting access.

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 a host name or IP address, follow these steps:

Restricting by hostname is more flexible than by IP addressif a user's IP address changes, you won't have to update this list. Restricting by IP address, however, is more reliableif 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 *.

For IP addresses, 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.

 

© Copyright 2022 Sun Microsystems, Inc. Some preexisting portions Copyright 2022 Netscape Communications Corp. All rights reserved.