How does nextkey work when using CA ACF2 Roles in access rules?
search cancel

How does nextkey work when using CA ACF2 Roles in access rules?


Article ID: 136520


Updated On:


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


The below scenario describes the issue

dataset rule

$KEY(C828) Roleset

P909.- Role(BBROLE) r(a) w(a)

- role(-) Nextkey(c828NR)




P808.- UID(AA) r(a) w(a)

P909.- UID(*) prevent




BBROLE - include(USERB) 




So USERB tries to read C828.P909.TEST

ACF2 builds a list of all the roles that USERB is included in and that is AAROLE and BBROLE.  

It goes through rule C828 using AAROLE, no match, goes on to rule C828NR and hits a prevent so access is denied. 


If USERB was only in BBROLE it would work, add CCROLE and it still works, add DDROLE and it still works, add AAROLE and it will not work.  



Release : 16.0

Component : CA ACF2 for z/OS


The scenario as described is incorrect.

The ruleline...

P909.- UID(*) prevent


would cause the validation for that role to stop but it would not stop the 

validation from continuing with the next role.

The validation will start with the first role that the user is connected to... 

A full validation thru all nextkeys will take place for that first role. 

If there is an allow permission the access is allowed. 

If there is a prevent , the validation for that role will stop and the process will start again with the user's next role.

This will continue until there are no more roles or there is an allow. 

 If there are any rule lines that match the environment, that rule line will be used.

 For example. - UID(*) R(A) E(A) A(P) and the user is requesting write access - the outcome of 

THIS rule line would be to prevent access - because WRITE ACCESS WAS NOT ALLOWED. 

The validation will continue at the first rule and validate the user's next role.