This document discusses shortcomings of the ANSI RBAC standard and potential extensions to address those shortcomings. It identifies vagueness in key RBAC concepts like the notion of a role and role hierarchies. It also finds RBAC has limited expressiveness, failing to address things like usage control, negative authorization, temporal access, distributed access, and spatial access. Several extensions are proposed that could enhance RBAC, such as UCON/TUCON for usage control, SBAC for distributed access control, and TRBACN and DEBAC for introducing temporal and event-based constraints. The goal of these extensions is to make RBAC more richly expressive and applicable to dynamic distributed environments.

1. 1 Introduction
ampson[8] introduced some basic ideas about
discretionary access control(DAC) but has an
inherent weakness that information can be copied
from one object to another. It is difficult for DAC to
enforce a safety policy and protect against some
security attacks. Mandatory access control (MAC)
was invented in order to overcome the shortcomings
of DAC and to enforce lattice-based confidentiality
policies in the face of Trojan Horse attacks. Sandhu
et al[7] presented now standardized Role based
access control (RBAC), which was considered as a
promising alternative to resolve the shortcomings of
both DAC and MAC.
L
RBAC as model provides some merits and hence has
contributed to its widely use. It can easily mirror an
organization’s structure and encourage well-
structured access control policies. It provides a
powerful mechanism for reducing the complexity,
cost and potential errors of assigning users
permissions within the organization. It naturally
supports delegation of access permissions. The most
common method of implementing access control in a
computer system is through access control lists
(ACL). Despite the widely use and adoption of the
American National Standard Institute (ANSI) on
Role-Based Access Control (RBAC) in the
commercial arena, it still has some associated
limitations that needs to be confronted and resolved.
2 Short comings of RBAC
n this section, I will discuss some notable short
comings of RBAC. The identified short comings
of RBAC are collectively group into two groups
namely: vagueness and limited expressiveness. The
subsections below provides a thoroughly overlook of
these short comings.
I
Vagueness
RBAC standard is vague to some margin on the
following points :
● [Notion of Role:] Role in ANSI RBAC[11]
is established as a job function within the
context of an organisation with some
associated semantics regarding authority and
responsibility conferred on the user assigned
to the role ([11], p. 233). Role in RBAC is
not definitely established what it represents
and poses a lot of questions. Within an
organisational context, is a role just a job
function formally? or should a role be
understood functionally?. Is a role simply an
identifier for a particular type of ascribed
status? The name of a set (of role members?
Permissions?).
● [Hierarchy issues in RBAC:] Hierarchical
RBAC adds requirements for supporting role
hierarchies[11]. Demonstratively,
Hierarchical RBAC component defined
mathematically a partial order of seniority
relation between roles which seems to be
inappropriate when issues like update of
roles is taken into consideration. RBAC
1
his report provides a technical overview of RBAC(Role-Based Access Control) in the
sense of its short comings and the potential extensions that can be made to enhance
expressiveness and richness of RBAC's. Despite the widely use and adoption of the
American National Standard Institute (ANSI) on RBAC in the commercial arena, it still has some
associated problematic (limitations) that needs to be confronted and resolved. The report sorts not
to provide an alternative to RBAC but to bring to bear the enhancements that has been made. It is
also to provide a supplementary short and concise overlook of RBAC.
T
Author : Frank Appiah
Date : 26/10/10
Title : Overview of RBAC
Version : 1.0
©2010 All Rights Reserved.

2. failure to address this issue poses a
lot questions and puts a burden on
the development of an effective
administrative RBAC model. This
exposes the vagueness of ANSI
RBAC as a standard. According to
ANSI RBAC, partial order of
seniority between roles means that
senior roles acquire the permissions
of junior roles and junior roles
acquire the user membership of the senior
roles.
This poses the following questions:
1. Is this unconstrained upward inheritance
which violates least privilege?
2. Is role activation transitive?: When there
is no session then role activation does not
exit at all which even greatly affects the
notion of role activation (transitivity).
With Single Role Activation (SRA), only
one role activation in a session which
makes Role Activation (RA) transitivity
not applicable.
3. What is the correct semantics of SoD
(Separation of Duties) with inheritance?
The standard is unclear about the issues
and these are left as an implementation
issue with no one solution.
Limited Expressiveness
NSI RBAC as a standard failed to address the
expressiveness and richness of the model to
definitely establish how access control for some
different context aside the organisational picture
painted in the standard should be confronted. Below
are some of the few points to back the point of
limited expressiveness in RBAC:
A
● [No Usage Control:] In this global era,
digital objects are all around us and it is
important to allow privilege access with
consumable functionality to avoid abuse and
help protect the works of others. For
example, a payment made with your credit
card to buy a ticket to watch a movie can be
used only once at the cinema or a SaaS
provider can provide software for other
companies who have purchased a
consumable number of access that is
addressed either by decreasing their access
counter by 1 or increasing the cost by a
certain amount until the maximum is reached
which they have pay for. Controlling usage
of sensitive information requires protection
of digital information that may be important
to organisations and nations. Relatively,
Content Providers' interest belongs here also;
to maximize ROI(Return-on-Investment) to
run the company. RBAC as a standard did
not take into account how this kind of usage
control can be catered for in the scenario
described above. Usage access control does
not fall into RBAC's notion of job function
and organisational picture painted to us.
RBAC's failure to address this type of access
control has introduced a limited expressive
power into the model and its been a standard
is questionable, and needs an extension
possibly.
● [Negative authorisation:] RBAC failed to
express how negative authorisation should be
carried out and the ANSI RBAC claims to
satisfy the least privilege without addressing
how this concern poses a lot of questions that
it needs to be answered.
● [Limited Status Control:] The ANSI RBAC
model in a distributed sense fails to scale
because of the bottleneck introduced in the
model. The standard RBAC model assumed
a more relatively static access environment
which will be administered by human users,
with a complete knowledge of users, job
functions, qualifications and responsibilities,
and this tends not be available in a dynamic
distributed sense like ubiquitous system:
distributed sensor system for weather
forecasting. Barker[3] for example pointed
out that the model is also concerned with a
one-type ascribed status, an assignment of
user to a role. According to Barker, the
elements of RBAC makes it suitable for use
in the centralised case are not necessarily so
relevant in a certain distributed computing
2
Author : Frank Appiah
Date : 26/10/10
Title : Overview of RBAC
Version : 1.0
©2010 All Rights Reserved.OVERVIEWOFRBAC

3. context([3], p. 1:3).
● [Time and Triggered(Event-based)
access:] Temporal authorisation enables
Security Administrators to specify that a
user's permission to access resource is to
hold for a restricted time interval and
automatically expires as soon as the
maximum time point in the interval is
elapsed[6]. RBAC overlooked all the above
merits and failed to definitely establish how
this is to be catered for in different temporal
authorisation context that certain resources
would and should be accessed. For example,
the UK Visa Border Agency grants visas to
persons for a specify time interval specified
in date and resources that are accessible by
visa requester expires after that interval.
Without temporal authorisation, ANSI
RBAC is only feasible for fixed and always
accessible resources which tends not be
possible for all scenarios in real life. Clearly,
lack of temporal authorisation greatly
reduced the expressiveness of standard
RBAC model. RBAC does not allow
Security Administrators to express proactive
specifications because of the lack of
temporal constraints. In a distributed context,
entities requesting information from a
resource may not be known and also user
authorisation may change dynamically on the
basis of occurrence of wider range of events
other than the role and permission
assignments used in RBAC[9]. RBAC is
limited to express policies for a dynamic and
distributed environment. This contributes to
its limited expressive power.
● [No Spatial Control:] In the area of
pervasive and ubiquitous computing, location
information will be necessary to access
certain kind of information. With the
growing of wireless network and mobile
device like mobile phones, PDA's etc. Spatial
representation in RBAC is another head-on
battle that the implementer is the loser in this
war in the cyberspace.
3 Potential extensions of RBAC
or the shortcomings of the ANSI RBAC model
short listed in Section 2, I will discuss the
potential ways in which the ANSI RBAC model has
soundly been extended to address the shortcomings:
F
Addressing vagueness in RBAC
● [Notion of Role:] According Sandhu, Roles
in RBAC are (1) a set of users and (2) a set
of permissions. This is definition is a bit
more clearer because it at least keeps one of
the most important key of interest at any
point in time, set of permissions. The notion
of role can be extended to include that a role
is sometimes argued to be a set of privileges
whiles a group as a set of users.
● [Addressing hierarchy issues in RBAC:]
The ANSI RBAC standard should distinctly
clarify the difference between base relations
and derived relations by allowing only one of
user assignment and assigned users be
treated as a base relations which is allowed
to be updated by administrative functions. An
auxiliary derived function can be used to
specify other RBAC specifications. The
Reference Model can maintain a relation that
contains the role dominance relationships
that have been added and update this relation
when there is hierarchical changes in roles.
The standard can take up the notion of
private roles in RBAC role hierarchies.
Secondly, inheritable and non inheritable
permissions should be taken into account to
help resolve which permissions are deem for
inheritance by transitivity or not. Different
organizational structure demands different
solution to RBAC's role hierarchies but
downwards delegation of powers either by
grant or transfer via RBAC hierarchy based
on task would be desirable.
3
Author : Frank Appiah
Date : 26/10/10
Title : Overview of RBAC
Version : 1.0
©2010 All Rights Reserved.

4. Potential extensions to address
limited expressiveness
[No Usage Control:] In UCONABC[1], The UCON
model considers this temporal and consumed
attributes as the mutable attributes of subjects or
objects. The UCON model has unified traditional
access control models and temporal access models
with its ABC (Authorizations, Obligations and
Conditions) core models.
In TUCON[2], a further work on both temporal and
consumable authorisation was modelled to address
the issue of privilege consuming usage of digital
objects in the global context. It extends the
traditional usage control models with a temporal
constraint. In terms of usage of a digital object three
attributes are required for authorisation in TUCON
policy representation:
(1) Time Interval (2) Valid Period (3) Usage times[2]
Time Interval: It includes the starting and the ending
time.
Valid Period: An access to a resource is allowed
during the valid period of usage.
Usage Times: It is the maximum time an access to
the object is prohibited and revocation is carried out
automatically by the system.
TUCON carries out revocation on when (1) the time
interval of authorisation has expired and (2) the
usage times is zero during the ongoing usage of
digital objects.
TUCON can introduce temporal usage constraints
into RBAC to address the issue of usage control in
general. It would allow RBAC to also express time-
based authorisations. A times authorisation is a 6-
tuple. For example, an assertion( 6, James, Sun,
read, +, Bob) means that Bob authorizes 6 times
privilege read on the book Sun to James.
[Limited Status Control:] In S. Barker et al[3], a
distributed access control model based on status was
modelled to address the issue of the one-type
ascribed status and static access policies introduced
as a bottleneck because of the centralised
environment. The modelled status-based access
control for distributed access control is called
SBAC. It has a notion of an action status and an
ascribed status([3], page 1). The action status is
captured through a history of events in relation to the
user (requester). This history enables changing
access policy requirements to be naturally resolved
in a distributed environment([3], p. 1). Barker points
out an idea to status levels that are assigned to
agents that request access to system resources
(henceforth these agents are referred to as
requester agents).These status levels change
dynamically in response to the actions the
requester agent performs[3]. Clearly SBAC
can be introduced into the RBAC standard
as an extension and to confront the problems
that the standard failed to address. SBAC is
a formal, well defined model and provides a
basis for proving access control properties
that satisfies SBAC policy specification. It
supports meta-policy specification and
provides sanctioning in the form of automated
penalization by action demotion.
[Time and Triggered(Event-based) access:] In
TRBACN
[6] an approach based on ura and pra
specification can be use to model and introduce a
temporal constraint into RBAC as an extension.
TRBACN
claims that to specify a time interval for
which ura or rpa predicate holds, a conjunction of
linear constraints of time variable, T is used.
Illustratively, if a User, U is assigned to a role, R
from a point in time 20091212 (YYYMMDD) until
some point in the future 20091218 then TRBACN
will specify this using ura predicate with the T
conjunction as:
ura(u, r, T) <-- 20091212<= T, T <= 20091218.
Conversely to represent that a role, r has all the
permissions P on a resource, books from 20091112
to some point 20091201 in the future can be
represented by rpa predicate as:
rpa(r, P, books, T) <-- 20091112<=T,
T<=20091201.
RBAC's role hierarchy is represented with a senior-
to and d-s relation. A role R1 in the senior-to relation
with role R2 represented as senior-to(R1,R2) means
that R2 inherits all the permissions of R1. A static
policy specification is rarely common which lead
TRBACN
to resolve this problem. In TRBACN
, user-
role assignment and permission-role assignments are
revoked by physical deletion of the appropriate
4
Author : Frank Appiah
Date : 26/10/10
Title : Overview of RBAC
Version : 1.0
©2010 All Rights Reserved.
OVERVIEWOFRBAC

5. definitions of ura(U, R, T) and rpa(R, P, O, T) from
an instance of TRBACN
theory.
For audit purposes, it is quite necessary for some
actions by certain privilege users to be tracked like
revocation of roles in TRBACN
. TRBACN
used the
terminated(A,T)1
predicate to keep history of the
revocation of ura or rpa assignments. ([7], p.184)
For example, James assignment to a role R is
revoked on 20091113 then the ura(James,R,T)
clause defined is removed physically and the
assertion terminated(ura(James,R),
20091113) is added. On the other hand, a
read permission on an object, o1 assigned to
a role, r1 is revoked on 20091218 will be
added as an assertion
terminated(rpa(r1,read,o1),20091218).
Clearly, TRBACN
seems as the right recipe to
solve temporal problems in the standard
RBAC because of its clarity and simplicity
as compared to other temporal models.
In DEBAC[9], a formal policy representation was
modelled to address the issues of dynamic and
distributed information systems using term rewrite
systems. DEBAC is based fundamentally on the
notion of events which makes it more suitable for
autonomous changing context.
In DEBAC, Bertolissi et al[9] defined an access to a
resource as:
DEBAC supports the notion of role hierarchy in
RBAC as a hierarchy of categorisation in which the
privileges of a category can be inherited by another
category via category hierarchy. DEBAC
accommodates the notion of RBAC separation of
duties constraint as categories assigned to a user
cannot be mutually exclusive. DEBAC claims sound
as a good enhancement to the ANSI RBAC model to
address dynamic and distributed requirements of
1 In terminated(A,T), A is the ura or rpa assignments and T is
the time of revocation of the ura or rpa assignment.
some computational context.
4 Conclusion
n this report, I explored Role Based Access
Control to the extent of its limitations but more
importantly the enhancements made to rectify these
limitations.
I
Access control or authorization, in its broadest sense
- has existed as a concept for as long as humans have
had assets worth protecting. In today’s information
technology, authorization is concerned with the ways
in which users can access resources in the computer
system, or informally speaking, with "who can do
what?", “when to do what?” and “why you did
what?”.
5 References
[1] Park, J. AND Sandhu, R. 2004. The UCONABC
Usage Control Model.
[2] B. Zhao, R. Sandhu, X. Zhang AND X. Qin
2007.Towards a Time-Based Usage Control Model.
[3] Barker, S. ,Majek J. Sergot AND Duminda
Wijesekera 2008. Status-Based Access Control.
[4] S. H. Park,Y. J. Han AND T. M. ChungS.-H.
2006. Context-Role Based Access Control.
[5] S. Barker : Distributed Access Control: A Logic-
Based Approach. V. Gorodetsky et al. (Eds.) MMM-
ACNS 2003, LNCS 2776, pp. 217–228, 2003.c
Springer-Verlag Berlin Heidelberg 2003
[6] S. Barker: TRBACN: A Temporal Authorization
Model. V.I. Gorodetski et al. (Eds.): MMM-ACNS
2001, LNCS 2052, pp. 178– 188, 2001.
[7] Sandhu, R.: Role Hierarchies and Constraints for
Lattice-Based Access Controls.In: European
Symposium on Research in Security and Privacy
(1996)
[8] Lampson, B.W.: Protection. 5th Princeton
Symposium on Information Science and Systems,
1971. Reprinted in ACM Operating Systems
Review, 8(1), 18-24 (1974)
[9] Clara Bertolissi, Maribel Fernandez, and Steve
Barker. Dynamic Event-Based Access Control as
Term Rewriting* 2007.
5
Author : Frank Appiah
Date : 26/10/10
Title : Overview of RBAC
Version : 1.0
©2010 All Rights Reserved.OVERVIEWOFRBAC
“A user u Є U is permitted to perform an
action a Є A on a resource r Є R that is
located at site s Є S if and only if u is
assigned to a category c Є C to which an
access on r has been assigned.”

6. [10] Clara Bertolissi AND Maribel Fernández 2008.
Time and Location based services with Access
Control.
[11] Sandhu, R. and Ferraiolo, D. and Kuhn, R.: The
NIST Model for Role-Based Access Control:
Towards a Unified Standard. Proc. 4th ACM
Workshop on Role-Based Access Control (2000) 47–
61
[12] Sandhu, R., Park, J.: Usage Control: A Vision
for Next Generation Access Control. In: Models and
Architectures for Computer Networks Security. The
Second International Workshopon Mathematical
Methods (2003).
[13] Indrakshi Ray, Mahendra Kumar, and Lijun Yu:
LRBAC: A Location-Aware Role-Based Access
Control Model A. Bagchi and V. Atluri (Eds.): ICISS
2006, LNCS 4332, pp. 147–161, 2006.
ABOUT THE AUTHOR
6
Author : Frank Appiah
Date : 26/10/10
Title : Overview of RBAC
Version : 1.0
©2010 All Rights Reserved.
He holds MSc in Advanced
Software Engineering from King's
College London and BSc in
Computer Engineering from
KNUST. He specialises in Access
Control and Privacy Policies,
Distributed Systems, Software
Architecture and Software
Technology.