Sun Java System Web Server 6.1 SP11 Administrator's Guide

Selecting Access Control Options

The following section describes the various options you can select when setting access control. For the Administration Server, the first two lines are set as defaults, and cannot be edited.

Setting the Action

You can specify the action to be taken by the server when a request matches the access control rule.

The server scans 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, that ACE is used. If continue is not selected, everyone would 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.

Specifying Users and Groups

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.

Sun Java System Web Server checks lists of users and groups stored either in an LDAP server, such as Sun Java System Directory Server, or in an internal file-based authentication database.

You can allow or deny access to everyone in the database, you can allow or deny specific people by using wildcard patterns, or you can select who to allow or deny from lists of users and groups.

Specifying the From Host

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

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 using hostname is more flexible than by IP address: if a user’s IP address changes, you will not 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 would enter a wildcard pattern that matches all hosts from that domain, such as * 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, * is acceptable, but * is not. When the * appears in a hostname, it must be the left-most character. For example, * is acceptable, but users.*.com is not.

For the IP address, the * must replace an entire byte in the address. For example, 198.95.251.* is acceptable, but* is not acceptable. 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 acceptable.

Restricting Access to Programs

Access to programs can only be restricted by the Administration Server. Restricting access to programs allows only specified users to view the Server Manager pages and determines if they can configure the server. For example, you might allow some administrators to configure the Users & Groups section of the administration server but might deny them access to modify Global Settings.

You can configure different users to access different functional domains. Once a user setup with access to a few selected functional domains logs in the Administration Server pages from only those functional domains are visible to the user.

Setting Access Rights

Access rights can only be set by the Server Manager for a server instance. 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 allows or denies partial access rights. For example, you grant users read-only access rights to your files, so they can view the information, but not change the files.

Writing Customized Expressions

You can enter custom expressions for an ACL. Select this option only 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 can restrict access by time of day and day of the week. This example assumes that you have two groups in your LDAP directory: the “regular” group gets access Monday through Friday, 8:00am to 5:00pm. while 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));

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

Turning Off Access Control

When you uncheck the option labeled “Access control is on,” you see 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 generated-https-server-id.acl file by putting # signs at the beginning of each line.

From the Administration Server, you could create and turn on access control for a specific server instance and leave it off (which is the default) for other servers. For example, you could deny access to the Server Manager pages from the Administration Server. With distributed administration setting turned on and access control turned off by default for any other servers, administrators could still access and configure other servers, but they cannot configure the Administration Server.

Note –

The access control is performed in addition to the user being part of the administrators group for distributed administration. The Administration Server first checks that a user (other than superuser) is in the administrators group, and then evaluates the access control rules.

Responding When Access is Denied

The Sun Java System Web Server provides the following default message when access is denied: “FORBIDDEN. Your client is not allowed access to the restricted object.” You can choose to show a different response when access is denied. You can also create a different message for each access control object.

ProcedureTo change the message sent for a specific ACL

  1. Click the Response When Denied link from the ACL page.

  2. Select Respond With the Following File in the lower frame.

  3. Enter the path to the absolute URL or a relative URI and click update.

    Make sure users have access to the URL or URI they are redirected to.

  4. Click Update.

  5. Click Submit in the top frame to submit the access control rule.