Chapter 18 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 Chapter 8, Controlling Access to Your Server. Resource templates are supported in the Proxy Server 4 release, as described in Chapter 16, Managing Templates and Resources.

This appendix contains the following sections:

• About ACL Files and ACL File Syntax

• Referencing ACL Files in the obj.conf File

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 a single syntax version number. For example:

version 3.0;

There version line 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: path, resource, or named.

• Path ACLs specify an absolute path to the resource they affect.

• Resource ACLs specify the template they affect, such as http://, https://, ftp://, and so on. For more information about templates, see Chapter 16, Managing Templates and Resources.

• Named ACLs specify a name that is referenced in resources in the obj.conf file. The server comes with a default named resource that allows read access to anyone, and write access to users in the LDAP directory. Even though a named ACL can be created from the Proxy Server user interface, you must manually reference the named ACLs with resources in the obj.conf file.

Path and resource ACLs can include wildcards. For more information about wildcards, see Chapter 16, 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 authentication statements that define the method used with the ACL. You also can include authorization statements to define the people and computers who are allowed or denied access. The following sections describe the syntax for these statements.

Authentication Statements

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

• Basic (default)

• Digest

• SSL

The Basic and Digest methods require the user to provide 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 the server authenticates: users, groups, or both users and groups. 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. Because of the hierarchy of rules, deny access to everyone in the first rule and then specifically allow access for users, groups, or computers in subsequent rules. For example, 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

The hierarchy in ACLs 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="iPlanet 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 show how access might be granted to different people or computers:

• user = "anyone"

• user = "smith*"

• group = "sales"

• dns = "*.mycorp.com"

• dns = "*.mycorp.com,*.company.com"

• ip = "198.*"

• ciphers = "rc4"

• ssl = "on"

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 a.m. or 2230 for 10:30 p.m. The following example restricts access to a group of users called guests between 8:00 a.m. and 4:59 p.m.

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 a.m. through 4:59 p.m.

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

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:

• and

• or

• not

• = (equals)

• != (not equal to)

The following operators can be used with timeofday and dayofweek:

• greater than

• < less than

• = greater than or equal to

• <= less than or equal to

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:

• Letters a through z

• Numbers 0 through 9

• Period and underscore

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 the obj.conf File

Named ACLs or separate ACL files can be referenced in the obj.conf file 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"</Object>

In this 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.