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 version number they use. There can be only one version line and it can appear after any comment lines. For example:
You can include comments in the file by beginning the comment line with the # sign.
Each ACL in the file begins with a statement that defines its type. ACLs can follow one of three types:
The type line begins with the letters acl and then includes the type information in double-quotation marks followed by a semicolon. Each type information for all ACLs must be a unique name--even among different ACL files. The following lines are examples of several different types of ACLs:
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.
Authentication Statements
ACLs can optionally specify the authentication method the server must use when processing the ACL. There are two general methods:
By default, the server uses the Basic method for any ACL that doesn't specify a method.
Each authenticate line must specify what list (users, groups or both) the server should use when authenticating users. 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:
The following example uses SSL as the authentication method for users and groups:
The following example allows any user whose username begins with the letters sales:
If the last line was changed to group = sales, then the ACL would fail because there are no groups in the user lists.
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. Use the following syntax when writing authorization statements:
Start each line with either allow or deny. It's 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_stuff, and then you have a subdirectory /my_stuff/personal that allows access to a few users, the access control on the subdirectory won't work because anyone allowed access to the /my_stuff directory will also be allowed access to the
/my_stuff/personal directory. To prevent this, create a rule for the subdirectory that first denies access to anyone and then allows it for the few users who need access.
However, in some cases if you set the default ACL to deny access to everyone, then your other ACL rules don't need a "deny all" rule.
The following line denies access to everyone:
Hierarchy of Authorization Statements
ACLs have a hierarchy that depends on the resource. For example, if the server receives a request for the document (URI)
/my_stuff/web/presentation.html, the server first looks for an ACL that matches the file type or any other wildcard pattern that matches the request, then it looks for one on the directory, and finally it looks for an ACL on the URI. If there are more than one ACLs that match, 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 one in the file and stops looking for other resources that match.
For example, using the ACL hierarchy with the request for the document
/my_stuff/web/presentation.html, you could have an absolute ACL that restricts access to the file type *.html. Then the server would use that ACL instead of looking for one that matches the URI or the path.
Attribute Expressions
Attribute expressions define who is allowed or denied access based on their username, group name, host name, or IP address. The following lines are examples of allowing access 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.
Note
Use 24-hour time to specify times (for example, use 0400 to specify 4 a.m. or 2230 for 10:30 p.m.).
The following example restricts access to a group of users called guests between 8 a.m. and 4:59 pm.
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 get access all day on weekends and on weekdays anytime except 8am-4:59pm.
Operators For Expressions
You can use various operators in attribute expressions. You can use parentheses to delineate the order of precedence of the operators. With user, group, dns, and ip,
you can use the following operators:
With timeofday and dayofweek,
you can use the following additional operators:
The Default ACL File
After installing the server, the server uses the default settings in the file server_root/httpacl/generated.https-serverid.acl. There is also a file called genwork.https-serverid.acl that is a working copy the server uses until you save and apply your changes when working with the user interface. When editing the ACL file, you might want to work in the genwork file and then use the iPlanet Web Server to save and apply the changes.
The following text is from the default file:
The default ACL file is referenced in magnus.conf as follows:
You can reference multiple ACL files in magnus.conf and then use their ACLs for resources in obj.conf. However, the server uses only the first ACL file with the web publisher and when evaluating access control for objects that don't have specific ACLs listed in obj.conf. If you're using the iPlanet Web Server windows to do some access control, the first ACL file in magnus.conf should point to the file
generated.https-serverid.acl. See the section
Referencing ACL Files in obj.conf, for more information.
General Syntax Items
Input strings can contain the following characters:
If you use any other characters, you need to use double-quotation marks around the characters.
A single statement can be placed on its own line and be 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.
|
Previous
