D. Ferraiolo, D. Kuhn. 1992. "Role-Based Access Controls"

(some notes on the paper since most of the information overlaps with other notes)

Like DoD agencies, civilian government and commercial firms are very much concerned with protecting the confidentiality of information... But many of these organizations have even greater concern for integrity.

An organizational meaning of security cannot be presupposed. Each organization has unique security requirements.

In many organizations, the end users do not "own" the information for which they are allowed access. For these organizations, the corporation or agency is the actual "owner" of system objects as well as the programs that process it. Control is often based on employee functions rather than data ownership.

The determination of membership and the allocation of transactions (permissions) to a role is not so much in accordance with discretionary decisions on the part of a system administrator, but rather in compliance with organization-specific protection guidelines. These policies are derived from existing laws, ethics, regulations, or generally accepted practices.

RBAC	MAC
more concerned with access to functions and information	more concerned with access to information
"who can perform what acts on what information"	"who can read what information"

Transaction (permission) clarification: "read" is not a transaction, because it is not bound to a particular data item. "read savings file" is.

RBAC applications

• database system - using roles to control access


• cryptographic authentication devices commonly used in the banking industry


• proposed standard by NIST, "Security Requirements for Cryptographic Modules," that will require support for access control and administration through roles

Role based access controls described in this paper address security primarily for application-level systems, as opposed to general purpose operating systems. (RBAC can be applied in OSs)


Formal description of RBAC

1. Role assignment: A subject can execute a transaction only if the subject has selected or been assigned a role


2. Role authorization: A subject's active role must be authorized for the subject


3. Transaction authorization: A subject can execute a transaction only if the transaction is authorized for the subject's active role
   
   • 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 the set of transactions potentially executable by the subject's active role.

It is 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.

4. for every s: subject, t: tran, o: object, (exec(s,t) is true if access(AR(s),t,o, x))

access(r, i, o, x) indicates if it is permissible for a subject in role r to access object o in mode x using transaction t, where x is taken from some set of modes such as read, write, append.

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. (unclear why it can't be achieved using original 3 rules)

Enforcing integrity through RBAC
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.

Static vs dynamic separation of duty

Static	Dynamic
no individual who can serve as payment initiator could also serve as payment authorizer.	an individual can take on both initiator and authorizer roles, with the exception that no one could authorize payments that he or she had initiated.
may be too rigid for commercial use, making the cost of security greater than the loss that might be expected without the security.	more flexible
could be implemented by checking only roles of users	could be implemented by checking both role and user ID