ACF2 $ROLESET Selection Processing, Blocking Rule Line and use of USER(-) and ROLE(-)

Products

• ACF2
• ACF2 - DB2 Option
• ACF2 for zVM
• ACF2 - z/OS
• ACF2 - MISC

Issue/Introduction

How does the rule interpreter process ROLESET rule entries? Is  possible to use a "blocking rule line" to stop the interpreter from proceeding down the rule set looking for a match?

Environment

Release:
Component: ACF2MS

Resolution

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

Example
USER001 belongs to ROLE1, ROLE2 and ROLE3:

ROLE1 LAST CHANGED BY xxxxxxxx ON 03/29/19-14:25        
                       INCLUDE(USER001 USER008 USER009) ROLE 

ROLE2 LAST CHANGED BY xxxxxxxx ON 03/29/19-14:25        
                       INCLUDE(USER001 USER002 USER003) ROLE 

ROLE3 LAST CHANGED BY xxxxxxxx ON 03/29/19-14:25        
                       INCLUDE(USER001 USER004 USER005) ROLE 

The following ROLESET rule is in place

$KEY(SYS1) ROLESET                     
 PDS.- ROLE(ROLE1)                        
 PDS.- ROLE(ROLE2)                        
 P-.- ROLE(ROLE3) READ(A) EXEC(A)    

Rule Validation

 

• USER001 logs in, ACF2 builds USER001 role table including ROLE1, ROLE2 and ROLE3.
• USER001 accesses SYS1.PDS.TEST.
• ROLE1 is used for SYS1 rule validation, rule entry 'PDS.- ROLE(ROLE1)' matches, access is denied, ACF2 continues the rule validation process.
• The next ROLE ROLE2 is selected, SYS1 rule validation is re-driven, rule entry 'PDS.- ROLE(ROLE2)' matches, access is denied, ACF2 continues the rule validation process.
• The next ROLE ROLE3 is selected, SYS1 rule validation is re-driven, rule entry 'P-.- ROLE(ROLE3) READ(A) EXEC(A)' matches, access is allowed.

Note: When there are several rule entries that have matching DSN patterns, when a rule entry with ROLE(-) is encountered no further rule validation occurs, the access specified on the rule entry with ROLE(-) is used. The ROLE(-) rule entry can be used like a 'blocking rule line'.

When a USER(…) rule line is encountered, the first rule entry that matches the actual data set, volume, USER, source, shift, library, program, and date being used (that is, the defined environment) is the rule entry CA ACF2 uses to determine the access privileges.

If access is denied by a rule line that specifies USER then the access is denied. In this case, CA ACF2 will not re-drive validation with the next role in the user’s role list.

Note: When compiling a ROLESET rule with rule entries with USER and ROLE rule entries that have matching DSN patterns and VOL patterns(if specified), the USER rule entries will sort ahead of the ROLE rule entries.

If the compiler finds two conflicting rules with the same environment during the sorting process, it rejects the input rule set and terminates.

Note the compiler sort order with respect to "USER(-)" and "ROLE(-)": 

The rule compiler converts the input into a form that the rule interpreter can 
verify. In addition, the rule compiler orders the rules according to the 
following criteria. 

• DSN patterns from most specific to most general 
• VOL patterns from most specific to most general 
• USER operands in alphabetical order, with "USER(-)" last 
• ROLE operands in alphabetical order, with "ROLE(-)" last 
• SOURCE operands in alphabetical order, with "not specified" last 
• SHIFT operands in alphabetical order, with "not specified" last 
• LIB patterns from most specific to most general 
• PGM/PROG patterns from most specific to most general 
• DDN patterns from most specific to most general 
• UNTIL dates from earliest to latest 
• ACTIVE dates from earliest to latest