How does nextkey work when using CA ACF2 Roles in access rules?
Article ID: 136520
Updated On:
Products
Issue/Introduction
The below scenario describes the issue
dataset rule
$KEY(C828) Roleset
P909.- Role(BBROLE) r(a) w(a)
- role(-) Nextkey(c828NR)
---------------------------------------------------
$KEY(C828NR)
$Prefix(C828)
P808.- UID(AA) r(a) w(a)
P909.- UID(*) prevent
--------------------------------------------------
AAROLE - include(USERA,USERB)
-------------------------------------------------
BBROLE - include(USERB)
-----------------------------------------------
USERB UID(AA DEPT20)
_____________________________
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.
Environment
Release : 16.0
Component : CA ACF2 for z/OS
Resolution
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.
Feedback
