Using Deny Rules with a General Permit Rule

You can also create policies that contain one or more Deny rules and then create the lowest priority rule in the policy as a Permit rule with no conditions. In such a policy, as soon as a Deny rule matches a user, the rest of the rules are not processed and the user is denied access to the resource. The Permit rule is only processed if the user does not match one of the Deny rules. Because all users match a rule with no conditions, the user is allowed access to the resource.

The key to creating this type of policy is making sure all the Deny rules match the users you do not want accessing the resource and making sure that the Result on Error Condition option is set correctly.

For example, suppose one of the Deny rules uses an LDAP attribute for the condition and that the attribute is a hatSize attribute. Some of your users do not have a hatSize attribute, so when they access the resource, the comparison generates an error. If Result on Error Condition option is set to False, the action (Deny) is not applied, and the next rule in the policy is processed. If that rule is the general Permit rule, then they are allowed access to the resource because they experienced an error. To prevent this behavior, you need to set the Result on Error Condition option to True, so that the Deny action is applied. Your rule then denies access to everyone whose hatSize attribute matches the specified value and everyone who does not have the attribute.

The Deny rule for such a policy would look similar to the following:

Figure 6-5 Deny Rule Configured for Error Conditions

For most people, Deny rules are harder to write than Permit rules. You not only need to carefully configure the Result on Condition Error option, you must also carefully consider the consequences of the condition not matching a user. When a user does not’ match the condition, the Action is not applied and the next rule in the policy is evaluated. For example, suppose the URL condition is set to the compare the following value:

http://sales.provo.novell.com/meetings/?

If the URL in the request is http://sales.provo.novell.com/meetings/january, the user does not match the condition, because the ? applies only to the files in the meetings directory and not to the subdirectories. The Action is not applied, and the next rule or policy is evaluated. Consider the following possibilities:

  • If you want the condition to match all files and subdirectories, you need to change the ? wildcard to the wildcard.

  • If you want the condition to allow access to the files in the /meetings directory but deny access to the subdirectories, you need to negate the condition so it evaluates as follows: if the URL is not a request for the /meetings/? directory, deny access. If you select this type of condition, you need to set the Result on Condition Error option to True. If the comparison returns an error and there is the possibility that the request is for a subdirectory, you want the user to be denied access.

The general Permit rule for a Deny policy would look similar to the following:

Figure 6-6 General Permit Rule