You need to know the syntax and function
of ACL files if you plan on customizing access control using the access-control
API. For example, you might use the access control API to interface with
another database, such as an Oracle or Informix database. For more information
on the API, see the DevEdge site at:
http://developer.netscape.com/library/documentation/index.html.
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:
acl "path=C:/Netscape/SuiteSpot/docs/mydocs/";
acl "*.html";
acl "default";
acl "uri=/mydocs/";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.
Init fn=acl-set-default-method method=SSLEach 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:
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 username begins with the letters sales:
authenticate (user) allow (all) user = sales*If the last line was changed to group = sales, then the ACL would fail because there are no groups in the user lists.
allow|deny [absolute] (right[,right...]) attribute expression;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:
deny (all) user = "anyone";
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.
version 3.0; acl "default"; authenticate (user,group) {
prompt="Enterprise Server"; }; allow (read,execute,list,info) user = "anyone"; allow (write,delete) user = "all";
acl "*.html"; deny absolute (all) user = "anyone";
acl "uri=/my_stuff/web/presentation.html"; deny (all) user = "anyone"; allow (all) user = "anyone";
NoteUse 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.
allow (read) (group="guests") and (timeofday<800 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 get access all day on weekends and on weekdays anytime except 8am-4:59pm.
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");
The following text is from the default file:
# File automatically written # # You may edit this file by hand # version 3.0; acl "agents"; authenticate (user,group) { prompt = "Enterprise Server"; }; deny (all) user = "anyone" allow absolute (all) user = "all"; acl "default"; allow (read,execute,list,info) user = "anyone"; allow (write,delete) user = "all";The default ACL file is referenced in magnus.conf as follows:
ACLFile absolutepath/generated.https-serverid.acl
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 Server Manager forms to do some access control, the first ACL file in magnus.conf should point to the file generated.https-serverid.acl. See Referencing ACL files in obj.conf for more information.
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 (see the dayofweek example).
PathCheck fn="check-acl" acl="aclname"
The aclname is a unique name of an ACL as it appears in any ACL file.
For example, you might add the following lines to your obj.conf file if you want to restrict access to a directory using the acl named testacl:
<Object ppath="/usr/ns-home/docs/test/*"> PathCheck fn="check-acl" acl="testacl" </Object>In the previous example, the first line is the object that states which server resource you want to restrict access to. The second line is the PathCheck directive that uses the check-acl function to bind the name ACL (testacl) to the object in which the directive appears. The testacl ACL can appear in any ACL file referenced in magnus.conf.