To clarify the notions presented in the previous section, we give a simple formal description, in terms of sets and relations, of role based access control. No particular implementation mechanism is implied.
For each subject, the active role is the one that the subject is currently using:
Each subject may be authorized to perform one or more roles:
Each role may be authorized to perform one or more transactions:
Subjects may execute transactions. The predicate exec(s,t) is true if subject s can execute transaction t at the current time, otherwise it is false:
Three basic rules are required:
The identification and authentication process (e.g. login) is not considered a transaction. All other user activities on the system are conducted through transactions. Thus all active users are required to have some active role.
With (1) above, this rule ensures that users can take on only roles for which they are authorized.
With (1) and (2), this rule ensures that users can execute only transactions for which they are authorized. Note that, because the conditional is ``only if'', this rule allows the possibility that additional restrictions may be placed on transaction execution. That is, the rule does not guarantee a transaction to be executable just because it is in TA(AR(s)), the set of transactions potentially executable by the subject's active role. For example, a trainee for a supervisory role may be assigned the role of ``Supervisor'', but have restrictions applied to his or her user role that limit accessible transactions to a subset of those normally allowed for the Supervisor role.
In the preceding discussion, a transaction has been defined as a transformation procedure, plus a set of data items accessed by the transformation procedure. Access control in the rules above does not require any checks on the user's right to access a data object, or on the transformation procedure's right to access a data item, since the data accesses are built into the transaction. Security issues are addressed by binding operations and data into a transaction at design time, such as when privacy issues are addressed in an insurance query transaction.
It is also possible to redefine the meaning of ``transaction'' in the above rules to refer only to the transformation procedure, without including a binding to objects. This would require a fourth rule to enforce control over the modes in which users can access objects through transaction programs. For example, a fourth rule such as
Use of this fourth rule might be appropriate, for example, in a hospital setting. A doctor could be provided with read/write access to a prescription file, while the hospital pharmacist might have only read access. (Recall that use of the first three rules alone requires binding the transaction program t and data objects that t can access, and only controls access to the transactions.) This alternative approach using the fourth rule might be helpful in enforcing confidentiality requirements.
Another use of RBAC is to support integrity. Integrity has been defined in a variety of ways, but one aspect [8] of integrity is a requirement that data and processes be modified only in authorized ways by authorized users. This seems to be a reasonable security objective for many real systems, and RBAC should be applicable to such systems.
In general, the problem of determining whether data have been modified only in authorized ways can be as complex as the transaction that did the modification. For this reason, the practical approach is for transactions to be certified and trusted. If transactions must be trusted then access control can be incorporated directly into each transaction. Requiring the system to control access of transaction programs to objects through the access function used in rule (4) might then be a useful form of redundancy, but it could involve significant overhead for a limited benefit in enforcing integrity requirements. Therefore, inclusion of a transaction to object access control function in RBAC would be useful in some, but not all applications.
