3 — Understanding NetCrusader/Web ACLs

[Previous] [Next] [Contents] [Index]

This chapter describes NetCrusader/Web Access Control Lists (ACLs), the default ACL model, and access permissions. It contains the following sections:

3.1 The ACL Model
3.2 Access Control Lists
3.3 A Closer Look at ACLs

3.1 The ACL Model

An ACL model is the set of permissions for operations associated with a set of objects. For example, read, write, and execute are permissions normally associated with files.

3.1.1 The Default ACL Model

By default, NetCrusader has eleven pre-defined permissions. This set of eleven pre-defined permissions is called the default ACL model. Any application or extension can use the default ACL model. For example, you can use Commander to create users and groups and then set permissions for documents on your web server using permissions from the default ACL model. Without any special programming, you have just set up access control on your web server.

Table 3-1 lists the permissions in the default ACL model.

Table 3-1: Default ACL Model Permissions

Abbreviation	Permission	Allows a User to...
r	read	Read an object using the GET or HEAD HTTP method.
w	write	Write to an object using the PUT or POST HTTP method.
x	execute	Execute a program or script specified by a URL. A user must have this permission to view an Active Server Page. Execute permission has no special meaning for directories. Traverse is used to allow access through a directory to objects contained within that directory.
c	control	Modify the ACL on an object.
t	test	View an ACL on an object.
m	unused	This permission supports future functionality.
u	unused	This permission supports future functionality.
l	list	Create and read an HTML directory index. Also requires that this function be enabled in the web server.
I	Inherited ACL	Specify that the object should obtain its ACL from the parent object. This permission simply indicates whether this is an explicit or inherited ACL. You cannot convert an explicit ACL to an inherited ACL by enabling this permission. To create an inherited ACL, delete the explicit ACL by enabling the Delete permission (see below).
D	Delete Explicit ACL	Delete an ACL. If you are using one of the command line tools (such as acl_edit), you enable the Delete permission on the user_obj ACL entry of an explicit ACL to delete it. Deleting an explicit ACL converts it into an inherited ACL. You cannot delete an inherited ACL.
T	Traverse	Traverse this container during sparse ACL evaluation.

However, the real strength of NetCrusader/Web is that you can create a custom ACL model and define your own set of operations for any object.

3.1.2 Custom ACL Models

In addition to the default ACL model, you can define your own custom ACL models. If you define a custom ACL model, you can define permissions specific to your application.

Custom models replace the default ACL model. If you want to use any of the pre-defined permissions (listed in Table 3-3), you must define them yourself. For example, if you are creating a custom ACL model and want to use r, w, or x, you must define these permissions in your custom model.

To create a custom ACL model, you create a text file that defines the permissions for the model as well as the model's scope (portion of the object tree protected by this model).

The default NetCrusader ACL model applies to all objects by default.The default ACL model automatically gives you the permissions listed in Table 3-2.

Table 3-2: Default ACL Model Permanent Automatic Permissions

Symbol	Name
c	control
t	test
I	Inherited ACL
D	Delete Explicit ACL

These four reserved permissions are available permanently, even when you define a custom model.

The default model also includes the permissions in Table 3-3. However, when you create a custom model, these permissions are not available automatically.

Table 3-3: ACL Model Automatic Permissions

Symbol	Name
l	list
r	read
w	write
x	execute
T	Traverse (for directories or containers)

3.1.2.1 Providing Unauthenticated Access in Custom ACL Models

If you turn off Security Adapter authorization, the Security Adapter refuses all unauthenticated requests. If you want your application to grant any level of access to unauthenticated users, but you do not want the Security Adapter to perform any access checking, enable Security Adapter authorization but modify the root ACL to enable free access to the any_other and unauthenticated users (For information about the any_other and unauthenticated users, refer to Section 3.3). Then program the application to perform all desired ACL checking.

3.2 Access Control Lists

While the ACL model describes the permissions available for a set of objects, the ACL itself specifies which permissions in the ACL model an entity has.

For example, the ACL model may indicate that an object has read, write, and execute permissions associated with it, but a particular user might have only read and execute permission. In this example, read and execute comprise the ACL for that user.

NetCrusader ACLs are similar to the file permission mechanisms provided by operating systems and web servers, but provide finer-grained access control because you can control access to any object for which the server provides access. Examples include a static HTML document, a directory, a server extension, a field in a database record, or a downstream extension or application. The actual objects protected in an application depend on the application.

3.2.1 Explicit ACLs Versus Inherited ACLs

An explicit ACL (sometimes called a real ACL) sets the access permissions for an object, and in the case of an object that is a container, it also sets the access permissions for the objects contained in that container. An object inherits its ACLs from the explicit ACL above it in the tree structure unless you specifically apply an explicit ACL to the object.

With ACL inheritance, you do not need to create an ACL for every object to which a server provides access. You can apply a single ACL and allow the objects beneath it to inherit that ACL.

Figure 3-1 uses documents and directories as an example to illustrate how explicit and inherited ACLs work.

Figure 3-1: Explicit ACLs

In Figure 3-1:

• ACL 1 applies permissions to the DOCS directory.

• ACL 2 applies permissions to the users.htm file.

• ACL 3 applies permissions to the PRIVATE directory.

The ACLs in the figure are shaded differently to show that each ACL grants a different set of access permissions to its target object. You can see from the shading that the objects contained in an object associated with an explicit ACL inherit their access permissions from the explicit ACL.

For example, ACL 1 applies permissions explicitly to the DOCS directory. The files under the DOCS directory would normally inherit the permissions of ACL 1 so that the permissions of ACL 1 would protect all the files under DOCS (index.htm, users.htm, the PUBLIC directory, products.htm, and so on). The chain of inheritance continues through all objects lower down in the tree and stops when it encounters an explicit ACL. Since there is an explicit ACL applied to users.htm (ACL 2), users.htm does not inherit its ACL.

Likewise ACL 3 is an explicit ACL on the PRIVATE directory. Since the PRIVATE directory is a subdirectory of DOCS, normally PRIVATE would inherit its ACL from DOCS. However, the explicit ACL (ACL 3) stops the chain of inheritance from ACL 1.

You use NetCrusader Commander to view and modify ACLs. When you change an explicit ACL, your changes are automatically and immediately applied to all inheriting ACLs. When you view an inherited ACL using Commander, you see the permissions of the explicit ACL from which the viewed ACL inherits.

3.2.2 The Default Root ACL

Initially all objects inherit their permissions from the root ACL; that is, the ACL at the top of the object tree. The default root ACL protects the object tree and applies until you modify it or apply explicit ACLs at other points in the tree.

3.2.3 ACL Storage

When storing ACLs, NetCrusader uses a sparse ACL mechanism. Using a sparse ACL mechanism makes NetCrusader ACL handling more efficient.

In a sparse ACL mechanism, the actual ACL is not stored for objects which inherit their ACLs.

An explicit ACL, however, is stored in the NetCrusader ACL database file. The ACL database file is located on the same system as the web server, in <installation_directory>/netc_authz/<server name>.

3.3 A Closer Look at ACLs

This section looks more closely at ACLs. An ACL contains the permissions that are enabled for a specific user, group of users, or special object. A common example would be an ACL of r, w, x (read, write, and execute) for a user.

Table 3-4 shows a sample set of ACLs for an object. This example uses the pre-defined permissions of the default ACL model.

Table 3-4: ACL Entry Example

Entry	Entry Type	Name	Enabled Permissions
1	user	alice	r w x T
2	group	employees	r w T
3	group	wccs-admin	r w x m u l T c t
4	any_other		r T
5	unauthenticated		r

The following describes the entries:

• user — Lists permissions for a specific user. You create users with Commander.

  The ACL entry (1) above shows the permissions for the user named Alice. In the example, Alice has read (r), write (w), execute (x), and traverse (T) permissions for the associated object.

  Another type of user entry (not shown) is the foreign_user entry. This entry would describe the permissions granted to specific users from outside the local security domain.

• group — Lists the permissions for a specific group of users. You create groups using Commander. Groups provide a convenient way to control access for a set of users with the same security requirements.

  NetCrusader/Web creates the wc-filters, wc-delegates, wccs-admin, and wc-servers groups automatically during configuration. For more information on these groups, see the NetCrusader/Web Installation and Operation Guide

  Another type of group entry (not shown) is the foreign_group entry. This entry would describe the permissions granted to specific groups from outside the local security domain.

• any_other — The any_other entry (4) is a special NetCrusader group that defines the permissions for users who are not covered by any of the user or group entries.

• unauthenticated — If a user categorized as any_other is also unauthenticated, the NetCrusader security server determines the permissions for the user by applying the unauthenticated entry (5) as an AND mask to the any_other entry.

All of the entries in the table together make up the ACL for the object.

Example

Using the ACLs shown in Table 3-4 on page 32, let us look at what happens if user Robert attempts to access the object protected by this ACL. The server authenticates Robert but determines that he is not listed in the ACL as a user and is not a member of any group listed in the ACL. The server grants Robert the access defined for the any_other permissions (read and traverse).

Now suppose a user named Susan, who has no NetCrusader identity, attempts to access this object. Because Susan is not listed in the ACL as a user and is not a member of any group listed in the ACL, the server classifies her as any_other. However, because Susan is unauthenticated, the server applies an AND mask to the unauthenticated controls and the any_other controls, resulting in read-only access.

3.3.1 ACL Entries for the Default Root ACL

The default root ACL for the default ACL model contains the entries shown in Table 3-5.

Table 3-5: Entries in the Default Root ACL

Entry Type	Name	Enabled Permissions1
unauthenticated		r T
group	wccs-admin2	r w x m u l T c t
any_other		r T

1 See Table 3-1 on page 27 for definitions. 2 The wccs-admin group is for users who will be managing NetCrusader users, groups, and ACLs.

The default root ACL for a server is named <sec_domain_name>/subsys/WWW/netcacl-<hostname>.

The default root ACL for a custom ACL model is named <sec_domain_name>/subsys/WWW/netcacl-<hostname>/app_name.

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Copyright © 1996-2002 Entegrity Solutions Corporation & its subsidiaries