Defining iChain Access Control Rules

After a user has logged in, Access Control List (ACL) rules control what resources the user can access. By default, the user has access to nothing. Only those resources explicitly listed in your ACL rules (specified by the URL) can be accessed by the organizations, organizational units, groups, or users listed in the Apply To list for the rule. Whenever possible, it is recommended that you use the highest-level object in the list of allowed users, making it easier and faster to configure an ACL rule.

iChain access control checks the ACL rules in the following sequence:

• Rules for all the user's containers, starting with the highest level container
• Rules for all communities of all the user's containers (if ACLCHECK was started using the /m option)
• Rules for the user's groups
• Rules for all communities of the user's groups (if ACLCHECK was started using the /m option)
• Rules for the user
• Rules for all communities of the user (if ACLCHECK was started using the /m option)

When a user tries to access a protected resource that has been defined as Public, the user is immediately granted access. If the resource is defined as Restricted, the iChain system checks the user's browser cookie address to see if he or she is a currently authenticated user and either lets the user access the resource if the user is authenticated or prompts the user for authentication. A current authenticated connection is all that is required. However, when a user attempts to access a URL that has been defined as Secure, the user must log in to eDirectory and provide a password. When the user is authenticated, the ACL rules are checked to see if the user is allowed to access the site.

ACL rules allow the use of an asterisk (*) or question mark (?) as wildcard characters when specifying URLs. The asterisk indicates that the user can have access to the folder contents and all subfolders. The question mark indicates the user can have access to the folder contents, but not the subfolders. Also, each ACL rule can be individually disabled or enabled, allowing you to turn on or off a particular rule for a time without losing its parameter settings.

ACL rules are stored in a cache that is updated periodically at a configurable interval. For performance reasons, the recommended cache refresh interval is three to six hours. If you make changes or additions to the ACL rules and want the cache to be updated immediately, use the manual Refresh option available in the Configure > Access Control tabs of the iChain Proxy Services Browser-based administration tool. If you have FTP enabled on the proxy, you can automatically refresh the iChain proxy when prompted by the snap-in.

When you create an entry in the URL list of an ACL rule, at least one of the two fields (Resource Name and URL) is required.

If only the URL is specified, it must be given as an absolute URL (for example, http://www.novell.com/index.html, not /index.html). The URL may contain wildcards. The ACL rule will match any request for the URL (including wildcards).

If only the Resource Name is specified, the ACL rule will match any request for the exact path of the Resource Name. For example, if the protected resource myserver has been defined as http://www.novell.com, and a URL list entry is created with myserver as the Resource Name and with no URL, then the ACL rule will apply to the http://www.novell.com URL only.

If both the Resource Name and the URL are specified, the URL must be given as a relative URL (/index.html, not http://www.novell.com/index.html) and may include wildcards. The ACL rule will match requests for the combined Resource Name and URL, including wildcards. For example, if the Resource Name is myserver and the URL is /documentation/*, then the ACL rule will apply to http://www.novell.com/documentation/*.

To create a new ACL rule for iChain:

1. From ConsoleOne, select File > New > New Object.

   or

   Click the New iChain Object icon.

2. Select ACL Rule > click OK.

3. Define a name for the rule > click OK.

4. Select the rule you just created and click Properties > Access Control.

5. Under the list of Allowed URLs, click Add > define a name and URL for a resource that this rule will control access to.

   You can use an asterisk (*) or question mark (?) as a wildcard character when specifying URLs. The asterisk indicates that the user can have access to the folder contents and all subfolders. The question mark indicates the user can have access to the folder contents, but not the subfolders.

6. Under the Apply To List, click Add to browse to and select the Os, OUs, groups, and users to which this rule applies.

   The Os, OUs, groups, and users in the Apply to List are allowed access to the listed URLs.

7. Under the Exception List, click Add to browse to and select the Os, OUs, groups, and users that are exceptions to this rule.

   The Os, OUs, groups, and users in the Exceptions List are a subset of the Apply to List and are objects that are denied access to the listed URLs.

8. To enable the ACL rule, check the Enable Access Control check box at the General tab.

9. To disable the ACL rule and save it for later use, uncheck the Enable Access Control check box.

ACL Exceptions

You can exclude certain users or group members listed in the Apply To List that you do not want to have access to the specified URLs. However, these exceptions are made on a per rule basis. So, although a user may be excluded from one rule, he may still have access to the URL through other ACL rules. Double-check all ACL rules for the resource to be sure exceptions are as you expect.

You can also define a subset of the destination URL as an exception for an ACL rule. For example, an ACL rule could be set on http://ichain.novell.com/* for the users in the o=novell container. By using the URL exception feature, an administrator could define http://ichain.novell.com/private/* as a URL exception. iChain access control would then allow the users in the o=novell container to go to all the pages under http://ichain.novell.com/, except http://ichain.novell.com/private/.

ACL Theory of Operations

The following is an example that explains the process of ACLs:

Table 1. ISO Protected Resource

Table 2. ACL Access Control

1. At the browser, Jack enters: http://www.novell.com/secret.
2. DNS points Jack's browser to the iChain box.
3. The iChain box has a Web Accelerator with www.novell.com defined and the Enable Authentication switch is turned on. (If the switch was not turned on, iChain would simply cache the resource and would provide no security).
4. The ISO entries are compared to the URL request to determine if authentication is required.
5. Jack is asked to enter his name and password for authentication. It is valid.
6. Completion of the initial URL compare takes place.
   • A --- Serves up only the index.html or the default.html. No match.
   • B --- The asterisk (*) indicates everything in the doc root directory and everything in every subordinate directory. Match.
   • C --- The asterisk (*) in this protected resource has two meanings: any HTML extension-based file in the doc root directory and all subordinate directories. Match.
   • D --- Similar to C, but any .GIF-based file in the document root directory and below. No match.
   • E --- Similar to A, but this one matches the URL Jack entered.

   Notice the types of protected resources: Public, Restricted, and Secure. these are labels to help in the URL comparison process.

   • Restricted --- This label indicates that once the user has authenticated and the requested resource matches the Restricted protected resource entry, the URL will be displayed. No further security processing is required.
   • Secure --- This label indicates that a second (ACL) compare of the URL entered will follow. Although the URL prefix that is labeled as secure can be used/linked to create the pattern that will be (ACL) compared against, it is provided only for semantic convenience. The field names URL prefix (in the ISO) and URL postfix (in the ACL) suggest a direct link. Although these fields are commonly concatenated, there is no direct link between the Secure protected resource and the ACL compare. (This will become clearer in the next step when the ACL compare is processed.)

   NOTE:  Two of the protected resource entries, B and C, match up with the URL Jack entered. The most specific match, based on the URL, takes precedence.

7. ACL check takes place next. In our example, there are four entries in the ACL. These are provided to show various methods that can be used to define the entry for the ACL.
   • The first entry shows both fields populated. http://www.novell.com/ is basically being cut and pasted from the ISO entry and then concatenated with the URL postfix of Secret/* to form http://www.novell.com/Secret/*. Since Jack is listed in the Apply To list, he is granted access to the resource.
   • The second entry also shows both fields populated. http://www.novell.com/* is basically being cut and pasted from the ISO entry to be concatenated with the URL postfix of Secret/* to form www.novell.com/Secret/*. Notice in this case iChain provides the intelligence to strip the trailing asterisk (*) during the cut and paste. Otherwise, the resource would look like: http://www.novell.com/*Secret/* and would produce a false negative match.

     Since Jack is listed in the Apply To list, he is granted access to the resource.

   • The third entry shows only the Name field populated. It simply provides a cut and paste of http://www.novell.com/secret to compare to the originally entered URL: http://www.novell.com/secret to produce a match and grant access. The ISO object denotes this URL prefix labeled as Secure. At this point in time --- the processing of the ACL --- this label has no meaning. It was used in the previous authentication process involving the ISO to indicate further security processing (ACL).
   • The fourth entry shows only the URL postfix field populated with http://www.novell.com/secret to compare to the originally entered URL: http://www.novell.com/secret to produce a match and grant access.

     Had Jack entered www.novell.com/secret/stuff/confid.xml, the only ISO protected resource that would allow access would be "B". With "B" eliminated, access would not be granted. The ISO protected resources A, C, D, and E do not match up. A new ISO entry could be created similar to C or D, such as www.novell.com/secret/*.xml. But rather than duplicate new entries, a new entry, www.novell.com/* (secure), could replace C, D, and the case for XML. During the processing at the ISO protected resource portion, www.novell.com/secret/stuff/confid.xml matches with www.novell.com/*. This match does not immediately grant access. It simply allows further processing at the ACL portion. Notice the /* at the ISO protected resource is appended to provide a match. iChain strips this off in the ACL processing portion.

The following flow chart shows the basic operation of the ACL. (It is not meant to be an all-inclusive code translation.)

Figure 1
Basic ACL Operation

Defining Dynamic Access Control Rules

Dynamic Access Control Rules allow an administrator to set up an access control rule based on a query of user attributes. (If a user's attribute value satisfies a predefined value, the rule would be applied to that particular user.) This type of query can be based on a user's attributes (the user's location, salary, hobby, etc.). For example, an administrator could configure a rule that says "Apply this rule to all the users who are in San Jose and have a salary greater than (>) $50,000."

Dynamic Access Control Rules are based on the following principles:

• A rule is applied to the users who satisfy a condition (query) provided by the administrator.
• Static applicability of the rules (object-based ACLs) will still exist in its current form. The DN exception and URL exception are also supported with the new type of rules. An ACL rule can contain both a dynamic query and a static "Apply To" list. Thus, one ACL rule can act as a dynamic rule and also as a traditional (static) rule.
• Because user attribute values can be dynamic, the administrator may want to limit the time that a rule can be cached in memory. This cache time, called "Time to Live," can be set in number of minutes and the cache for that rule will be expired after the specified duration elapses. The Time to Live value can only be set for dynamic ACLs. If no value is entered in the Time to Live field, the cache will not expire until the overall cache refresh takes place for ACLCHECK. If the Time to Live value is set at zero, the rule will not be cached.
• The administrator who creates a dynamic ACL must have write privileges on the ISO. (This is not required for non-dynamic ACLs.)

Setting Up Dynamic Access Control Rules

The dynamic ACL setup GUI allows you to create and test the search filter, then convert it to standard LDAP format to be stored in eDirectory. This query is later used to allow or disallow dynamic access control in iChain.

Dynamic ACLs can be defined when using the iChain Web Accelerator Wizard or the iChain Access Control snap-ins.

To create a dynamic ACL:

1. From ConsoleOne, open the ACL Rule object.

2. At the Access Control tab click the Dynamic ACL button in the Apply To dialog box (see Figure 2).

   Figure 2
   Access Control Tab in ACL Rule Object Snap-in
   

   This opens the Dynamic ACL Query Setup dialog box (see Figure 3).

   Figure 3
   Dynamic ACL Query Setup
   

3. Browse and select the active ISO and NCP Server object, if not pre-populated, which points to the appropriate LDAP group object having the updated NDS to LDAP attribute and class mappings.

4. Either update the existing LDAP Search filter field to form the query or click on the Advanced Dynamic ACL query setup button (see Figure 4).

   Figure 4
   Dynamic ACL Advanced Query Setup
   

5. Specify the time-to-live (in minutes) in cache for the dynamic ACL.

6. If you choose to build and test the query in the Advanced Dynamic ACL panel, the Find in field allows you to specify the container where to start searching for the objects.

7. The first query field (see Figure 5) allows you to select an object property to use as a search criterion, or select [Object Type] to search for the objects of a specific class.

   NOTE:  The [Object Type] is required only to test this query in this panel. Once the query is formed and tested, the administrator should remove this search criteria before saving it since iChain currently allows dynamic access control on user objects only.

   Figure 5
   Query Field
   

   Click the comparison operator to select a logical operator to use when comparing the value of the specified attribute with the actual attribute value in the Authorization Server (eDirectory).

   The second query field allows you to specify the attribute value to compare against the actual attribute value in the Authorization Server (eDirectory). The syntax is the type of data contained in the attribute, such as character string, integer, etc.

   Click on a statement connector keyword to select the keyword that specifies how this statement connects with the next statement or group of statements in the query. "And" specifies that both this and the next statement (or statement group) must be true for a match to occur. If there is no next statement, selecting this keyword adds one. "Or" specifies that either this or the next statement (or statement group) must be true for a match to occur. If there is no next statement, selecting this keyword adds one. "Insert Row" adds a new statement below this one. "Delete Row" deletes the statement from the query. "New Group" adds a new statement group below this one. "End" specifies that this statement ends the query.

   NOTE:  When creating a query there are some limitations with the query tool. It does not allow a mixture of "and/or" conditions in the same group or between groups.

8. Click the Test button to test the query in the eDirectory namespace and display the results at the bottom of the dialog box.

   You can right-click objects in the result list to perform actions as you do in the ConsoleOne right pane.

9. Click the Cancel button to discard the setup and exit the panel.

10. Click OK to convert the query (search criteria) to standard LDAP search filter format to be stored in the ACL object. Make sure your eDirectory to LDAP mappings are present in the right LDAP group object as pointed by the NCP Server object. This will close the Advanced window and allow you to edit the formed LDAP search filter before saving it along with its time-to-live-in-cache attribute.

    IMPORTANT:  It is important to understand the differences and associated limitations while testing your query. Query testing is done in the eDirectory namespace and stored in LDAP format. Thus, there may be situations where you need to specify the value in the second query field in eDirectory format while testing, but change it to LDAP format before saving it.