test

Oracle iPlanet Web Server 7.0.9 Administrator's Guide

Configuring Access Control

The server supports authentication and authorization through the use of locally stored access control lists (ACLs), which describe what access rights a user has for a resource. For example, an entry in an ACL can grant a user named John read permission to a particular folder, misc.

This section describes the process of restricting access to the files or directories on your web site. You can set global access control rules for all servers, and also individually for specific servers. For instance, a human resources department might create ACLs allowing all authenticated users to view their own payroll data, but restrict access to updating data to only human resource personnel responsible for payroll.

The core ACLs supported by the server are three types of authentication: basic, SSL, and digest.

To edit access control settings, perform the following tasks:

  1. Click the Configurations tab and select the configuration.

  2. Click the Security sub tab > Access Control sub tab.

  3. Click the Add ACL button to add a new ACL or click existing ACL to edit the settings.

Adding an Access Control List (ACL)

The following section describes the process of adding a new ACL to the configuration.

  1. Click the Configurations tab and select the configuration.

  2. Click the Access Control sub tab > Access Control Lists sub tab.

  3. Click the New button to add a new ACL.

Configure the following parameters:

Table 7–2 ACL Parameters

Parameter

Description

Resource

Named/URI/Path. Select the type of resource you need to set access restriction and specify the value. Example for URI resource — “/sales”. Example for Path resource — “/opt/oracle/webserver7/docs/cgi-bin/*”. 

Authentication DB

Authentication Database lets you select a database the server will use to authenticate users.

The default is keyfile

Authentication Method

  1. Basic — uses the HTTP Basic method to obtain authentication information from the client. The username and password are only encrypted over the network if SSL is turned on for the server.

  2. SSL — uses the client certificate to authenticate the user. To use this method, SSL must be turned on for the server. When encryption is on, you can combine Basic and SSL methods.

  3. Digest — uses an authentication mechanism that provides a way for a browser to authenticate based on username and password without sending the username and password as clear text. The browser uses the MD5 algorithm to create a digest value using the user’s password and some information provided by the Web Server. Note that in order to use Digest the underlying auth-db must support digest as well. This means either a File auth-db using digestfile or an LDAP auth-db must be present if the Digest Authentication Plug-in has been installed

  4. Other — uses a custom method created using the access control API.

Prompt for Authentication

Prompt for Authentication option enables you to enter 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 browser, the user will see the first 40 characters of the prompt.

Web browsers typically cache the username and password, and associate them with the prompt text. When the user accesses server files and directories with the same prompt, the usernames and passwords won’t need to be entered again. If you want users to authenticate again for specific files and directories, you simply need to change the prompt for the ACL on that resource. 

Denied Access Response

Specify the response action when an access to a resource is denied. 

1. Respond with default message — Select this option to display the standard access denied message from the server. 

2. Respond with URL — Select this option to forward the request to any other external URL or error page. 

Note –

Using CLI

To add an ACL through the CLI, execute the following command.


wadm> set-acl --user=admin --password-file=admin.pwd 
--host=serverhost --port=8989 --vs=config1_vs_1 --config=config1 
--aclfile=aclfile1

See CLI Reference, set-acl(1).

Adding an Access Control Entry (ACE)

The section describes the process of adding a new Access Control Entry (ACE) for the selected configuration.

  1. Click the Configurations tab and select the configuration.

  2. Click the Access Control sub tab > Access Control List sub tab.

  3. Click the New button.

  4. Click the New button under Access Control Entry.

Configure the following ACE parameters:

Table 7–3 ACE parameters

Parameter

Description

Access

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

  • Deny means users or systems cannot access the resource.

    The server goes through the list of access control expressions (ACEs) to determine the access permissions.

Users

1. Anyone — No authentication. Grants access to everyone.

2. All in the Auth DB — Grants access to all users specified in the authentication database.

3. Only the following in the Auth DB — Restrict access to selected users from the authentication DB.

You can query the authentication DB based on common attributes like First name, Last name and Email address. 

Groups

With group authentication, users are prompted to enter a username and password before they can access the resource specified in the access control rule. 

Use this option to restrict access to specific groups. 

From Host

You can restrict access to the Administration Server or your web site based on which computer the request comes from. 

  • Anyplace enables access to all users and systems.

  • Only from enables you to restrict access to specific Host Names or IP Addresses.

If you select the Only from option, enter a wildcard pattern or a comma-separated list in the Host Names or IP Addresses fields. Restricting by hostname is more flexible than by IP address: if a user’s IP address changes, you won’t need 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. 

You can only use the * wildcard notation for wildcard patterns that match the computers’ host names or IP addresses. For example, to allow or deny all computers in a specific domain, you will enter a wildcard pattern that matches all hosts from that domain, such as *.sun.com. You can set different hostnames and IP addresses for superusers accessing the Administration Server.

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

For the IP address, the * must replace an entire byte in the address. For example, 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 not 198.*.251.30.

Rights

Access rights restrict access to files and directories on your web site. In addition to allowing or denying all access rights, you can specify a rule that enables or denies partial access rights. For example, you allow users read-only access rights to your files, so they can view the information, but not change the files. 

  • All Access Rights is the default and will allow or deny all rights.

  • Only the following rights allow you to select a combination of rights to be allowed or denied:

    • Read enables users to view files, including includes the HTTP methods GET, HEAD, POST, and INDEX.

    • Write enables users to change or delete files, including the HTTP methods PUT, DELETE, MKDIR, RMDIR, and MOVE. To delete a file, a user must have both write and delete rights.

    • Execute enables users to execute server-side applications, such as CGI programs, Java applets, and agents.

      POST maps to execute right only.

    • Delete enables users who also have write privileges to delete files or directories.

    • List enables users to access lists of the files in directories that do not contain an index.html file.

    • Info enables users to receive information about the URI, for example http_head.

Continue

The server goes through the list of access control expressions (ACEs) to determine the access permissions. 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, and if it matches, the next ACE is used. 

If continue is not checked, everyone will be denied access to the resource. 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 matching ACE determines if access is allowed or denied.