TABLE OF CONTENTS In this section we look at 13 properties that should hold throughout the lifetime of an RBAC system. This is mostly based on the work of Serban et al. [SERB98].
Imposing a maximum cardinality constraint on a given role means the number of authorized users for that role at any time should not exceed its cardinality. Formally,
?R ? ROLES, role_authorized_users(R) ? cardinality max (R).
Imposing a minimum role cardinality constraint means the number of users authorized for that role should not be lower than the cardinality requirement for that role. Formally,
?R ? ROLES, role_authorized_users(R) ? cardinality min (R)
Note the use of authorized users here due to the effect of a hierarchical RBAC. In the case of a flat RBAC, authorized users are identical to the assigned users.
To maintain consistency and avoid useless cyclic scenarios, no role should inherit itself directly or indirectly. Formally,
?R ? ROLES, ? (R ? + R).
? + denotes an inheritance path of length one or more.
Any two roles authorized for the same user are not in any static separation-of-duty relationship. Formally,
?u ? USERS, ? R 1, R 2 ? ROLES, R 1, R 2 ?
user_authorized_roles(u) ? R 1, R 2 ? SSoD.
Any two roles explicitly assigned to a user should...
