Novell Doc: Novell iChain Administration Guide - Defining Dynamic Access Control Rules

12.2 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 might 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 is not cached.
The administrator who creates a dynamic ACL must have write privileges on the ISO. (This is not required for non-dynamic ACLs.)

12.2.1 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 Server Web Accelerator Wizard or the iChain Access Control snap-ins.

To create a dynamic ACL:

In ConsoleOne, open the ACL Rule object.
On the Access Control page click the Dynamic ACL button (represented as a magnifying glass) next to the Apply To dialog box.

This opens the Dynamic ACL Query Setup dialog box.
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 eDirectory to LDAP attribute and class mappings.
Either update the existing LDAP Search filter field to form the query or click the Advanced Dynamic ACL query setup button located at the right of the Search filter field.
Specify the time to live (in minutes) in cache for the dynamic ACL.

NOTE:This time to live is meant to keep track of changes in user's attributes rather than changes in the ACL rule value. If you delete an ACL rule, the user still has access to that resource. Dynamic ACL rules are read at startup time or at the cache refresh time, so this dynamic ACL rule is still cached until you perform an aclcheck refresh.
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 location to start searching for the objects.
The first query field 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. After the query is formed and tested, you should remove this search criteria before saving it because iChain currently allows dynamic access control on user objects only.

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). For more information about the Authorization Server, see Installing iChain Services Schema Extensions on the iChain Authorization Server.

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, or integer.

Click 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.
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.
If you don't want to keep the query, click the Cancel button to discard the setup and exit the panel.
If you want to keep the query, 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 closes the Advanced window and allows 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. A rule built with comma-delimited LDAP format (for example, commerceBudgetHolder = cn=CostCenter03,o=novell,c=us) fails to locate user objects matching the specified attribute when using the Test button, but works properly to allow or deny user access through ACLCHECK. Changing the format to use eDirectory dot-delimited format (for example, commerceBudgetHolder = cn=CostCenter03.o=novell.c=us) allows the Test button to work as expected so that the rule can be verified. Remember to change the rule back to the comma-delimited LDAP format when saving so that ACLCHECK functions as expected.