Writing Rules › Use of NEXTKEY in Resource Rules › Using NEXTKEYs With $ROLESET Rules

Using NEXTKEYs With $ROLESET Rules

When using the NEXTKEY parameter in a ROLESET rule, the same ROLE has to match throughout the NEXTKEY chain. Higher level rules could use ROLE(-) since ROLE(-) will match any role.

Note: ROLE(-) will also match for logonids that have no roles.

During access validation on a $ROLESET rule, the first role in the user’s list of roles 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.

The following examples assume the following information for logonid USER01:

• USER01 has UID string: TFINPAYUSER01
• USER01 has the following roles in this order:
  • CROLC
  • AROLA
  • ZROLZ
  • CROLA

Example 1

$KEY(MASTER) 
$ROLESET  
$TYPE(ttt)
 SHOP ROLE(CROLC) NEXTKEY(MASTER2)  
 SHOP ROLE(ZROLZ) NEXTKEY(MASTER2)  
 DROP ROLE(CROLC) NEXTKEY(MASTER2) 
 CROP ROLE(-) NEXTKEY(MASTER2) 

$KEY(MASTER2) 
$ROLESET
$TYPE(ttt)
$PREFIX(MASTER)
 SHOP ROLE(CROLC) PREVENT
 SHOP ROLE(ZROLZ) ALLOW or LOG
 DROP ROLE(CROLA) ALLOW
 CROP ROLE(AROLA) ALLOW                                       

• Does USER01 have read access to resource MASTER.SHOP?

  Yes, since he has role ZROLZ and the SHOP rule lines use ZROLZ throughout the NEXTKEY chain. Note that CROLC is used first, but the access is denied through CROLC. The validation is re-driven with the next role in the list, AROLA, and again the access is denied. The validation is re-driven with the next role in the list, ZROLZ, and an allow condition is met with ZROLZ.

• Does USER01 have read access to resource MASTER.DROP?

  No, because the first rule uses CROLC and the NEXTKEY rule uses CROLA. The same ROLE must be used throughout, or access will be denied.

• Does USER01 have read access to resource MASTER.CROP?

  Yes, because the first rule uses ROLE(-) which matches any role and the NEXTKEY rule uses AROLA, which USER01 has.

Example 2

$KEY(MASTER)
$ROLESET
 SHOP USER(USER01) NEXTKEY(MASTER2)
 DROP USER(-) NEXTKEY(MASTER2)
$KEY(MASTER2)
$ROLESET
$PREFIX(MASTER)
 SHOP ROLE(ZROLZ) NEXTKEY(MASTER3)
 DROP ROLE(CROLZ) NEXTKEY(MASTER3)

$KEY(MASTER3)
$PREFIX(MASTER)
 SHOP UID(TFINPAY) ALLOW 
 DROP UID(TFINPAY) ALLOW

• Does USER01 have read access to resource MASTER.SHOP?

  Yes, in the first rule, his logonid matches the USER. For the second rule, he has ZROLZ. And in the third rule, his UID string matches.

• Does USER01 have read access to resource MASTER.DROP?

  No, because he does not have role CROLZ so the second rule won't match.

Example 3

$KEY(MASTER)
$ROLESET
 SHOP ROLE(*ROL*) NEXTKEY(MASTER2)
 DROP USER(US-) NEXTKEY(MASTER2)

$KEY(MASTER2)
$PREFIX(MASTER)
 SHOP UID(TFINPAY) ALLOW
 DROP UID(TFINPAY) ALLOW 

• Does USER01 have read access to resource MASTER.SHOP?

  No, because ROLE and USER values are not maskable except for when using a single dash character to represent all users. So, ROLE(-) and USER(-) will match everyone. ROLE(*ROL*) will only match an X(ROL) record with a record name of *ROL*. The asterisks are treated as literal asterisks and not as a mask.

• Does USER01 have read access to resource MASTER.DROP?

  No, because ROLE and USER values are not maskable except for when using a single dash character to represent all users. USER(US-) will not match. The dash is treated as literal dash and not as a mask. The rule compiler will warn you when you use a literal dash or asterisk characters.