Figure 4-1: Custom Object Model for Banking Application
[Previous] [Next] [Contents] [Index]
The NetCrusader/Web Authorization Object feature depends on two files: the object definition file and the ACL definition file. This chapter describes the purpose of these files and how to create them. It includes the following sections:
4.2 Understanding Object Models
4.3 Object Definition File
4.4 Understanding ACL Models
4.5 ACL Definition File
4.6 Next Steps
4.1 Overview of Model Files
Before you begin scripting or coding, you must decide whether you will:
NOTE:
Before you start, you need to know the name of the directory in which
the NetCrusader/Web Security Adapter is installed so that you can store the
model files in the correct directory. You must have write permission to that
directory or must have a system administrator store the files in that directory
for you once you have created them.
4.2 Understanding Object Models
An object model describes the structure of resources for which access will be authorized. In the NetCrusader/Web Authorization Object environment, the object model describes the structure of objects in a project, application, object, or any virtual system that will use the Authorization Object.
4.2.1 Default and Custom Object Models
The object model is organized as a hierarchical tree, at the root of which is the root object. The default object model describes only the structure of the root object and all other objects are assumed to inherit their permissions from the root, unless the permissions are explicitly overridden.
You can work with the default object model or define a custom object model, describing objects that exist under the root object. You can define an arbitrarily deep hierarchy of objects. By defining your own object model, you can represent any real or conceptual objects that exist in your web application, and then apply access control to these objects.
4.2.2 Object Model Structure
Throughout this document we refer to sample applications to illustrate how to use the NetCrusader/Web Authorization Object. The description of the sample application which follows starts to describe the object model structure for the application.
For our banking application we choose to use a custom object model. We define a directory object, under root, named Banking, which contains the leaf node objects Savings, Checking, Money Market, and so on, as illustrated in Figure 4-1.
Figure 4-1: Custom Object Model for Banking Application
This definition of the objects in the banking application is our object model. (We could also define subdirectories to further partition the object model, if desired.) Because we are describing objects under the root, we are defining a custom object model.
4.3 Object Definition File
You use the object definition file to specify a custom object model to be used in your application. If you are using the default object model, you do not need to create this file.
4.3.1 Object Definition File Syntax
The file begins with a
<MODEL> tag and ends with a </MODEL> tag.
You use
<OBJ> and <DIR> tags to define object nodes and directory nodes, respectively.
The attribute names within a tag, however, are case-sensitive. For example, in the following example for the sample banking application, the attributes Checking, Savings, and Money Market are case sensitive.
The object definition file for the banking application introduced in Section 4.2 is as follows:
<MODEL>
<OBJ Name="Checking"/>
<OBJ Name="Savings"/>
<OBJ Name="Money Market"/>
/MODEL>
The
<MODEL> tag starts the object model specification block, and </MODEL> ends it.
You begin a directory specification with the <DIR> tag and close it with the</DIR> tag. Objects and directories specified between the open and close directory tags are contained within that directory. The object model specified in Example 2 would have a hierarchical structure as shown in Figure 4-2.
Figure 4-2: Object Model Tree for Banking Example 2
4.3.3 Saving the Object Definition File
<install_dir>\model\<model_name>\object.txt
The <model_name> is the name that you provide as the name of your web application when you call the InitModel function. See Chapter 3 for more details on initializing the Authorization Object.
For example, in our sample banking application, we use Bank as the
application name.
NOTE:
The object definition file and the ACL definition file must exist as a
pair; that is, there must be one of each for each model.
4.4 Understanding ACL Models
NetCrusader security features a default ACL model, which any application can use. The default NetCrusader ACL model applies to all objects by default.The default ACL model automatically gives you the permissions listed in Table 4-1.
| Symbol | Name |
|---|---|
|
c
|
ACL Control
|
|
t
|
ACL Test
|
|
I
|
Inherited ACL
|
|
D
|
Delete Explicit ACL
|
The default model also includes the permissions in Table 4-2. These permissions are not available automatically in custom models. That is, if you want to use any of the permissions in this table, you must define them.
| Symbol | Name |
|---|---|
|
l
|
List
|
|
r
|
Read
|
|
w
|
Write
|
|
x
|
Execute
|
|
T
|
Traverse (for directories or containers)
|
Custom models replace the default ACL model. If you want to use any of the pre-defined permissions (listed in Table 4-2), 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).
For example, in our sample banking application, appropriate permissions might include Deposit, Withdraw, Check Balance, Transfer, Create Account, Close Account, Hold Check, and so on.
4.5 ACL Definition File
If you choose to define a custom ACL model, you must create an ACL definition file. The ACL definition file is where you define the set of application-specific actions whose access is to be controlled (permissions) and the default permissions (default rights) granted to a group or individual.
Some examples of application-specific actions for the sample banking application are Deposit, Withdraw, Check Balance, Transfer, Create Account, Close Account, Hold Check, and so on. The groups for our banking application might include customers, tellers, and so on.
4.5.1 When the ACL Definition File is Used
The ACL file is not used again unless you delete the permission store (the ACL database). Any edits you make to the ACL change the ACL database.
4.5.2 ACL Definition File Syntax
Like the syntax for the object definition file, the syntax for the ACL definition file follows the XML syntax standard for "well-formed" XML, the simplest form of XML, requiring no DTD (Section 4.3.1 on page 45).
Any line whose leading character is not < is treated as a comment line. You cannot break lines.
4.5.3 Structure of the ACL Definition File
The ACL file starts with a <ACLModel> tag and ends with an </ACLModel> tag. It contains two blocks: one for defining the permission set (
<PERMS>) and one for defining the default ACL model (<DEFAULT>).
The following is an example of the ACL definition file for the sample banking application.
</ACLModel>
4.5.3.1 The <perms> Block
<PERM> tag begins the permission definition section.
syb attribute associates a one-character symbol with a permission type.
name attribute gives a meaningful description to the permission type.
<perm syb='a' name="Add Account" />
The valid permissions are a-z and A-Z. However, four permissions are reserved by the underlying authorization library (see Table 4-1 on page 48). These permissions are automatically created in every model. Do not use the symbols (one-character abbreviations) of these permissions for your custom permissions.
For example, the following line gives the
service group a, x, d, w, and v permissions:
<DEFACL Type="group" Id="service" Permissions="axdwv" />
<defAcl type="group" id="wccs-admin" permissions="ct" />
NOTE:
At least one user must always have control (c) and ACL test (t)
permission. If the only user with these permissions is deleted, you will not be
able to edit ACLs.
4.5.4 Creating the ACL Definition File
<install_dir>\model\<Model Name>\acl.txt
The <Model Name> is the name of your model. This is the name that you provide as the name of your web application when you call the InitModel function. See Chapter 3 for more details on initializing the Authorization Object.
NOTE:
The object definition file and the ACL definition file must exist as a
pair; that is, there must be one of each for each model.
In our sample banking application, we use Bank as the application name. We would save the file as:
<install_dir>\model\Bank\acl.txt
4.6 Next Steps
After creating the object definition file and ACL model file (if required), you are ready to develop your application. Chapter 2 describes this process.
[Previous] [Next] [Contents] [Index]
To make comments or ask for help, contact support@entegrity.com.