The following topics describe 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.
This section contains the following topics:
You can specify the action the server takes when a request matches the access control rule.
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 entries (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. If that ACE matches, the next ACE is used. If Continue is not selected, everyone is denied access to the resource. The server continues down the list until it reaches either an ACE that does not match or an ACE that matches but does not continue. The last matching ACE determines if access is allowed or denied.
With user and group authentication, users are prompted to provide a user name and password before they can access the resource specified in the access control rule.
The Proxy 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, allow or deny specific people by using wildcard patterns, or select who to allow or deny from lists of users and groups.
The following elements are displayed for Users/Groups on the Access Control Rules For page in the user interface.
Anyone (No Authentication) is the default and means anyone can access the resource without providing a user name 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 setting means that anyone in the administrators group that you specified for distributed administration can access the pages.
Authenticated People Only
All In The Authentication Database matches any user who has an entry in the database.
Only The following People specifies which users and groups to match. You can list users or groups of users individually by separating the entries with commas, or with a wildcard pattern, or you can select from the lists of users and groups stored in the database. Group matches all users in the groups you specify. User matches the individual users you specify. For the Administration Server, the users must also be in the administrators group you specified for distributed administration.
Prompt For Authentication specifies the message text that is displayed in the authentication dialog box. You can use this text to describe what the user needs to type. Depending on the operating system, users see approximately the first 40 characters of the prompt. Most browsers cache the user name and password and associate them with the prompt text. If the user accesses areas of the server files and directories that have the same prompt, the user does not need to retype user names and passwords. Conversely, if you want to force users to reauthenticate for various areas, you must change the prompt for the ACL on that resource.
Authentication Methods specifies the method the server uses for getting authentication information from the client. The Administration Server offers only the Basic method of authentication. The Server Manager offers the following methods:
Default uses the default method specified in the obj.conf file, or Basic if there is no setting exists in obj.conf. If you select Default, the ACL rule does not specify a method in the ACL file. Choosing Default enables you to 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 user name and password are only encrypted if encryption is turned on for the server (SSL is enabled). Otherwise, names and passwords are sent in clear text, and can be read if intercepted.
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, Basic and SSL methods can be combined.
You can enable security only in reverse proxy mode and not in forward proxy mode.
Digest uses an authentication mechanism that enables browsers to authenticate users based on user name and password without sending the user name 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 Proxy Server. This digest value is also computed on the server side using the Digest authentication plug-in and compared against the digest value provided by the client.
Prompt For Authentication is a required parameter in Digest Authentication. Change the value to match the realm (required for digest file). For example, if in the digest file, you have configured all users to be in the realm test, then the Prompt For Authentication field should contain the text test.
Other uses a custom method that you create using the access control API.
Authentication Database specifies the database that the server will use to authenticate users. This option is only available through the Server Manager. If you choose Default, the server looks for users and groups in a directory service configured as default. If you want to configure individual ACLs to use different databases, select Other, and specify the database. Non-default databases and LDAP directories must be specified in server-root/userdb/dbswitch.conf. If you use the access control API for a custom database, select Other, and type the database name.
You can restrict access to the Administration Server based on which computer the request comes from.
The following elements are displayed for From Host on the Access Control Rules For page in the user interface:
Anyplace allows access to all users and systems
Only From enables you to restrict access to specific host names or IP addresses
If the Only From option is selected, type a wildcard pattern or a comma-separated list in the Host Names or IP Addresses fields. Restricting by host name is more flexible than by restricting by IP address. If a user’s IP address changes, you do not need to update this list. Restricting by IP address, however, is more reliable. If a DNS lookup fails for a connected client, host name 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 *.example.com. You can set different host names and IP addresses for superusers accessing the Administration Server.
For host names, the * must replace an entire component of the name, that is, *.example.com is acceptable, but *users.example.com is not. When the * appears in a host name, it must be the leftmost character. For example, *.example.com 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 198.95.251.3* is not. When the * appears in an IP address, it must be the rightmost character. For example, 198.* is acceptable, but 198.*.251.30. is not.
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 whether those users can configure that server. For example, you might allow some administrators to configure the Users and Groups section of the Administration Server but deny access to the Global Settings section.
You can configure different users to access different functional domains. Once a user is given access to a few selected functional domains, after the user logs in, Administration Server pages from only those functional domains are available to that user.
The following elements are displayed for Programs on the Access Control Rules For page in the user interface:
All Programs allows or denies access to all programs. By default, administrators have access to all programs for a server.
Only The Following enables you to specify the programs to which users have access.
Program Groups reflect the tabs of the Administration Server, for example, Preferences and Global Settings, and represent access to those pages. When an administrator accesses the Administration Server, the server uses their user name, host, and IP address to determine the pages they can view.
Program Items enables you to control access to specific pages within a program by typing a page name in the field.
Access rights can only be set by the Server Manager for a server instance. Access rights restrict access to files and directories on your server. In addition to allowing or denying all access rights, you can specify a rule that allows or denies partial access rights. For example, you could allow users read-only access rights to your files so they can view the information but not change the files.
The following elements are displayed for Rights on the Access Control Rules For page in the user interface.
All Access Rights is the default and allows or denies all rights.
Only The following Rights enables you to select a combination of rights to be allowed or denied:
Read permits users to view files, including the HTTP methods GET, HEAD, POST, and INDEX.
Write permits 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 permits users to execute server-side applications, such as CGI programs, Java applets, and agents.
Delete permits users who also have write privileges to delete files or directories.
List permits users to access lists of the files in directories that do not contain an index.html file.
Info permits users to receive information about the URI, for example http_head.
You can enter custom expressions for an ACL. Select this option only if you are familiar with the syntax and structure of ACL files. A few features are 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:00 am to 5:00 pm. 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 about valid syntax and ACL files, see Chapter 18, ACL File Syntax.
When you deselect the option labeled Access Control Is On on the Access Control Rules For page, you receive a prompt asking whether you want to erase records in the ACL. When you click OK, the ACL entry for that resource is deleted from the ACL file.
If you want to deactivate an ACL, comment out the ACL lines in the file generated-proxy-serverid.acl by using # signs at the start of each line.
From the Administration Server, you could create and turn on access control for a specific server instance and leave it off (the default) for other servers. For example, you could deny all access to the Server Manager pages from the Administration Server. With distributed administration on and access control off by default for any other servers, administrators could still access and configure the other servers, but could not configure the Administration Server.
The Proxy Server provides a default message when access is denied, and you can customize the response if desired. You can also create a different message for each access control object.
By default, for the Administration Server, users receive the Permission Denied message in server-root/httpacl/admin-denymsg.html.
Click the Response When Denied link on the Access Control Rules For page.
Select the desired response, provide additional information if appropriate and then click Update. Make sure users have access to the response to which they are redirected.
Click Submit to save your changes, or Revert to reset the elements in the page to the values they contained before your changes.