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 7–8. 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 7–9. The active role of a subject s, written actr(s), is the role that s is currently performing.
Definition 7–10. The authorized roles of a subject s, written authr(s), is the set of roles that s is authorized to assume.
Definition 7–11. 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 7–7. 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 7–8. 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 7–9. 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
|
|
EXAMPLE: RBAC can model the separation of duty rule. Our goal is to specify separation of duty centrally; then it can be imposed on roles through containment, as discussed in the preceding example. The key is to recognize that the users in some roles cannot enter other roles. That is, for two roles r1 and r2 bound by separation of duty (so the same individual cannot assume both roles):
|
Capturing the notion of mutual exclusion requires a new predicate.
Definition 7–12. Let r be a role, and let s be a subject such that r
auth(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) ] ] ]
| Top |