Configuring role-based access control to enforce mandatory and discretionary access control policies.
Access control models have traditionally included mandatory access control (or lattice-based access control) and discretionary access control. Subsequently, role-based access control has been introduced, along with claims that its mechanisms are general enough to simulate the traditional methods. In this paper we provide systematic constructions for various common forms of both of the traditional access control paradigms using the role-based access control (RBAC) models of Sandhu et al., commonly called RBAC96. We see that all of the features of the RBAC96 model are required, and that although for the manatory access control simulation, only one administrative role needs to be assumed, for the discretionary access control simulations, a complex set of administrative roles is required.
INTRODUCTION
Role-based access control (RBAC) has recently received considerable attention as
a promising alternative to traditional discretionary and mandatory access controls
(see, for example, Proceedings of the ACM Workshop on Role-Based Access Con-
trol, 1995-2000). In RBAC, permissions are associated with roles, and users are
made members of appropriate roles thereby acquiring the roles' permissions. This
greatly simplies management of permissions. Roles can be created for the various
job functions in an organization and users then assigned roles based on their
responsibilities and qualications. Users can be easily reassigned from one role to
another. Roles can be granted new permissions as new applications and systems
are incorporated, and permissions can be revoked from roles as needed.
An important characteristic of RBAC is that by itself it is policy neutral. RBAC
is a means for articulating policy rather than embodying a particular security policy
(such as one-directional information
ow in a lattice). The policy enforced in a
particular system is the net result of the precise conguration and interactions of
various RBAC components as directed by the system owner. Moreover, the access
control policy can evolve incrementally over the system life cycle, and in large
systems it is almost certain to do so. The ability to modify policy to meet the
changing needs of an organization is an important benet of RBAC.
Traditional access control models include mandatory access control (MAC), which
we shall call lattice-based access control (LBAC) here [Denning 1976; Sandhu 1993],
and discretionary access control (DAC) [Lampson 1971; Sandhu and Samarati 1994;
Sandhu and Samarati 1997]. Since the introduction of RBAC, several authors have
discussed the relationship between RBAC and these traditional models [Sandhu
1996; Sandhu and Munawer 1998; Munawer 2000; Nyanchama and Osborn 1996;
Nyanchama and Osborn 1994]. The claim that RBAC is more general than all of
these traditional models has often been made. The purpose of this paper is to show
how RBAC can be congured to enforce these traditional models.
Classic LBAC models are specically constructed to incorporate the policy of
one-directional information
ow in a lattice. This one-directional information
ow
can be applied for condentiality, integrity, condentiality and integrity together, or
for aggregation policies such as Chinese Walls [Sandhu 1993]. There is nonetheless
strong similarity between the concept of a security label and a role. In particular,
the same user cleared to, for example, Secret can on dierent occasions login to a
system at Secret and Unclassied levels. In a sense the user determines what role
(Secret or Unclassied) should be activated in a particular session.
This leads us naturally to ask whether or not LBAC can be simulated using
RBAC. If RBAC is policy neutral and has adequate generality it should indeed be
able to do so, particularly since the notion of a role and the level of a login session
are so similar. This question is theoretically signicant because a positive answer
would establish that LBAC is just one instance of RBAC, thereby relating two
distinct access control models that have been developed with dierent motivations.
A positive answer is also practically signicant, because it implies that the same
Trusted Computing Base can be congured to enforce RBAC in general and LBAC
in particular. This addresses the long held desire of multi-level security advocates
that technology which meets needs of the larger commercial marketplace be appli-
Conguring RBAC to Enforce MAC and DAC  3
cable to LBAC. The classical approach to fullling this desire has been to argue
that LBAC has applications in the commercial sector. So far this argument has
not been terribly productive. RBAC, on the other hand, is specically motivated
by needs of the commercial sector. Its customization to LBAC might be a more
productive approach to dual-use technology.
In this paper we answer this question positively by demonstrating that several
variations of LBAC can be easily accommodated in RBAC by conguring a few
components. 1 We use the family of RBAC models recently developed by
Sandhu et al [Sandhu et al. 1996; Sandhu et al. 1999] for this purpose. This family
is commonly called the RBAC96 model. Our constructions show that the concepts
of role hierarchies and constraints are critical to achieving this result.
Changes in the role hierarchy and constraints lead to dierent variations of LBAC.
A simulation of LBAC in RBAC was rst given by Nyanchama and Osborn [Nyan-
chama and Osborn 1994]; however, they do not exploit role hierarchies and constraints
and cannot handle variations so easily as the constructions of this paper.
Discretionary access control (DAC) has been used extensively in commercial ap-
plications, particularly in operating systems and relational database systems. The
central idea of DAC is that the owner of an object, who is usually its creator, has
discretionary authority over who else can access that object. DAC, in other words,
involves owner-based administration of access rights. Whereas for LBAC, we do
not need to discuss a complex administration of access rights, we will see that for
DAC, the administrative roles developed in Sandhu, Bhamidipati, and Munawer
[1999] are crucial. Because each object could potentially be owned by a unique
owner, the number of administrative roles can be quite large. However, we will
show that the role administration facilities in the RBAC96 model are adequate to
build a simulation of these sometimes administratively complex systems.
The rest of this paper is organized as follows. We review the family of RBAC96
models due to Sandhu, Coyne, Feinstein, and Youman [1996] in section 2. This is
followed by a quick review of LBAC in section 3. The simulation of several LBAC
variations in RBAC96 is described in section 4. This is followed by a brief discussion
in Section 5 of other RBAC96 congurations which also satisfy LBAC properties.
Section 6 introduces several major variations of DAC. In Section 7 we show how
each of these variations can be simulated in RBAC96. Section 8 summarizes the
results. Preliminary versions of some of these results have appeared in Sandhu
[1996], Sandhu and Munawer [1998], Nyanchama and Osborn [1996] and Osborn
[1997].
2. RBAC MODELS
A general RBAC model including administrative roles was dened by Sandhu et
al [Sandhu et al. 1996]. It is summarized in Figure 1. The model is based on
three sets of entities called users (U ), roles (R), and permissions (P ). Intuitively, a
It should be noted that RBAC will only prevent overt
ows of information. This is true of any
access control model, including LBAC. Information
ow contrary to the one-directional requirement
in a lattice by means of so-called covert channels is outside the purview of access control
per se. Neither LBAC nor RBAC addresses the covert channel issue directly. Techniques used to
deal with covert channels in LBAC can be used for the same purpose in RBAC.
4  Osborn, Sandhu and Munawer
user is a human being or an autonomous agent, a role is a job function or job title
within the organization with some associated semantics regarding the authority and
responsibility conferred on a member of the role, and a permission is an approval
of a particular mode of access to one or more objects in the system.
ADMINIS-
ROLES
AR
user roles
HIERARCHY
ROLE
RH
ROLE
HIERARCHY
ARH
IONS
PERMISSION
ASSIGNMENT
PA
ROLES
R
PERMISSION
APA
ASSIGNMENT
ADMIN.
IONS
CONSTRAINTS
U
USERS
USER
ASSIGNMENT
UA
USER
ASSIGNMENT
AUA
Fig. 1. The RBAC96 Model
The user assignment (UA) and permission assignment (PA) relations of Figure 1
are both many-to-many relationships (indicated by the double-headed arrows). A
user can be a member of many roles, and a role can have many users. Similarly,
a role can have many permissions, and the same permission can be assigned to
many roles. There is a partially ordered role hierarchy RH, also written as ,
where x  y signies that role x inherits the permissions assigned to role y. In the
work of Nyanchama and Osborn [Nyanchama and Osborn 1994; Nyanchama and
Osborn 1999; Nyanchama and Osborn 1996], the role hierarchy is presented as an
acyclic directed graph, and direct relationships in the role hierarchy are referred to
as edges. Inheritance along the role hierarchy is transitive; multiple inheritance is
allowed in partial orders.

Figure

1 shows a set of sessions S. Each session relates one user to possibly
many roles. Intuitively, a user establishes a session during which the user activates
Conguring RBAC to Enforce MAC and DAC  5
some subset of roles that he or she is a member of (directly or indirectly by means
of the role hierarchy). The double-headed arrow from a session to R indicates
that multiple roles can be simultaneously activated. The permissions available to
the user are the union of permissions from all roles activated in that session. Each
session is associated with a single user, as indicated by the single-headed arrow from
the session to U . This association remains constant for the life of a session. A user
may have multiple sessions open at the same time, each in a dierent window on the
workstation screen for instance. Each session may have a dierent combination of
active roles. The concept of a session equates to the traditional notion of a subject
in access control. A subject (or session) is a unit of access control, and a user may
have multiple subjects (or sessions) with dierent permissions active at the same
time.
The bottom half of Figure 1 shows administrative roles and permissions. RBAC96
distinguishes roles and permissions from administrative roles and permissions re-
spectively, where the latter are used to manage the former. Administration of
administrative roles and permissions is under control of the chief security o-cer
or delegated in part to administrative roles. The administrative aspects RBAC96
elaborated in [Sandhu et al. 1999] are relevant for the DAC discussion in Section 6.
For the purposes of the LBAC discussion, we assume a single security o-cer is the
only one who can congure various components of RBAC96.
Finally, Figure 1 shows a collection of constraints. Constraints can apply to any
of the preceding components. An example of constraints is mutually disjoint roles,
such as purchasing manager and accounts payable manager, where the same user
is not permitted to be a member of both roles.
The following denition formalizes the above discussion.
Definition 1. The RBAC96 model has the following components:
|U , a set of users
R and AR, disjoint sets of (regular) roles and administrative roles
P and AP , disjoint sets of (regular) permissions and administrative permissions
S, a set of sessions
many-to-many permission to role assignment relation
APA  AP AR, a many-to-many permission to administrative role assignment
relation
|UA  U R, a many-to-many user to role assignment relation
AUA  U AR, a many-to-many user to administrative role assignment relation
|RH  R R, a partially ordered role hierarchy
ARH  AR AR, partially ordered administrative role hierarchy
(both hierarchies are written as  in inx notation)
mapping each session s i to the single user user(s i )
(constant for the session's lifetime),
roles maps each session s i to a set of roles and administrative roles
(which can change with
time)
session s i has the permissions [
6  Osborn, Sandhu and Munawer
|there is a collection of constraints stipulating which values of the various components
enumerated above are allowed or forbidden.
3. LBAC (OR MAC) MODELS
Lattice based access control is concerned with enforcing one directional information
ow in a lattice of security labels. It is typically applied in addition to classical
discretionary access controls, but in this section we will focus only on the MAC
component. A simulation of DAC in RBAC96 is found in Section 7. Depending
upon the nature of the lattice, the one-directional information
ow enforced by
LBAC can be applied for condentiality, integrity, condentiality and integrity
together, or for aggregation policies such as Chinese Walls [Sandhu 1993]. There are
also variations of LBAC where the one-directional information
ow is partly relaxed
to achieve selective downgrading of information or for integrity applications [Bell
1987; Lee 1988; Schockley 1988].
The mandatory access control policy is expressed in terms of security labels
attached to subjects and objects. A label on an object is called a security classi-
cation, while a label on a user is called a security clearance. It is important to
understand that a Secret user may run the same program, such as a text editor, as
a Secret subject or as an Unclassied subject. Even though both subjects run the
same program on behalf of the same user, they obtain dierent privileges due to
their security labels. It is usually assumed that the security labels on subjects and
objects, once assigned, cannot be changed (except by the security o-cer). This
last assumption, that security labels do not change, is known as tranquillity. (Non-
tranquil LBAC can also be simulated in RBAC96 but is outside the scope of this
paper.) The security labels form a lattice structure as dened below.
Definition 2. (Security Lattice) There is a nite lattice of security labels SC
with a partially ordered dominance relation  and a least upper bound operator. 2
An example of a security lattice is shown in Figure 2. Information is only permitted
to
ow upward in the lattice. In this example, H and L respectively denote high
and low, and M1 and M2 are two incomparable labels intermediate to H and L.
This is a typical condentiality lattice where information can
ow from low to high
but not vice versa.
The specic mandatory access rules usually specied for a lattice are as follows,
where  signies the security label of the indicated subject or object.
Definition 3. (Simple Security Property) Subject s can read object
if
Definition 4. (Liberal ?-property) Subject s can write object
(o). 2
The ?-property is pronounced as the star-property. For integrity reasons sometimes
a stricter form of the ?-property is stipulated. The liberal ?-property allows a low
subject to write a high object. This means that high data may be maliciously or
accidently destroyed or damaged by low subjects. To avoid this possibility we can
employ the strict ?-property given below.
Definition 5. (Strict ?-property) Subject s can write object
(o). 2
Conguring RBAC to Enforce MAC and DAC  7
Fig. 2. A Partially Ordered Lattice
The liberal ?-property is also referred to as write-up and the strict ?-property as
non-write-up or write-equal.
In variations of LBAC the simple-security property is usually left unchanged as
we will do in all our examples. Variations of the ?-property in LBAC whereby the
one-directional information
ow is partly relaxed to achieve selective downgrading
of information or for integrity applications [Bell 1987; Lee 1988; Schockley 1988]
will be considered later.
4. CONFIGURING RBAC FOR LBAC
We now show how dierent variations of LBAC can be simulated in RBAC96. It
turns out that we can achieve this by systematically changing the role hierarchy and
dening appropriate constraints. This suggests that role hierarchies and constraints
are central to dening policy in RBAC96.
4.1 A Basic Lattice
We begin by considering the example lattice of Figure 2 with the liberal ?-property.
Subjects with labels higher up in the lattice have more power with respect to read
operations but have less power with respect to write operations. Thus this lattice
has a dual character. In role hierarchies subjects (sessions) with roles higher in
the hierarchy always have more power than those with roles lower in the hierarchy.
To accommodate the dual character of a lattice for LBAC we will use two dual
hierarchies in RBAC96, one for read and one for write. These two role hierarchies
for the lattice of Figure 2 are shown in Figure 3(a). Each lattice label x is modeled
as two roles xR and xW for read and write at label x respectively. The relationship
among the four read roles and the four write roles is respectively shown on the left
and right hand sides of Figure 3(a). The duality between the left and right lattices
is obvious from the diagrams.
To complete the construction we need to enforce appropriate constraints to re
ect
the labels on subjects in LBAC. Each user in LBAC has a unique security clearance.
This is enforced by requiring that each user in RBAC96 is assigned to exactly two
roles xR and LW. An LBAC user can login at any label dominated by the user's
clearance. This requirement is captured in RBAC96 by requiring that each session
has exactly two matching roles yR and yW. The condition that x  y, that is the
8  Osborn, Sandhu and Munawer
HR
LR
M1R M2R M1W M2W
(a) Liberal ?-Property
HR
LR
M1R M2R HW LW M2W
(b) Strict ?-Property
Fig. 3. Role Hierarchies for the Lattice of Figure 2
user's clearance dominates the label of any login session established by the user, is
not explicitly required because it is directly imposed by the RBAC96 construction.
Note that, by virtue of membership in LW, each user can activate any write role.
However, the write role activated in a particular session must match the session's
read role. Thus, both the role hierarchy and constraints of RBAC96 are exploited
in this construction.
LBAC is enforced in terms of read and write operations. In RBAC96 this means
our permissions are read and writes on individual objects written as (o,r) and (o,w)
respectively. An LBAC object has a single sensitivity label associated with it.
This is expressed in RBAC96 by requiring that each pair of permissions (o,r) and
(o,w) be assigned to exactly one matching pair of xR and xW roles respectively.
By assigning permissions (o,r) and (o,w) to roles xR and xW respectively, we are
implicitly setting the sensitivity label of object o to x.
4.2 The General Construction
Based on the above discussion we have the following construction for arbitrary lattices
(actually the construction works for partial orders with a lower-most security
class). Given SC with security labels and partial order LBAC , an
equivalent RBAC96 system is given by:
Construction 1. (Liberal ?-Property)
|RH which consists of two disjoint role hierarchies. The rst role hierarchy consists
of the \read" roles fL and has the same partial order as LBAC ;
the second partial consists of the \write" roles fL and has a partial
order which is the inverse of LBAC .
Conguring RBAC to Enforce MAC and DAC  9
is an object in the systemg
|Constraint on UA: Each user is assigned to exactly two roles xR and LW where
x is the label assigned to the user and LW is the write role corresponding to the
lowermost security level according to LBAC
|Constraint on sessions: Each session has exactly two roles yR and yW
|Constraints on PA:
|(o,r) is assigned to xR i (o,w) is assigned to xW
|(o,r) is assigned to exactly one role xR such that x is the label of
Theorem 1. An RBAC96 system dened by Construction 1 satises the Simple
Security Property and the Liberal ?-Property.
Proof: (a) Simple Security Property: Subjects in the LBAC terminology correspond
to RBAC96 sessions. For subject s to read o, (o,r) must be in the permissions
assigned to a role, either directly or indirectly, which is among the roles available
to session s, which corresponds to exactly one user u. For u to be involved in this
session, this role must be in the UA for u (either directly or indirectly). Let
z and y. By the constraints on PA given in Construction 1, (o,r) is assigned
directly to exactly one role xR, where and by the construction of RH, is
inherited by roles yR such that y LBAC x. For s to be able to read o, it must have
one of these yR in its session. By the denition of roles in a session from Denition
1, any role junior to zR can be in a session for u, i.e. z LBAC y. In other words, a
session for u can involve one reading role yR such that z LBAC y. Therefore, the
RBAC96 system dened above allows subject s to read object
and which is precisely the Simple Security Property.
(b) Liberal ?-Property: Each user, u, is assigned by UA to xR, where x is the
clearance of the user. According to LBAC, the user can read data classied at
level x or at levels dominated by x. It also means that the user can start a session
at a level dominated by x. So, if a user cleared to say level x, wishes to run a
session at level y, such that x LBAC y, the constraints in Construction 1 allow
the session to have the two active roles yR and yW. Because every user is assigned
to LW, it is possible for every user to have a session with yW as one of its roles.
The structure of the two role hierarchies means that if the yW role is available to
a user in a session, the user can write objects for which the permission (o,w) is in
yW. By construction of the role hierarchy, the session can write to level y or levels
dominated by y. In LBAC terms, the subject, s, corresponds to the session, and
within a session a write can be performed if (o,w) is in the permissions of a role,
which by the construction is only if (o) LBAC (s). This is precisely the Liberal
?-Property.4.3 LBAC Variations
Variations in LBAC can be accommodated by modifying this basic construction in
dierent ways. In particular, the strict ?-property retains the hierarchy on read
roles but treats write roles as incomparable to each other as shown in Figure 3(b)
for the example of our basic lattice.
Construction 2. (Strict ?-Property) Identical to construction 1 except RH
has a partial order among the read roles identical to the LBAC partial order, and
no relationships among the write roles. 2
Theorem 2. An RBAC96 system dened by Construction 2 satises the Simple
Security Property and the Strict ?-Property.
The proof of this and subsequent similar results is omitted.
Next we consider a version of LBAC in which subjects are given more power than
allowed by the simple security and ?-properties [Bell 1987]. The basic idea is to
allow subjects to violate the ?-property in a controlled manner. This is achieved
by associating a pair of security labels  r and w with each subject (objects still
have a single security label). The simple security property is applied with respect
to  r and the liberal ?-property with respect to w . In the LBAC model of [Bell
1987] it is required that  r should dominate w . With this constraint the subject
can read and write in the range of labels between  r and w which is called the
trusted range. If  r and w are equal the model reduces to the usual LBAC model
with the trusted range being a single label.
The preceding discussion is remarkably close to our RBAC constructions. The
two labels  r and w correspond directly to the two roles xR and yW we have
introduced earlier. The dominance required between  r and w is trivially recast
as a dominance constraint between x and y. This leads to the following construction:
Construction 3. (Liberal ?-Property with Trusted Range) Identical to construction
|Constraint on UA: Each user is assigned to exactly two roles xR and yW such
that x  y in the original lattice
|Constraint on sessions: Each session has exactly two roles xR and yW such that
x  y in the original lattice 2
Lee [1988] and Schockley [1988] have argued that the Clark-Wilson integrity
model [Clark and Wilson 1987] can be supported using LBAC. Their models are
similar to the above except that no dominance relation is required between x and y.
Thus the write range may be completely disjoint with the read range of a subject.
This is easily expressed in RBAC96 as follows.
Construction 4. (Liberal ?-Property with Independent Write Range) Identical
to construction 3 except x  y is not required in the constraint on UA and the
constraint on sessions. 2
A variation of the above is to use the strict ?-property as follows.
Construction 5. (Strict ?-Property with Designated Write) Identical to construction
|Constraint on UA: Each user is assigned to exactly two roles xR and yW
|Constraint on sessions: Each session has exactly two roles xR and yW 2
Construction 5 can also be directly obtained from construction 4 by requiring the
strict ?-property instead of the liberal ?-property. Construction 5 can accommodate
Clark-Wilson transformation procedures as outlined by Lee [1988] and Schockley
Conguring RBAC to Enforce MAC and DAC  11
[1988]. (Lee and Schockley actually use the liberal ?-property in their constructions,
but their lattices are such that the constructions are more directly expressed in
terms of the strict ?-property.)
5. EXTENDING THE POSSIBLE RBAC CONFIGURATIONS
In the previous section, we looked at specic mappings of dierent kinds of LBAC to
an RBAC system with the same properties. In this section we examine whether or
not more arbitrary RBAC systems which do not necessarily follow the constructions
in Section 4 still satisfy LBAC properties. In order to do this, we assume that all
users and objects have security labels, and that permissions involve only reads and
writes.
In the previous discussion, all constructions created role hierarchies with disjoint
read and write roles. This is not strictly necessary; the role hierarchy in Figure 5
could be the construction for the strict ?-property with the following modications:
|Constraint on UA: Each user is assigned to all roles, xRW such that the clearance
the user dominates the security label x
|Constraint on sessions: Each session has exactly one role: yRW
|Constraints on PA:
|(o,r) is assigned to xR i (o,w) is assigned to xRW
|(o,r) is assigned to exactly one role xR 2
HR
LR
M1R M2R
Fig. 4. Alternate role hierarchy for Strict ?-property
Nevertheless, the structure of role hierarchies which do map to valid LBAC cong-
urations is greatly restricted, as the examples in Osborn [1997] show. For example,
a role with permissions to both read and write a high data object and a low data
object cannot be assigned to a high user as this would allow write down, and cannot
be assigned to a low user, as this would allow read up. If a role had only read
permissions for some objects classied at M1, and other objects classied at M2 (cf

Figure

2), a subject cleared at H could be assigned to this role.
As far as the read operation is concerned, a subject can have a role r in its session
if the label of the subject dominates the level of all o such that (o,r) is in the role.
Since the least upper bound is dened for the security lattice, this can always be
determined. Similarly, for write operations, if a greatest lower bound is dened for
the security levels, then the Liberal ?-property is satised in a session if the security
level of the subject dominates the greatest lower bound of all o such that (o,w) is
in the role. If such a greatest lower bound does not exist, such a role should not be
in any user's UA. (If it could be determined that (s)  (o) for all o such that
(o,w) is in the role, then this (s) would be a lower bound, and then a greatest
lower bound would exist.)
We introduce the following two denitions to capture the maximum read level of
objects in a role, and the minimum write level if one exists.
Definition 6. The r-level of a role r (denoted r-level(r)) is the least upper
bound (lub) of the security levels of the objects for which (o,r) is in the permissions
of r.
Definition 7. The w-level of a role r (denoted w-level(r)) is the greatest lower
bound (glb) of the security levels of the objects o for which (o,w) is in the permissions
of r, if such a glb exists. If the glb does not exist, the w-level is undened.
The following theorem follows from these denitions.
Theorem 3. An RBAC96 conguration satises the simple security property
and the Liberal ?-Property if all of the following hold:
|Constraint on Users: ((8u 2 U) [(u) is given])
|Constraints on Permissions:
is an object in the systemg
|Constraint on UA:
|Constraint on Sessions:
An example showing a possible role hierarchy is given in Figure 5, where the
underlying security lattice contains labels funclassied, secret, top secretg and roles
are indicated by, for example, (ru,rs) meaning the permissions in the role include
read of some unclassied and some secret object(s) (each role may have permissions
inherited because of the role hierarchy). The roles labeled ru1 and ru3 at the
bottom have read access to distinct objects labeled unclassied; ru2 inherits the
permissions of ru1 and has additional read access to objects at the unclassied level.
The role labeled (ru,ws) contains permission to read some unclassied objects and
some secret objects. This role could be assigned in UA to either unclassied
users or to secret users. Notice the role at the top of the role hierarchy, labeled
(ru,rs,rts,ws,wts). This role cannot be assigned to any user without violating either
Conguring RBAC to Enforce MAC and DAC  13
the Simple Security Property or the Liberal-? Property. Note that if this role
is deleted from the role hierarchy, we have an example of a role hierarchy which
satises the Simple Security Property and the Liberal-? Property, and which does
not conform to any of the constructions of Section 4.
Not valid in any
User Assignment
ru,rs
In UA for
unclassified
users
ru,ws
ws,wts
ws
ru,rs
ws
ru,rs
ws,wts
In UA for Top-
Users
ru,rs,rts
ws,wts
ru,rs,rts
users
In UA for
Fig. 5. A Role Hierarchy and its User Assignments
An RBAC96 conguration satises the strict ?-property if all of the above conditions
hold, changing the Constraint on Sessions to:
|Constraint on Sessions: (8s 2 sessions)
6. DAC MODELS
In this section we discuss the DAC policies that will be considered in this paper.
The central idea of DAC is that the owner of an object, who is usually its creator,
has discretionary authority over who else can access that object. In other words the
core DAC policy is owner-based administration of access rights. There are many
variations of DAC policy, particularly concerning how the owner's discretionary
power can be delegated to other users and how access is revoked. This has been
recognized since the earliest formulations of DAC [Lampson 1971; Graham and
Denning 1972].
14  Osborn, Sandhu and Munawer
Our approach here is to identify major variations of DAC and demonstrate their
construction in RBAC96. The constructions are such that it will be obvious how
they can be extended to handle other related DAC variations. This is an intuitive,
but well-founded, justication for the claim that DAC can be simulated in RBAC. 2
The DAC policies we consider all share the following characteristics.
|The creator of an object becomes its owner.
|There is only one owner of an object. In some cases ownership remains xed
with the original creator, whereas in other cases it can be transferred to another
user. (This assumption is not critical to our constructions. It will be obvious
how multiple owners could be handled.)
|Destruction of an object can only be done by its owner.
With this in mind we now dene the following variations of DAC with respect to
granting of access.
(1) Strict DAC requires that the owner is the only one who has discretionary
authority to grant access to an object and that ownership cannot be transferred.
For example, suppose Alice has created an object (Alice is owner of the object)
and grants read access to Bob. Strict DAC requires that Bob cannot propagate
access to the object to another user. (Of course, Bob can copy the contents
of Alice's object into an object that he owns, and then propagate access to
the copy. This is why DAC is unable to enforce information
ow controls,
particularly with respect to Trojan Horses.)
(2) Liberal DAC allows the owner to delegate discretionary authority for granting
access to an object to other users. We dene the following variations of liberal
DAC.
(a) One Level Grant: The owner can delegate grant authority to other users
but they cannot further delegate this power. So Alice being the owner of
object O can grant access to Bob who can grant access to Charles. But
Bob cannot grant Charles the power to further grant access to Dorothy.
(b) Two Level Grant: In addition to a one-level grant the owner can allow
some users to further delegate grant authority to other users. Thus, Alice
can now authorize Bob for two-level grants, so Bob can grant access to
Charles, with the power to further grant access to Dorothy. However, Bob
cannot grant the two-level grant authority to Charles. (We could consider
n-level grant but it will be obvious how to do this from the two level
construction.)
(c) Multilevel Grant: In this case the power to delegate the power to grant
implies that this authority can itself be delegated. Thus Alice can authorize
Bob, who can further authorize Charles, who can further authorize
Dorothy, and so on indenitely.
(3) DAC with Change of Ownership: This variation allows a user to transfer
ownership of an object to another user. It can be combined with strict or liberal
DAC in all the above variations.
2 A formal proof would require a formal denition of DAC encompassing all its variations, and a
construction to handle all of these in RBAC96. This approach is pursued in [Munawer 2000].
Conguring RBAC to Enforce MAC and DAC  15
For revocation we consider two cases as follows.
(1) Grant-Independent Revocation: Revocation is independent of the granter.
Thus Bob may be granted access by Alice but have it revoked by Charles.
(2) Grant-Dependent Revocation: Revocation is strongly tied to the granter.
Thus if Bob receives access from Alice, access can only be revoked by Alice.
In our constructions we will initially assume grant-independent revocation and then
consider how to simulate grant-dependent revocation. In general, we will also assume
that anyone with authority to grant also has authority to revoke. This coupling
often occurs in practice. Where appropriate, we can decouple these in our
simulations because, as we will see, they are represented by dierent permissions.
These DAC policies certainly do not exhaust all possibilities. Rather these are
representative policies whose simulation will indicate how other variations can also
be handled.
7. CONFIGURING RBAC FOR DAC
To specify the above variations in RBAC96 it su-ces to consider DAC with one
operation, which we choose to be the read operation. Similar constructions for
other operations such as write, execute and append, are easily possible. 3 Before
considering specic DAC variations, we rst describe common aspects of our constructions

7.1 Common Aspects
The basic idea in our constructions is to simulate the owner-centric policies of DAC
using roles that are associated with each object.
7.1.1 Create an Object. For every object O that is created in the system we
require the simultaneous creation of three administrative roles and one regular role
as follows.
|Three administrative roles in AR: OWN O, PARENT O and PARENTwith-
GRANT O
|One regular role in R: READ O
Role OWN O has privileges to add and remove users from the role PAREN-
TwithGRANT O which in turn has privileges to add and remove users from the
role PARENT O The relationship between these roles is shown in Figure 6. In

Figure

administrative roles are shown with darker circles than regular roles. In

Figure

6(a), the dashed right arrows indicate that the role on the left contains the
administrative permissions governing the role on the right. Figure 6(b) shows the
administrative role hierarchy, with the senior role above its immediate junior, connected
by an edge. For instance role OWN O has administrative authority over
roles PARENTwithGRANT O as indicated in gure 6(a). In addition due to the
3 More complex operations such as copy can be viewed as a read of the original object and a write
(and possibly creation) of the copy. It can be useful to associate some default permissions with
the copy. For example, the copy may start with access related to that of the original object or
it may start with some other default. Specic policies here could be simulated by extending our
constructions.
inheritance via the role hierarchy of gure 6(a) OWN O also has administrative
authority over PARENT O and READ O.
OWN_O READ_O
(a)
OWN_O
PARENTwithGRANT_O
PARENT_O
(b)
PARENT_O
PARENTwithGRANT_O
Fig. 6. (a)Administration of roles associated with an object (b) Administrative role hierarchy
In addition we require simultaneous creation of the following eight permissions
along with creation of each object O.
|canRead O: authorizes the read operation on object O. It is assigned to the role
READ O.
|destroyObject O: authorizes deletion of the object. It is assigned to the role
OWN O.
|addReadUser O, deleteReadUser O: respectively authorize the operations to add
users to the role READ O and remove them from this role. They are assigned to
the role PARENT O.
|addParent O, deleteParent O: respectively authorize the operations to add users
to the role PARENT O and remove them from this role. They are assigned to
the role PARENTwithGRANT O.
|addParentWithGrant O, deleteParentWithGrant O: respectively authorize the
operations to add users to the role PARENT O and remove them from this role.
They are assigned to the role OWN O.
These permissions are assigned to the indicated roles when the object is created
and thereafter they cannot be removed from these roles or assigned to other roles.
7.1.2 Destroy an Object. Destroying an object O requires deletion of the four
roles namely OWN O, PARENT O, PARENTwithGRANT O and READ O and
the eight permissions (in addition to destroying the object itself). This can be done
only by the owner, by virtue of exercising the destroyObject O permission.
Conguring RBAC to Enforce MAC and DAC  17
7.2 Strict DAC
In strict DAC only the owner can grant/revoke read access to/from other users.
The creator is the owner of the object. By virtue of membership (via seniority) in
PARENT O and PARENTwithGRANT O, the owner can change assignments of
the role READ O. Membership of the three administrative roles cannot change, so
only the owner will have this power. This policy can be enforced by imposing a
cardinality constraint of 1 on OWN O and of 0 on PARENT O and PARENTwith-
GRANT O.
This policy could be simulated using just two roles OWN O and READ O, and
giving the addReadUser O and deleteReadUser O permissions directly to OWN O
at creation of O. For consistency with subsequent variations we have introduced all
required roles from the start.
7.3 Liberal DAC
The three variations of liberal DAC described in Section 6 are now considered in
turn.
7.3.1 One-Level Grant. The one-level grant DAC policy can be simulated by
removing the cardinality constraint of strict DAC on membership in PARENT O.
The owner can assign users to the PARENT O role who in turn can assign users to
the READ O role. But the cardinality constraint of 0 on PARENTwithGRANT O
remains.
7.3.2 Two-Level Grant. In the two level grant DAC policy the cardinality constraint
on PARENTwithGRANT O is also removed. Now the owner can assign
users to PARENTwithGRANT O who can further assign users to PARENT O.
Note that members of PARENTwithGRANT O can also assign users directly to
READ O, so they have discretion in this regard. Similarly the owner can assign
users to PARENTwithGRANT O, PARENT O or READ O as deemed appropri-
ate. (N-level grants can be similarly simulated by having N roles, PARENTwith-
GRANT O N 1 , PARENTwithGRANT O N 2 , . , PARENTwithGRANT O, PARENT
O.)
7.3.3 Multilevel Grant. To grant access beyond two levels we authorize the role
PARENTwithGRANT O to assign users to PARENTwithGRANT O. We achieve
this by assigning the addParentWithGrant O permission to the role PARENTwith-
GRANT O when object O is created. As per our general policy of coupling grant
and revoke authority, we also assign the deleteParentWithGrant O permission to
the role PARENTwithGRANT O when O is created. This coupling policy is arguably
unreasonable in the context of grant-independent revoke, so the deletePar-
entWithGrant O permission could be retained only with the OWN O role if so
desired. For grant-dependent revoke the coupling is more reasonable.
7.4 DAC with Change of Ownership
Change of ownership can be easily accomplished by suitable redenition of the administrative
authority of a member of OWN O. Recall that change of ownership
in this context means transfer of ownership from one user to another. Thus the
OWN O role needs a permission that enables this transfer to occur and this per-
mission can only be assigned to this role. A member of OWN O can assign another
user to OWN O but at the cost of loosing their own membership.
7.5 Multiple Ownership
Multiple ownership can also be accommodated by removing the cardinality constraint
on membership in the OWN O role. Since all members of OWN O have
identical power, including the ability to revoke other owners, it would be appropriate
with grant-independent revoke to distinguish the original owner. Alternately,
we can have grant-dependent revoke of ownership.
7.6 Grant-Dependent Revoke
So far we have considered grant-independent revocation where revocation is independent
of granter. Now nally we consider how to simulate grant-dependent
revoke in RBAC96. In this case only the user who has granted access to another
user can revoke the access (with possible exception of the owner who is allowed to
revoke everything).
U1_PARENT_O
U2_PARENT_O
Un_PARENT_O
U1_READ_O
U2_READ_O
Un_READ_O
Fig. 7. Read O Roles associated with members of PARENT O
Specically, let us consider the one level grant DAC policy simulated earlier
by allowing members of PARENT O role to assign users to READ O role. To
simulate grant-dependent revocation with this one level grant policy we need a
dierent administrative role U PARENT O and a dierent regular role U READ O
for each user U authorized to do a one-level grant by the owner. These roles are
automatically created when the owner authorizes user U. We also need two new
administrative permissions created at the same time as follows.
|addU ReadUser O, deleteU ReadUser O: respectively authorize the operations
to add users to the role U READ O and remove them from this role. They are
assigned to the role U PARENT O.
Conguring RBAC to Enforce MAC and DAC  19
Ui PARENT O manages the membership assignments of Ui READ O role as indicated
in Figure 7 for user Ui. U PARENT O has a membership cardinality constraint
of one. Moreover, its membership cannot be changed. Thus user U will be
the only one granting and revoking users from U READ O. The U READ O role
itself is assigned the permission canRead O at the moment of creation. As before
all of this enforced by RBAC96 constraints. We can allow the owner to revoke
users from the U READ O role by making U PARENT O junior to OWN O in
the administrative role hierarchy. Simulation of grant-dependent revocation can be
similarly simulated with respect to the PARENT O and PARENTwithGRANT O
roles. Extension to multiple ownership is also possible.
8. CONCLUSIONS
We have shown that the common forms of LBAC and DAC models can be simulated
and enforced in RBAC96 with systematic constructions. All of the components of
the RBAC96 model shown in Figure 1 were required to carry out these simulations.
Users and permissions are essential to express any access control model. The Role
Hierarchy is important in the LBAC simulation. The Administrative Role Hierarchy
is essential in the enforcement of DAC policies, as is the administrative user to role
assignment relation. We observe however that the permissions that have been
granted to users in a DAC system can give an arbitrarily rich role hierarchy, as was
noted in a conversion of relational database permissions to role graphs by Osborn,
Reid, and Wesson [1996]. Constraints play a role in all of the constructions. It is
important to note that the LBAC simulation assumes a single administrative role,
whereas the DAC simulation requires a large number of administrative roles, which
are dynamically created and destroyed.
RBAC Models
One Administrative Role Complex Administrative Roles
of Section 7
of Section 4
of Section 5
a. LBAC construction
b. other LBAC configurations
c. DAC configurations
Fig. 8. Containment of Models
We can represent some of our ndings using the Venn diagram in Figure 8. The
20  Osborn, Sandhu and Munawer
area on the left of the gure indicates that in this subset of RBAC96 congurations,
there is no need for administrative roles except for an assumed single administrative
role. On the right, the administrative part of the RBAC96 model is fully utilized.
Part (a) represents the subset of possible RBAC96 congurations which are built
by constructions 1 and 2. Area (b) shows that there are other congurations not
built by these two constructions which still satisfy LBAC properties. Part (c) of
the diagram represents in general the RBAC96 congurations built by the various
constructions in Section 7. Note that these latter constructions all fall in the region
where the administrative roles of the RBAC96 model are being fully utilized.
Future work should now focus on what happens in the rest of the RBAC96
Models not included in the areas constructed in this paper. Models for decentralized
role administration which fall in between these extremes have been proposed by
Sandhu, Bhamidipati, and Munawer [1999]. These models allow for large numbers
of administrative roles but this number is expected to be much smaller than the
number of objects in the system.
In conclusion, then, we have shown with various systematic constructions how to
simulate and enforce traditional LBAC and DAC access control models in RBAC96.



--R

Secure computer systems: A network interpretation.
A comparison of commercial and military computer security policies.
A lattice model of secure information ow.


Using mandatory integrity to enforce
Administrative Models for Role-Based Access Control
Access rights administration in role-based security systems
Modeling mandatory access control in role-based security systems
The role graph model and con ict of interest.
Mandatory access control and role-based access control revisited
On the interaction between role based access control and relational databases.


Role hierarchies and constraints for lattice-based access controls
The ARBAC97 model for role-based administration of roles

How to do discretionary access control using roles.
Access control: Principles and practice.

Implementing the Clark/Wilson integrity policy using current tech- nology
--TR
Role-Based Access Control Models
Modeling mandatory access control in role-based security systems
Mandatory access control and role-based access control revisited
On the interaction between role-based access control and relational databases
How to do discretionary access control using roles
The role graph model and conflict of interest
The ARBAC97 model for role-based administration of roles
A lattice model of secure information flow
Lattice-Based Access Control Models
Access Rights Administration in Role-Based Security Systems
Role Hierarchies and Constraints for Lattice-Based Access Controls
Administrative models for role-based access control

--CTR
Sylvia L. Osborn, Information flow analysis of an RBAC system, Proceedings of the seventh ACM symposium on Access control models and technologies, June 03-04, 2002, Monterey, California, USA
Cungang Yang , Chang N. Zhang, An approach to secure information flow on Object Oriented Role-based Access Control model, Proceedings of the ACM symposium on Applied computing, March 09-12, 2003, Melbourne, Florida
James B. D. Joshi , Rafae Bhatti , Elisa Bertino , Arif Ghafoor, Access-Control Language for Multidomain Environments, IEEE Internet Computing, v.8 n.6, p.40-50, November 2004
Rafae Bhatti , Elisa Bertino , Arif Ghafoor , James B. D. Joshi, XML-Based Specification for Web Services Document Security, Computer, v.37 n.4, p.41-49, April 2004
Gail-Joon Ahn , Ravi Sandhu, Role-based authorization constraints specification, ACM Transactions on Information and System Security (TISSEC), v.3 n.4, p.207-226, Nov. 2000
Rafae Bhatti , James Joshi , Elisa Bertino , Arif Ghafoor, X-GTRBAC admin: a decentralized administration model for enterprise wide access control, Proceedings of the ninth ACM symposium on Access control models and technologies, June 02-04, 2004, Yorktown Heights, New York, USA
James B D Joshi , Elisa Bertino , Arif Ghafoor, Temporal hierarchies and inheritance semantics for GTRBAC, Proceedings of the seventh ACM symposium on Access control models and technologies, June 03-04, 2002, Monterey, California, USA
Marian Ventuneac , Tom Coffey , Ioan Salomie, A policy-based security framework for Web-enabled applications, Proceedings of the 1st international symposium on Information and communication technologies, September 24-26, 2003, Dublin, Ireland
Sejong Oh , Ravi Sandhu, A model for role administration using organization structure, Proceedings of the seventh ACM symposium on Access control models and technologies, June 03-04, 2002, Monterey, California, USA
Sylvia Osborn, Integrating role graphs: a tool for security integration, Data & Knowledge Engineering, v.43 n.3, p.317-333, December 2002
Ravi Sandhu , David Ferraiolo , Richard Kuhn, The NIST model for role-based access control: towards a unified standard, Proceedings of the fifth ACM workshop on Role-based access control, p.47-63, July 26-28, 2000, Berlin, Germany
Sejong Oh , Ravi Sandhu , Xinwen Zhang, An effective role administration model using organization structure, ACM Transactions on Information and System Security (TISSEC), v.9 n.2, p.113-137, May 2006
Roberto Di Pietro , Luigi V. Mancini, Security and privacy issues of handheld and wearable wireless devices, Communications of the ACM, v.46 n.9, p.74-79, September
Engineering authority and trust in cyberspace: the OM-AM and RBAC way, Proceedings of the fifth ACM workshop on Role-based access control, p.111-119, July 26-28, 2000, Berlin, Germany
Manuel Koch , Luigi V. Mancini , Francesco Parisi-Presicce, A graph-based formalism for RBAC, ACM Transactions on Information and System Security (TISSEC), v.5 n.3, p.332-365, August 2002
Wolfgang Essmayr , Stefan Probst , Edgar Weippl, Role-Based Access Controls: Status, Dissemination, and Prospects for Generic Security Mechanisms, Electronic Commerce Research, v.4 n.1-2, p.127-156, January-April 2004
David F. Ferraiolo , Serban Gavrila , Vincent Hu , D. Richard Kuhn, Composing and combining policies under the policy machine, Proceedings of the tenth ACM symposium on Access control models and technologies, June 01-03, 2005, Stockholm, Sweden
Jason Crampton, On permissions, inheritance and role hierarchies, Proceedings of the 10th ACM conference on Computer and communications security, October 27-30, 2003, Washington D.C., USA
Yang , Raimund K. Ege , Huiqun Yu, Mediation security specification and enforcement for heterogeneous databases, Proceedings of the 2005 ACM symposium on Applied computing, March 13-17, 2005, Santa Fe, New Mexico
James B. D. Joshi , Elisa Bertino , Usman Latif , Arif Ghafoor, A Generalized Temporal Role-Based Access Control Model, IEEE Transactions on Knowledge and Data Engineering, v.17 n.1, p.4-23, January 2005
Patrick C. K. Hung , Dickson K. W. Chiu , W. W. Fung , William K. Cheung , Raymond Wong , Samuel P. M. Choi , Eleanna Kafeza , James Kwok , Jousha C. C. Pun , Vivying S. Y. Cheng, Towards end-to-end privacy control in the outsourcing of marketing activities: a web service integration solution, Proceedings of the 7th international conference on Electronic commerce, August 15-17, 2005, Xi'an, China
Siqing Du , James B. D. Joshi, Supporting authorization query and inter-domain role mapping in presence of hybrid role hierarchy, Proceedings of the eleventh ACM symposium on Access control models and technologies, June 07-09, 2006, Lake Tahoe, California, USA
W. T. Tsai , X. Liu , Y. Chen , R. Paul, Simulation Verification and Validation by Dynamic Policy Enforcement, Proceedings of the 38th annual Symposium on Simulation, p.91-98, April 04-06, 2005
James B. D. Joshi , Basit Shafiq , Arif Ghafoor , Elisa Bertino, Dependencies and separation of duty constraints in GTRBAC, Proceedings of the eighth ACM symposium on Access control models and technologies, June 02-03, 2003, Como, Italy
Mahesh V. Tripunitara , Ninghui Li, Comparing the expressive power of access control models, Proceedings of the 11th ACM conference on Computer and communications security, October 25-29, 2004, Washington DC, USA
Jingzhu Wang , Sylvia L. Osborn, A role-based approach to access control for XML databases, Proceedings of the ninth ACM symposium on Access control models and technologies, June 02-04, 2004, Yorktown Heights, New York, USA
James B. D. Joshi , Elisa Bertino, Fine-grained role-based delegation in presence of the hybrid role hierarchy, Proceedings of the eleventh ACM symposium on Access control models and technologies, June 07-09, 2006, Lake Tahoe, California, USA
Jason Crampton , George Loizou, Administrative scope: A foundation for role-based administrative models, ACM Transactions on Information and System Security (TISSEC), v.6 n.2, p.201-231, May
David F. Ferraiolo, An argument for the role-based access control model, Proceedings of the sixth ACM symposium on Access control models and technologies, p.142-143, May 2001, Chantilly, Virginia, United States
Timothy Fraser , David Ferraiolo , Mikel L. Matthews , Casey Schaufler , Stephen Smalley , Robert Watson, Panel: which access control technique will provide the greatest overall benefit, Proceedings of the sixth ACM symposium on Access control models and technologies, p.141-149, May 2001, Chantilly, Virginia, United States
Basit Shafiq , James B. D. Joshi , Elisa Bertino , Arif Ghafoor, Secure Interoperation in a Multidomain Environment Employing RBAC Policies, IEEE Transactions on Knowledge and Data Engineering, v.17 n.11, p.1557-1577, November 2005
Thuong Doan , Steven Demurjian , T. C. Ting , Andreas Ketterl, MAC and UML for secure software design, Proceedings of the 2004 ACM workshop on Formal methods in security engineering, October 29-29, 2004, Washington DC, USA
Shih-Chien Chou , Yuan-Chien Chen, Managing role relationships in an information flow control model, Journal of Systems and Software, v.79 n.4, p.507-522, April 2006
Ravi Sandhu , Kumar Ranganathan , Xinwen Zhang, Secure information sharing enabled by Trusted Computing and PEI models, Proceedings of the 2006 ACM Symposium on Information, computer and communications security, March 21-24, 2006, Taipei, Taiwan
Elisa Bertino , Piero Andrea Bonatti , Elena Ferrari, TRBAC: A temporal role-based access control model, ACM Transactions on Information and System Security (TISSEC), v.4 n.3, p.191-233, August 2001
Gustaf Neumann , Mark Strembeck, Design and implementation of a flexible RBAC-service in an object-oriented scripting language, Proceedings of the 8th ACM conference on Computer and Communications Security, November 05-08, 2001, Philadelphia, PA, USA
Vugranam C. Sreedhar, Data-centric security: role analysis and role typestates, Proceedings of the eleventh ACM symposium on Access control models and technologies, June 07-09, 2006, Lake Tahoe, California, USA
James B. D. Joshi , Elisa Bertino , Arif Ghafoor, An Analysis of Expressiveness and Design Issues for the Generalized Temporal Role-Based Access Control Model, IEEE Transactions on Dependable and Secure Computing, v.2 n.2, p.157-175, April 2005
Yanjun Zuo , Brajendra Panda, Component based trust management in the context of a virtual organization, Proceedings of the 2005 ACM symposium on Applied computing, March 13-17, 2005, Santa Fe, New Mexico
Ting Yu , Divesh Srivastava , Laks V. S. Lakshmanan , H. V. Jagadish, A compressed accessibility map for XML, ACM Transactions on Database Systems (TODS), v.29 n.2, p.363-402, June 2004
Shih-Chien Chou, Providing flexible access control to an information flow control model, Journal of Systems and Software, v.73 n.3, p.425-439, November-December 2004
Lawrence A. Gordon , Martin P. Loeb, The economics of information security investment, ACM Transactions on Information and System Security (TISSEC), v.5 n.4, p.438-457, November 2002
Shih-Chien Chou , Chin-Yi Chang, An information flow control model for C applications based on access control lists, Journal of Systems and Software, v.78 n.1, p.84-100, October 2005
Rafae Bhatti , Arif Ghafoor , Elisa Bertino , James B. D. Joshi, X-GTRBAC: an XML-based policy specification framework and architecture for enterprise-wide access control, ACM Transactions on Information and System Security (TISSEC), v.8 n.2, p.187-227, May 2005
Charles E. Phillips, Jr. , T.C. Ting , Steven A. Demurjian, Information sharing and security in dynamic coalitions, Proceedings of the seventh ACM symposium on Access control models and technologies, June 03-04, 2002, Monterey, California, USA
Shih-Chien Chou, Embedding role-based access control model in object-oriented systems to protect privacy, Journal of Systems and Software, v.71 n.1-2, p.143-161, April 2004
David F. Ferraiolo , Ravi Sandhu , Serban Gavrila , D. Richard Kuhn , Ramaswamy Chandramouli, Proposed NIST standard for role-based access control, ACM Transactions on Information and System Security (TISSEC), v.4 n.3, p.224-274, August 2001
Joon S. Park , Ravi Sandhu , Gail-Joon Ahn, Role-based access control on the web, ACM Transactions on Information and System Security (TISSEC), v.4 n.1, p.37-71, Feb. 2001
W. T. Tsai , Yinong Chen , Ray Paul , Xinyu Zhou , Chun Fan, Simulation Verification and Validation by Dynamic Policy Specification and Enforcement, Simulation, v.82 n.5, p.295-310, May       2006
Katherine Campbell , Lawrence A. Gordon , Martin P. Loeb , Lei Zhou, The economic cost of publicly announced information security breaches: empirical evidence from the stock market, Journal of Computer Security, v.11 n.3, p.431-448, 1 March
mandatory access control;lattice-based access control;role-based access control;discretionary access control