Previous Topic: Which Rule Entry is Selected for $ROLESET Rules?Next Topic: Merging Rule Sets

Writing Rules › Use of NEXTKEY in Resource Rules

Use of NEXTKEY in Resource Rules

The NEXTKEY parameter directs CA ACF2 Option for DB2 to evaluate an alternate resource rule set when a particular environment applies to the access, but the access is prevented. Remember that CA ACF2 Option for DB2 validation is directed to the rule set specified in the NEXTKEY option only when access based on the current rule entry is prevented. Validation of the access continues with the evaluation of the alternate resource rule set.

You can build a maximum chain of 25 NEXTKEYs. When you specify more than 25, CA ACF2 Option for DB2 denies access and writes an SMF logging record of the event. The ACFRPTRV report displays the error condition and the $KEYs of all the rules that CA ACF2 Option for DB2 checked.

When using NEXTKEY, you must ensure that looping is avoided. Looping in NEXTKEY processing occurs when a NEXTKEY parameter is interpreted more than once during a single access validation. CA ACF2 Option for DB2 issues an error message when a loop condition occurs. It also denies the access request and logs the event. The ACFRPTRV report displays the error condition and the $KEYs of all the rules that CA ACF2 Option for DB2 checked.

You can use the NEXTKEY feature to divide a particular rule set. You might divide a rule set if it is very large (and you have not enabled the RULELONG parameter of the RULEOPTS GSO record), or to delegate rule maintenance (%CHANGE or %RCHANGE) authority. An alternative to using NEXTKEY to divide a large rule set is to increase the size of the CA ACF2 Inforstorage database. The default size of an CA ACF2 Option for DB2 resource rule record is 4K (4096 bytes), but your site can increase the size up to 32K (32768 bytes). For more information, see the Product Guide.

The same ROLE has to match throughout the NEXTKEY chain when using the NEXTKEY parameter with $ROLESET rules. Higher level rules could use ROLE(-) since ROLE(-) will match any role.

During access validation on a $ROLESET rule, the first role in the list is used for validation. If access is denied, the next role in the list is selected and validation is re-driven, possibly taking a different NEXTKEY path. This process continues until access is allowed or the user’s list of roles is exhausted.

You can combine $ROLESET rules and regular UID rules in the same NEXTKEY path.