7.4. Role-Based Access Control
The ability, or need, to access information may depend on one's job functions.
|
EXAMPLE:
Allison is the bookkeeper for the Department of Mathematics. She is responsible for balancing the books and keeping track of all accounting for that department. She has access to all departmental accounts. She moves to the university's Office of Admissions to become the head accountant (with a substantial raise). Because she is no longer the bookkeeper for the Department of Mathematics, she no longer has access to those accounts. When that department hires Sally as its new bookkeeper, she will acquire full access to all those accounts. Access to the accounts is a function of the job of bookkeeper, and is not tied to any particular individual. |
This suggests associating access with the particular job of the user.
Definition 77.
A role is a collection of job functions. Each role r is authorized to perform one or more transactions (actions in support of a job function). The set of authorized transactions for r is written trans(r). Definition 78.
The active role of a subject s, written actr(s), is the role that s is currently performing. Definition 79.
The authorized roles of a subject s, written authr(s), is the set of roles that s is authorized to assume. Definition 710.
The predicate canexec(s, t) is true if and only if the subject s can execute the transaction t at the current time.
Three rules reflect the ability of a subject to execute a transaction.
Axiom 71.
Let S be the set of subjects and T the set of transactions. The rule of role assignment is ( s  S)(t T)[ canexec(s, t)  actr(s)  Ø ].
This axiom simply says that if a subject can execute any transaction, then that subject has an active role. This binds the notion of execution of a transaction to the role rather than to the user.
Axiom 72.
Let S be the set of subjects. Then the rule of role authorization is (s S)[ actr(s)  authr(s) ].
This rule means that the subject must be authorized to assume its active role. It cannot assume an unauthorized role. Without this axiom, any subject could assume any role, and hence execute any transaction.
Axiom 73.
Let S be the set of subjects and T the set of transactions. The rule of transaction authorization is (s S)(t T)[ canexec(s, t) t trans(actr(s)) ].
This rule says that a subject cannot execute a transaction for which its current role is not authorized.
The forms of these axioms restrict the transactions that can be performed. They do not ensure that the allowed transactions can be executed. This suggests that role-based access control (RBAC) is a form of mandatory access control. The axioms state rules that must be satisfied before a transaction can be executed. Discretionary access control mechanisms may further restrict transactions.
|
EXAMPLE:
Some roles subsume others. For example, a trainer can perform all actions of a trainee, as well as others. One can view this as containment. This suggests a hierarchy of roles, in this case the trainer role containing the trainee role. As another example, many operations are common to a large number of roles. Instead of specifying the operation once for each role, one specifies it for a role containing all other roles. Granting access to a role R implies that access is granted for all roles containing R. This simplifies the use of the RBAC model (and of its implementation).
If role ri contains role rj, we write ri > rj. Using our notation, the implications of containment of roles may be expressed as
(s S)[ ri authr(s)  ri > rj rj authr(s) ]
|
Capturing the notion of mutual exclusion requires a new predicate.
Definition 711.
Let r be a role, and let s be a subject such that r authr(s). Then the predicate meauth(r) (for mutually exclusive authorizations) is the set of roles that s cannot assume because of the separation of duty requirement.
Putting this definition together with the above example, the principle of separation of duty can be summarized as
(r1, r2 R) [ r2 meauth(r1) [ (s S) [ r1 authr(s) r2  authr(s) ] ] ]
 | 
