Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Web Proxy Server 4.0.1 Administration Guide 

Appendix A
ACL File Syntax

Access control list (ACL) files are text files containing lists that define who can access Proxy Server resources. By default the Proxy Server uses one ACL file that contains all of the lists for access to your server. Multiple ACL files can also be created and referenced in the obj.conf file.

Proxy Server 4 uses a different ACL file syntax than was used in Proxy Server 3.x. This appendix describes ACL files and their syntax. For detailed information about controlling access to your Proxy Server and its resources, see Controlling Access to Your Server. Resource templates are supported in the Proxy Server 4 release, as described in Managing Templates and Resources.

This appendix contains the following sections:

About ACL Files and ACL File Syntax

All ACL files must follow a specific format and syntax. An ACL file is a text file containing one or more ACLs. All ACL files must begin with the syntax version number. For example:

version 3.0;

There can be only one version line and it can appear after any comment lines. Proxy Server uses syntax version 3.0. Comments can be included in the file by using the # symbol at the start of the comment line.

Each ACL in the file begins with a statement that defines its type. ACLs can be one of three types:

Path and resource ACLs can include wildcards. For more information about wildcards, see Managing Templates and Resources.

The type line begins with the letters acl and then includes the type information in double quotation marks, followed by a semicolon. For example:

acl "default";
acl "http://*.*";

Each type information for all ACLs must be a unique name, even among different ACL files. After you define the type of ACL, you can have one or more statements that define the method used with the ACL (authentication statements) and the people and computers who are allowed or denied access (authorization statements). The following sections describe the syntax for these statements.

This section contains the following topics:

Authentication Statements

ACLs can optionally specify the authentication method the server must use when processing the ACL. There are three general methods:

The Basic and Digest methods require the user to enter a user name and password before accessing a resource.

The SSL method requires the user to have a client certificate. To be authenticated, encryption must be turned on for the Proxy Server, and the user’s certificate issuer must be in the list of trusted CAs.

By default, the server uses the Basic method for any ACL that does not specify a method. Your server’s authentication database must support Digest authentication sent by a user.

Each authenticate line must specify what attribute (users, groups, or both users and groups) the server authenticates. The following authentication statement, which would appear after the ACL type line, specifies Basic authentication with users matched to individual users in the database or directory:

authenticate(user) {
    method = "basic";

The following example uses SSL as the authentication method for users and groups:

authenticate(user, group) {
    method = "ssl";

The following example allows any user whose user name begins with the word sales:

allow (all) user = "sales*";

If the last line is changed to group = sales, then the ACL would fail because the group attribute is not authenticated.

Authorization Statements

Each ACL entry can include one or more authorization statements. Authorization statements specify who is allowed or denied access to a server resource.

Writing Authorization Statements

Use the following syntax when writing authorization statements:

allow|deny [absolute] (right[,right...]) attribute expression;

Start each line with either allow or deny. It is usually a good idea to deny access to everyone in the first rule and then specifically allow access for users, groups, or computers in subsequent rules. This is because of the hierarchy of rules. That is, if you allow anyone access to a directory called /my_files, and allow a few users access to the subdirectory /my_files/personal, the access control on the subdirectory will not work because anyone allowed access to the /my_files directory will also be allowed access to the /my_files/personal directory. To prevent this, create a rule for the subdirectory that first denies access to anyone, and then allows access for the few users who need it.

In some cases, however, if you set the default ACL to deny access to everyone, your other ACL rules do not need a "deny all" rule.

The following line denies access to everyone:

deny (all) user = "anyone";

Hierarchy of Authorization Statements

ACLs have a hierarchy that depends on the resource. When the server receives a request for a specific resource, it builds a list of ACLs that apply for that resource. The server first adds named ACLs listed in check-acl statements of its obj.conf file. It then appends matching path and resource ACLs. This list is processed in the same order. Unless "absolute" ACL statements are present, all statements are evaluated in order. If an "absolute allow" or "absolute deny" statement evaluates to "true," the server stops processing and accepts this result.

If more than one ACL matches, the server uses the last statement that matches. However, if you use an absolute statement, then the server stops looking for other matches and uses the ACL containing the absolute statement. If you have two absolute statements for the same resource, the server uses the first statement in the file and stops looking for other resources that match.

version 3.0;
acl "default";
authenticate (user,group) {
  prompt="Sun Java System Web Proxy Server";
allow (read,execute,list,info) user = "anyone";
allow (write,delete) user = "all";

acl "http://*.*";
deny (all) user = "anyone";
allow (all) user = "joe";

Attribute Expressions

Attribute expressions define who is allowed or denied access based on their user name, group name, host name, or IP address. The following lines provide examples of how access might be granted to different people or computers:

You can also restrict access to your server by time of day (based on the local time on the server) by using the timeofday attribute. For example, you can use the timeofday attribute to restrict access to certain users during specific hours.

Use 24-hour time to specify times, such as 0400 to specify 4:00 am or 2230 for 10:30 pm. The following example restricts access to a group of users called guests between 8:00 am and 4:59 pm:

allow (read)
    (group="guests") and
    (timeofday<0800 or timeofday=1700);

You can also restrict access by day of the week. Use the following three-letter abbreviations to specify days of the week: Sun, Mon, Tue, Wed, Thu, Fri, and Sat.

The following statement allows access for users in the premium group any day and any time. Users in the discount group have access all day on weekends, and anytime on weekdays except 8 am-4:59 pm.

allow (read) (group="discount" and dayofweek="Sat,Sun") or 
(group="discount" and (dayofweek="mon,tue,wed,thu,fri" and
(timeofday<0800 or timeofday=1700)))

Operators for Expressions

Various operators can be used in attribute expressions. Parentheses delineate the operator order of precedence. The following operators can be used with user, group, dns, and ip:

The following operators can be used with timeofday and dayofweek:

The Default ACL File

After installation, the server_root/httpacl/generated.proxy-serverid.acl file provides default settings for the server. The server uses the working file genwork.proxy-serverid.acl until settings are created in the user interface. When editing an ACL file, you could make changes in the genwork file, then save and apply the changes using the Proxy Server.

General Syntax Items

Input strings can contain the following characters:

For other characters, double quotation marks must be used around the characters.

A single statement can be placed on its own line and terminated with a semicolon. Multiple statements are placed within braces. A list of items must be separated by commas and enclosed in double quotation marks.

Referencing ACL Files in obj.conf

Named ACLs or separate ACL files can be referenced in the obj.conf file. This is done in the PathCheck directive using the check-acl function. The line has the following syntax:

PathCheck fn="check-acl" acl="aclname"

where aclname is the unique name of an ACL as it appears in any ACL file.

For example, you might add the following lines to the obj.conf file to restrict access to a directory using the ACL named testacl:

<Object ppath="https://"
PathCheck fn="check-acl" acl="testacl"

In the previous example, the first line is the object that states the server resource to which you want to restrict access. The second line is the PathCheck directive that uses the check-acl function to bind the named ACL (testacl) to the object in which the directive appears. The testacl ACL can appear in any ACL file referenced in server.xml.

Previous      Contents      Index      Next     

Part No: 819-3650-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.