A model of OASIS role-based access control and its support for active security.
OASIS is a role-based access control architecture for achieving secure interoperation of services in an open, distributed environment. Services define roles and implement formally specified policy for role activation and service use; users must present the required credentials, in the specified context, in order to activate a role or invoke a service.  Roles are activated for the duration of a session only. In addition, a role is deactivated immediately if any of the conditions of the membership rule associated with its activation becomes false.OASIS does not use role delegation but instead defines the notion of appointment, whereby a user in some role may issue an \actright{} to some other user.  The role activation conditions of services may include \actright{}s, prerequisite roles and environmental constraints.We motivate our approach and formalise OASIS.  First, a basic model is presented followed by an extended model which includes parameterisation.
INTRODUCTION
The growing interest in role-based access control (RBAC)
as an eective means of replacing traditional discretionary
and mandatory access control has led to the development of
several models over the past few years [20, 8, 16]. Besides
the basic structure of subject, role and privilege, they all
include a notion known as role hierarchy. In its original
interpretation, a senior role in a hierarchy is treated as an
instance of all its junior roles. This means a senior role is
granted all privileges given to junior ones.
Although role hierarchy has become part of the accepted
model, we question whether it is appropriate in real-world
applications. In general a senior role will not need all the
privileges of its junior roles to carry out its work, and this
leads to violation of the principle of least privilege [18]. One
of the main reasons for using RBAC is that it provides a
natural way to model constraints such as separation of du-
ties. Role hierarchies complicate the specication and enforcement
of these constraints. For example, one kind of
separation of duties constraint is that a subject cannot have
a pair of con
icting privileges at any time. Privileges are
assigned to roles, and the interpretation of this constraint is
that a subject cannot act in a pair of con
icting roles simul-
taneously. Suppose that this pair of roles is in a hierarchy,
each being subsidiary to the same senior role. It would then
be impossible to exercise the senior role without breaking
either the constraint or the hierarchy.
There are various proposals to work around these prob-
lems. Sandhu [19] proposes separating the purposes of a
hierarchy into usage and activation. In an activation hierarchy
a user may choose to activate any role that is below
her assigned role in the hierarchy, therefore avoiding having
two con
icting roles active simultaneously. Ferraiolo et
al. [8] choose to override the inheritance relationship whenever
there is tension between hierarchy and con
ict. Moett
[14] suggests employing an ordering other than the organisational
hierarchy to dene a role hierarchy, or to use subsidiary
roles (also known as private roles [20]) outside the
organisational hierarchy. Such solutions are awkward since
they require an organisation to adapt its security policies
in order to avoid the potential problems of role hierarchies.
Moett and Lupu [15] examine some possible uses of role hierarchies
and identify three potential interpretations for role
hierarchies, namely isa hierarchy, activity hierarchy, and supervision
hierarchy. We believe that the use of role hierarchies
arises mainly through the in
uence of object-oriented
modelling and we are not convinced of their utility in practice

Goh questions the concept of role hierarchies from the
point of view of subsidiarity in [10]. He argues that useful
role hierarchies are uncommon in a real organisation where
tasks are assigned to appropriate roles independently of the
authority structure. We believe this view is a step forward
towards a more practical model for role based access control.
In this paper, we present a role based access control model
in which the fundamental role-role relationship, role activation
dependency, is dynamic. Each role activation is governed
by a set of rules, which are specied in logic. Roles
are parameterised, which helps to make policy expression
more scalable. Our model oers several advantages over existing
ones while retaining most of their desirable features.
The advantages include: (1) each role is named by a specic
issuing service, so that it is easy to dene roles and establish
policies for each service independently. (2) role activation is
controlled by rules which need to change only if the underlying
security policies change, so it is possible to deploy policy
separately for each administrative domain. (3) the use
of parameters makes it easy to tailor the model to specic
applications, since state may be read from the environment
when each role is activated. In this way active security based
on tasks or work
ow can be implemented naturally. (4) our
logic-based approach supports formal reasoning about policy

The remainder of this paper is organised as follows. Section
introduces our model informally and relates it to the
literature. Section 3 discusses appointment which replaces
delegation in the model. Section 4 provides a formal description
of the model. We present a simplied model in detail,
and indicate how it can be extended to include parameter-
isation. Section 5 describes a scenario to demonstrate one
application of the model. Section 6 concludes this paper
with a summary.
2. THEOASISACCESSCONTROLMODEL
OASIS stands for Open Architecture for Secure Interworking
Services. It is designed to facilitate access control in distributed
systems. OASIS embodies an open, decentralised
approach; for example, roles are dened by services and
services may interoperate, recognising one another's roles,
according to service-level agreements. We do not envisage
a single centralised role administrator. Previous work on
OASIS has focused mainly on the architectural issues [11,
3]. [12] discussed engineering issues in large-scale OASIS
implementations. It is important to note that OASIS is integrated
with an event infrastructure [3]; this allows services
protected by OASIS to communicate asynchronously, so that
one service can be notied immediately of a change of state
at another. This paper addresses the formalisation of the
OASIS model, but rst we motivate the essential concepts
on which it depends.
Central to the OASIS model is the idea of credential-based
role activation. The credentials that a user possesses, together
with side conditions which depend on the state of the
environment, will authorise him or her to activate a number
of roles. At any given time, a user will activate a subset of
these potential roles in order to carry out some specic task,
thus embodying the principle of least privilege in an organisation
[18]. The ability to activate and deactivate roles is
vital to the support for active security [23], where the context
is taken into consideration when an access is requested.
The concept of role activation in OASIS is similar to the
concept of session in [20], except that a user cannot deactivate
at will. Activation of any role in OASIS is explicitly
controlled by a role activation rule, and this rule may require
that specied preconditions continue to hold while the role
remains active, the role membership rule. When a role is
activated at a service an event channel is created in association
with each membership condition. An event is triggered
immediately any such condition becomes false, causing the
role to be deactivated. For example, such a trigger may
be generated when a timer expires or when a database is
updated to remove a user from membership of a group.
A role activation rule species the conditions that a user
must meet in order to activate a role. The intuition behind
this is that roles are usually given to a person provided that
he or she has met certain conditions, e.g. being qualied as
a physician, being employed by a company, being assigned
to a task, being on shift, etc. We model these conditions in
three categories, namely: prerequisite roles, appointments,
and constraints.
A prerequisite role in the condition for a target role means
that a user must have already activated the prerequisite
role before he or she can activate the target role. This is
a session-based notion. The basis of the concept of prerequisite
roles is competency and appropriateness, as pointed
out by Sandhu et al. [20].
Appointment occurs when a member of some role grants
a credential 1 that will allow some user to activate another
role. The context may be an assignment of jobs or tasks. It
may also be the passing of an examination, becoming professionally
qualied, or becoming employed. An activation
rule for a role requiring an appointment will require that the
associated credential is presented when activating that role.
Note that the appointing role is in no sense delegating; a
clerk in a hospital registry will not be medically qualied.
Security policies in real life often involve constraints such
as separation of duties. Several types of constraint have
been identied and discussed in the literature [20, 13, 21,
17]. In our model, constraints may be associated with role
activation rules, see denition 4 in section 4.1; in future
work we plan to specify role constraints at the organisational
level, for example, \an account clerk cannot simultaneously
be a billing clerk". We describe a possible implementation
of role constraints in the discussion of negated prerequisite
roles following denition 6.
The use of roles allows access control policy to be specied
in terms of the privileges of categories of users. This has
two advantages: rst, there is no need to change policy as
sta come and go; second, details of individuals need only
be taken into account during role activation. On the other
hand, we feel that in many applications it is insu-cient to
base access control decisions solely on roles and their assigned
privileges. This is especially true when context information
such as time needs to be considered. Extensions have
been proposed to the basic RBAC models in order to support
work
ow systems [6], team-based systems [22, 24], and,
more generally, in the content-based access control model of
1 For clarity we introduce a new term appointment certicate
for the credential associated with an appointment. We had
earlier referred to auxiliary credential certicates, see [3].
Giuri and Iglio [9] and the generalised model of Covington
et al.[7]. Most of these proposals are specic to their application
domains.
In OASIS, we have extended the role model with parame-
ters, based on rst-order logic. Parameters may be included
in the rules that cover both role activation and access to an
object or service. Parameters may be bound to such items
as the time of a role activation, the userid of a le owner,
or an attribute of the object that is being accessed. The
values that instantiate parameters are therefore context-
dependent. Our model is similar to some extent to Giuri
and Iglio's model based on role templates [9]. The main difference
is that our model uses formal rst-order predicate
logic as its foundation.
In section 4.1 we present the details of a simplied model
using propositional logic. This version omits parameters,
but it is identical to the full model in all other essential
features. In section 4.2 we outline the extensions necessary
to include parameters. We adopt a formal approach using
logic because adding parameters to privileges and roles adds
a layer of complexity to the model. A logic-based approach
helps to reduce errors in security policies by allowing static
checks to be performed, for example, for completeness, consistency
and reducibility. It also allows formal reasoning
about security policies to discover potential errors or con-
icts. Furthermore, the use of logic enables our model to
be integrated with policies specied in pseudo-natural lan-
guage. Preliminary, proof-of-concept work in this area can
be found in [2].
3. APPOINTMENT
Role delegation is an extension to the conventional delegation
of privileges, in which one user grants privileges to
another through roles. Recent and signicant work in this
area has been done by Barka and Sandhu. In [5], a role-based
delegation model called RBDM0 is introduced. In RBDM0,
if a role is delegated then all the associated privileges are
granted. Delegation is limited to a single step. Later work
by the same authors [4] identies cases of role-based delegation
that are useful in practice, and in particular extends
the model to include cascading delegation.
We introduce the notion of appointment to replace delega-
tion. A user in a role acting as an appointer grants another
user, the appointee, a credential which may be used to activate
one or more roles. Roles activated on the basis of an
appointment are usually associated with some tasks or re-
sponsibilities, and encapsulate the privileges granted by the
appointer.
3.1 Appointment vs. Delegation
The appointment model oers several advantages over the
traditional delegation model. First, privilege propagation is
controlled and well-dened. In [4], an attribute totality is
introduced to indicate whether the whole set of privileges
assigned to a role are to be delegated, or only some sub-
set. The latter case is known as partial delegation. Partial
delegation breaks the formal semantics of role-based access
control since a partially delegated role is in fact a new role
sharing an overloaded name with its delegating role. In the
appointment model, only those roles required to complete a
job function may be activated by the appointee, and conditions
may be specied to restrict the context of activation.
The appointment model thus goes some way towards embodying
the principle of least privilege [18]. Appointment
in itself confers no privileges. Any privileges derive solely
from roles activated on the basis of an appointment, and
are limited to the current session. Privileges are independent
of the appointer role.
Second, cascading delegation becomes irrelevant since appointees
are typically in a dierent role from their appointer.
The level of delegation attribute in [4] therefore becomes redundant

Third, in the appointment model, an appointer can give
access to privileges that he or she does not possess, albeit in
a controlled fashion. There is no reason why an appointer
should be able to satisfy the conditions for activating a role
that is to be granted to the appointee.
In general, delegation can be viewed as a special case of
appointment, in which a user in some role may appoint another
user to activate that same role. This mechanism could
be part of the emergency procedure of a service when a role
holder is called away or is taken ill.
3.2 Taxonomy
Barka and Sandhu describe a classication framework for
role-based delegation models in [4]. While some of these
attributes are useful and indeed essential when designing
a delegation model, we present a dierent taxonomy spe-
cic to role-based appointment and dynamic role activation.
Our taxonomy involves three types of users, appointer, appointee
and revoker. The appointer is someone with the
credentials for activating the appointing role, the appointee
species who is to be allocated an appointment, and the
revoker species who can revoke an appointment.
Appointer. Appointment implies the granting of privileges.
It is therefore essential to restrict which users may grant each
type of appointment. For each specic type of appointment
some role is identied to be the appointer. So long as a user
is acting in the appointer capacity, i.e. the user has activated
the appointer role, the user can make appointments of the
given type. For most organisational policies, it is su-cient
to control who may appoint through an appointer role. If
it is necessary to restrict those granting appointments to a
specic set of users, this can be enforced by side conditions
when the appointer role is activated.
Appointee. An appointment is granted so that the appointee
can obtain privileges by activating some role. At the least
the activation rules will require that the user is known to
the system, for example through holding a credential as an
authenticated user. In some circumstances that may be the
only requirement. An example is that a doctor on duty in
Accident and Emergency (A&E) may appoint any member
of the hospital sta who is on duty to order a blood test for
a patient, rather than being constrained to appoint only a
nurse in the A&E team.
If on the other hand the appointment is to be long-lived,
the regulations that govern the issue of appointment cer-
ticates can specify checks that should be made on all ap-
pointees. An example is when a new doctor is registered as
an employee of a hospital. The administrator making an appointment
(and/or issuing a smartcard) must check the new
doctor's academic and professional qualications. Checks
may include a mixture of clerical and computational proce-
dures. Provided that the checks are satised the appointer
will apply for an appointment certicate to transfer to the
appointee. A revocation credential specic to the appointment
is issued to and may be retained by the appointer, see
below.
It is possible to restrict the use of appointment certicates
independently of their issue. In particular, an appointment
certicate may require that the user presenting it is already
active in one or more roles, see denition 3. Such a condition
is appropriate when an appointment should only be
activated by sta who are already on duty. The appointment
certicate may also be subject to predicates which
can include environmental constraints, see denition 11 in
section 4.2.
Revoker. In OASIS an appointment can be revoked in three
possible ways: by its appointer only; by anyone in the ap-
pointer role; or by rule-based system revocation. The rst
two cases make use of the revocation credential returned at
the time of appointment.
In the rst case, an appointment can only be revoked by
its appointer. This is common in real-life organisations; for
example, the lead doctor in a care team might assign tasks
to sta on that team by means of appointment. He then
becomes responsible for monitoring performance. Revoking
the appointment of any member who performs badly is up
to the lead doctor himself. The revocation credential is valid
only when presented by the user who made the appointment.
This is called appointer-only revocation.
As pointed out in [5], dependence on a particular user to
revoke may have undesirable consequences; for example, if
an appointer is on leave it may be impossible to take immediate
action to limit damage. A solution is to allow anyone
who can activate the appointer role to make the revocation.
This is called appointer-role revocation. This is helpful only
if more than one user can activate the appointer role. The
principle is to limit the spread of damage by increasing the
number of people who can stop a misbehaving party.
The third possibility for revocation is system-managed re-
vocation. In this case, an appointment is revoked automatically
if certain conditions are met. There are many circumstances
in which the revocation of an appointment can be
better handled by the system than by a human. Continuing
the A&E scenario, the lead doctor may appoint a nurse to
order a blood test and wish that appointment to be revoked
as soon as the order has been successfully made.
Three possible types of system-managed revocation are
based on time, tasks and sessions. For time-based revoca-
tion, an appointment is associated with an expiry time. The
appointment certicate is revoked automatically at the expiry
time. This is appropriate if the policy is to review long-lived
credentials at regular intervals. In other applications,
such as an appointment to complete a specic job, it may
be di-cult to apply in practice. An alternative approach
is to bind an appointment to its assigned responsibilities,
expressed as tasks. The system monitors the progress of
these tasks and once they have been completed successfully,
the appointment is automatically revoked. This approach,
which requires substantial support from a task model, is
suitable in a work
ow environment.
The third type of system-managed revocation is based on
sessions. This can have two interpretations, the session of
the appointer or the session of the appointee. In the former
case, an appointment is valid so long as the appointer role
is still activated. It will be revoked automatically when the
appointer leaves the appointer role. This type of revocation
ensures tight monitoring of the appointee. An appointment
can also be for the duration of the current session of the
appointee. For example, a junior doctor may be appointed
to stand in for a consultant who is called away to an emer-
gency. When the junior's shift is over he logs o and the
session and appointment end. In practice the membership
rules for a role entered by an appointee will often require
that some other role remain active, and use of the appointment
is therefore limited to the associated session.
When designing practical systems which deploy the OASIS
model we have used appointment for long-standing persistent
credential allocation. Examples are credentials that
depend on academic or professional qualications, or on
holding a particular job in an organisation. Such credentials
are used, among others, to activate roles in order to
carry out tasks for the duration of a session.
4. FORMAL MODEL
We present two models in this section. The rst is based
on propositional logic to formalise role activation conditions,
see section 4.1. It covers most of the ideas introduced in
the previous sections, including appointment. We show in
particular how to express the membership rules associated
with active roles, and explain how we enforce these rules
using event channels.
OASIS roles and appointment certicates include param-
eters. Role activation rules can match parameters to ensure,
for example, that logged-in users can only invoke mutator
methods on objects that they own. In section 4.2 we outline
the extensions required to handle parameterisation. The
extended model is based on rst-order predicate calculus,
which allows the use of variables in expressions. Our models
are not designed to be application-specic. Instead, they
are capable of expressing a variety of security policies.
4.1 Basic Model
The model is built on top of six basic sets, described as
follows:
set of all users
S: set of all services
set of all role names
set of all environmental constraints
O: set of all objects
A: set of all access modes for objects
In addition to these sets, which are fundamental, two
other sets are central to the interpretation of the basic model:
R: set of all roles
P: set of all privileges
A user is a human-being interacting with a computer sys-
tem. An element in U can be any convenient representation
that uniquely identies a user in a system. The computer
system is composed of a collection of services S, which may
be managed independently. A role is a named job function
or title within an organisation that is associated with some
service; a role is specic to a service, and is dened below.
Services confer privileges on their role members, and may
also recognise the roles of other services.
Denition 1. A role r 2 R is a pair (s; n) 2 S N , where
s 2 S is a service and n 2 N is the name of a role dened
by s.
The name of a role is unique within the scope of its den-
ing service. When describing our model, we blur the distinction
between roles and role names where this will not lead
to confusion.
An environmental constraint e 2 E is a proposition that
is evaluated at the time of role activation. The value may
depend on factors such as the time of day, the identity of
the computer on which the current process is running or a
condition such as group membership which requires access
to a local database. In this paper we do not discuss the
details of environmental constraints. We therefore consider
each environmental constraint as an atomic proposition.
The conditions of some role activation rule must be sat-
ised when a role is activated. We may require in addition
that some subset of these conditions, the membership rule,
remains true throughout the session. If an environmental
constraint e appears as a membership condition then its implementation
must be active; when the role is activated each
membership condition is evaluated, and in addition a trigger
is set to notify the service should the condition become
false. We discuss this requirement in more detail below.
A privilege is a right to perform some operation on a particular
object. It is dened formally as follows.
Denition 2. A privilege p 2 P is a pair (o; a) 2 O A,
O is an object and a 2 A is an access mode for
the object o.
The set of objects and their corresponding access modes
are service dependent. For example, in relational database
applications, objects may represent rows and their associated
access modes include read- or update-attributes. In
object-oriented systems, including distributed object sys-
tems, objects are represented naturally while access modes
are the methods for each object. In general, we treat privileges
as an abstract unit if the context permits.
The underlying idea of RBAC is to associate privileges
with roles, and roles with users. These associations are described
as relations in our model. Before describing these
relations, we need to dene the relationship between roles.
As explained earlier, role hierarchy does not have any place
in our model. Instead we control the acquisition of privileges
through role activation governed by rules. Roles can
only be activated during a session, and being active in one
role may be a precondition for activating another; an example
is a log-in credential that ensures that the user has
been authenticated. In order to activate certain roles a user
must hold an appointment; the corresponding condition in a
role activation rule is an appointment certicate. Its formal
denition follows.
Denition 3. An appointment certicate ! is an instance
of an appointment. It may include a set of prerequisite roles,
described by the function
where
is the set of
all appointment certicates in the system.
An appointment certicate held by a user is valid only if
the user is active in all of its prerequisite roles. This allows
an appointer to ensure that an appointment certicate can
only be used when the preconditions for activating all of
those roles have been met.
A role activation rule species the conditions for a user to
activate a role. It can be formally dened as follows.
Denition 4. A role activation rule, or activation rule for
short, is dened as a sequent (x1
for 1  i  n is a variable in the universe
[E , and
We say that each x i for 1  i  n is an activating
condition for the role r.
For an activation rule (x1 ; x2 ; :::; xn ' r), a user must satisfy
all conditions x1 ; x2 ; :::; xn in order to activate the role
r. Satisfaction interprets each variable within the current
context to give a Boolean value, see denition 6. There may
be more than one activation rule associated with a particular
role r.
An example of a role activation rule is given below with
and
According to this rule a user who is active in role r1 and
holds the appointment certicate !1 can activate the role r4 ,
provided that the conditions for the appointment certicate
to be valid are satised. In this case the sole condition is
that the user be active also in the prerequisite role r3 .
This denition of activation rule is essentially a restricted
form of Boolean logic. Any Boolean expression without
negation over the universe X can be translated into one or
more activation rules by rewriting it into disjunctive normal
form (DNF), and taking each implicant as an activation con-
dition. For example, an expression in the same universe as
the above example is shown below in Boolean logic syntax.
This is translated to DNF,
and this can be written in sequent notation shown below.
The set of all activation rules specied in a system is denoted
by . We summarise the symbols representing additional
sets of objects in our model here.
set of all appointment certicates
set of all role activation rules
set of all membership rules
We now consider a special type of role activation rule,
called initial rules.
Denition 5. A role activation rule (x1 ; x2 ; :::; xn ' r) in
which for 1  i  n the variable x i[ E is initial. The
role r is said to be an initial role.
Initial rules provide a means to allow users to start a session
by acquiring initial roles. A particular case is that of
rules with no antecedent conditions, ' r. The activation
of such an initial role depends on system policies and typically
requires system-dependent mechanisms, for example,
password authentication or challenge-response authentica-
tion. In general activation of an initial role may require
an appointment certicate and be subject to environmental
constraints. The set of all initial roles is denoted IR  R.
We restrict explicit association between users and roles to
initial roles. In order to activate any other role a user must
satisfy the preconditions of some activation rule, including
possession of one or more prerequisite roles. These preconditions
can include appointments and environmental constraints
as well as role membership.
Note that during a session a user accumulates privileges
by activating a succession of roles. Starting from a set of initial
roles, which become active following authentication, a
number of roles may be entered according to specied rules.
An acyclic directed graph structure is therefore established
that exhibits the run-time dependency of each role on its pre-
conditions. Supercially the structure is similar to a static
role hierarchy, but there are important dierences. First,
the dependency structure is dynamic; there may be several
activation rules for the same role. Second, any privileges
acquired by entering a role in this way will usually not be
shared with any prerequisite role; it is more likely that the
new role is more specic, and has been activated on the basis
of appointment, or perhaps following database look-up. Parameter
values play an essential part in determining which
particular users can acquire the privileges associated with
more specic roles.
The activation of a non-initial role requires a user to satisfy
each of the conditions of some activation rule for that
role. We dene what is required for elements of each of the
sets
R,
and E to satisfy a precondition for role activation.
Denition 6. The interpretation function for a role activation
rule is a truth assignment with type, I
falseg. An interpretation function, I, with respect
to a user u 2 U is denoted as Iu , and is dened below:
true if x 2 R and u is active in
role x,
u possesses the
appointment certicate x
and is active in all the
prerequisite roles r 2 (x),
and the evaluation
of x yields true.
false otherwise
Note that the denition of activation rules does not include
negation (:). We brie
y consider the eect of allowing
negation of each of the three types of role activation condi-
tion. First, environmental constraints e 2 E are atomic by
denition. Any discussion of negation must take place in
the context of an explicit environmental sublanguage, such
as temporal expressions that test the time of day.
Second, appointment certicates !record the fact
of an appointment. It is only when a role is activated on
the basis of an appointment certicate that any privileges
are bestowed on the user. Negation should be associated
with the roles activated rather than with the appointment
certicate itself. In any case, appointment certicates can
be anonymous and therefore transferable from user to user;
the advantage of such a scheme is that a single revocation
credential covers all the users of such an appointment cer-
ticate. It is not in general possible to tell whether a user
has obtained such an appointment.
Negating a role r 2 R makes perfectly good sense. In-
deed, allowing a negated role among the conditions for role
activation has a natural interpretation under Iu , namely
active in role r. This is a possible
implementation of a separation of duties constraint. But if
a user must not activate two roles simultaneously, then the
activation rules for each role should indicate that this user
must not be active in the other. A more appropriate way of
specifying the requirement would be to declare an explicit
separation of duties constraint. We are actively investigating
this issue.
Given the denition of the interpretation function, we can
then dene role activation formally.
Denition 7. (Role activation) A user u 2 U can activate
a role r 2 R if and only if there exists an activation rule
where Iu is the interpretation function for u at the time
when the activation request is made.
Note that the denition of the interpretation function implies
that its evaluation with respect to a user changes with
the context. When a user requests an activation of a role,
the interpretation function is immediately evaluated in the
user's context and the decision is made.
The opposite of role activation is role deactivation. Often
continuing activation of a role will be valid only if some
subset of the activation conditions continues to hold. These
are called the membership conditions. The membership rule
associated with a role activation rule species those conditions
that must remain true in order for a user to remain
active in that role.
When a role is activated at a service s 2 S each of the conditions
of the activation rule is veried. For roles associated
with s itself this is straightforward. Roles and appointment
certicates of other services must be validated by the issuer.
In the case that x i is a membership condition s establishes
an event channel on the trigger :x i so that the issuer can
notify s should the condition become false. OASIS depends
on asynchronous notication to support role deactivation,
see for example [3].
We have not dened explicit sublanguages for environmental
contraints in this paper. However, it is worth considering
two examples. First, let's suppose that a particular
role may be held only between 1600 and 1800 hours on any
day. We can include this requirement as part of the activation
rules through a constraint in E ; at activation we check
the time of day, say 1723, and set a timer exception for 1800
hours. In this instance the evaluation is independent of the
user u.
Second, suppose that user u requests a privilege that is
restricted to members of group g. For this example we require
active database support. At activation, we check the
data base for the required group membership. At the same
time, we set a trigger for the negation of the condition. If
the group manager updates the database to exclude user u
then the trigger res and deactivation takes place. This example
shows how constraints in E may be user specic. The
rst prototype implementation of OASIS included a simple
associative tuple store with triggers.
Denition 8. The membership rule associated with the
activation rule for the role r 2 R is
the sequent (x1
for which 1  are the membership conditions.
If a user is active in the role r through the activating
rule
r shall be immediately deactivated if the
associated membership rule (x1 ; x2 ; :::; xm ' r) can no longer
be satised. We denote the set of all membership rules in
a system as . The formal denition of role deactivation is
given below.
Denition 9. (Role deactivation) A role r 2 R held by
a user u 2 U is deactivated if Iu 6j= x i , where x i is some
membership condition in the rule (x1
corresponding to the rule
2 that activated r, and Iu is
the interpretation function for u.
Continued satisfaction of the membership rule associated
with the rule used for activating a role r is required for
the user to remain active in r. Note that the deactivation
of a role r may trigger the deactivation of another role r 0
whose membership depends on the membership of r. This
is referred to as cascading deactivation. Its implementation
is discussed in [3, 11] where the implementation of triggers
and an event infrastructure are discussed.
Note that the membership rule associated with an active
role r is specic to the rule under which r was activated.
Consider as an example the rules obtained by translating
the Boolean expression introduced after denition 4
which species that a user who is active either in role r1 or
in role r2 and who holds an appointment certicate !1 may
activate role r4 .
The corresponding activation rules are as follows:
In each case the membership rule will include the relevant
prerequisite role, so as to enforce cascading deactivation at
the end of the session. If revocation of the appointment is
to take immediate eect, then the appointment certicate
must also be a membership condition.
We can now dene the association of roles with privileges.
This is expressed as a relation as follows.
RP  R P, the role-privilege relation.
RP describes the role-privilege relationship. It is a many-
to-many relation specied by the security administrators of
an organisation to express security policies. We distinguish
two sets of privileges for a role by the terms direct and eec-
tive. Our denitions are dierent from those given in [17],
where direct and eective privileges are dened with role
hierarchy in mind.
The direct privilege set of a role r 2 R is the set of privileges
assigned to r directly, i.e. RPg.
The eective privilege set of a role r is the set of privileges
that a user who is active in r must necessarily hold.
This includes the eective privileges of all roles specied as
membership conditions when r was activated, including the
prerequisite roles of any appointment certicates. Each of
these roles must still be active, or r would have been subject
to cascading deactivation. The eective privilege set is dy-
namic, and depends on the specic activation history. The
following denition ascends the activation tree recursively.
Denition 10. Suppose a user u 2 U is active in some role
r whose current membership rule is r). The
eective privilege set EP(r) of r is dened as follows:
is a prerequisite
role
if x iis an appointment
certicate, the union of
EP() for all prerequisite roles  2
The eective privilege set for role r denes privileges that
a user must continue to hold while remaining active in that
role.
In some RBAC models it is possible to compute the maximum
privileges that a user may assume. OASIS denes
security policies on a service by service basis for multiple
management domains in a distributed world. For example,
a nationwide system for electronic health records will comprise
many interoperating domains such as hospitals, primary
care practices, clinics, research institutes etc. Services
within a given domain express their policy for role activation
and service use. Membership of a role of one service
may be required as a credential for entering another. Such
dependencies are specied in service level agreements. It is
likely that policy will be administered at domain level, and
will derive from local and national administrative and legal
sources, depending on the application. Service level agreements
will also be made across domains. Appointments may
be made at several administrative levels. Some appointment
certicates will apply to many domains, for example those
representing academic and professional qualications. Others
will be dynamic and local, for example temporary substitution
for a colleague who is called away while on duty.
Should it be required, it is possible to compute the maximum
privileges that a user may obtain based on statically
known appointments. This assumes that all constraints will
be satised at the time roles are activated. In practice,
dynamic environmental conditions may prevent some roles
from being activated in any specic session. In addition unforeseen
appointments might be made dynamically within
sessions.
Previously we introduced appointment certicates to represent
appointments. Services which support appointment
will dene their own roles and policies to manage it, and
will issue and validate the appointment certicates. At each
appointment an appointment certicate is returned to the
appointer, who subsequently transfers it to the appointee.
The latter can then use the appointment certicate during
role activation, either at the issuing service or at some other.
The role activation rules may specify a number of prerequisite
roles in addition to one or more appointment certicates.
In this way we can for example implement the two-signature,
countersign approval system commonly found in business by
requiring two appointment certicates. In addition the ap-
pointer, when applying for the appointment certicate, may
specify a set of roles in which the appointee must be active
in order for it to be valid, see denition 3.
OASIS supports rapid and selective revocation, which is
managed by invalidating the appointment certicate issued
on an appointment. Whenever a credential is invalidated
any roles that depend on it are deactivated and their associated
credentials invalidated, see [3] for implementation
details. This can lead to cascading deactivation of a tree of
roles in which a user is active. Cascading deactivation also
takes place when a session ends after a user logs o; logged-
in-user is likely to be an initial role. This basic model is
su-cient to support system-managed revocation. We do
not attempt to formalise the details.
4.2 Extended Model
There is an increasing interest in the research community
in just-in-time, active security where policies must adapt to
their environment. Prominent examples include the workow
authorisation model [1] and task-based authorisation
controls (TBAC) [23]. Essentially, a major drawback of traditional
RBAC models that limits their usefulness is their
inability to take into account ne-grained information from
the execution context. In the introduction we discussed ad-hoc
extensions that have been suggested to meet specic
needs. As an alternative we propose a generic framework
which can be tailored to each application domain with minimal
eort.
The problem of implementing an access control system for
the Electronic Health Records (EHRs) of the United Kingdom
National Health Service (NHS) is one of the case
studies that has informed the design of OASIS [2]. In this
application it is vital that the user requesting access can
be identied, since under the UK Patients' Charter the patient
has the right to exclude named individuals. Traditional
functional roles are not adequate for this purpose, since such
an exclusion is specic both to the patient and to the potential
reader. Individual identity must therefore be established
by a credential which is presented on access; in the OASIS
model the obvious choice is a role membership certicate,
asserting the NHS identier of the user in some way. Rules
for role activation refer to individual roles, so it is not possible
to name a separate role for each potential user; such an
implementation would be neither manageable nor scalable.
Instead we set up generic initial roles such as logged-in-user
and smart-card to correspond to the modes of authentication
supported by the system. In order to identify the individual
we extend the role membership certicate (RMC) by a pa-
rameter, userid and NHS-id respectively. Such parameters
are among the elds protected when the RMC is generated,
see for example [3].
In the basic model described in the last section access
control decisions are made on the basis of propositions that
are evaluated in the current context. These propositions
relate to roles and appointments, and the policy governing
the acquisition of privileges is expressed in terms of them.
Role activation rules can take account of the execution environment
by evaluating propositions relating to such factors
as the current time of day or an entry in an administration
database. We extend this model to allow parameterisation of
roles, appointment certicates, privileges and environmental
constraints. In order to accommodate these extensions
we have enhanced the specication to dene role activation
rules and membership rules in terms of predicates rather
than propositions.
The details of these extensions are intuitive. RMCs contain
a number of protected elds, which, together with a
nonce key identifying the session, form input to the one-way
function that generates the signature. In the formal model a
parameterised role consists of a role together with
a k-tuple that identies the parameter values. In expressing
the conditions for role entry a proposition identifying r as a
prerequisite role is replaced by a k-ary predicate. Within a
rule the arguments of each predicate may be either variables
or constants. Variables may also occur in the parameterised
role r 0 that is being activated. Evaluation of an activation
rule proceeds by unication over the variables that are spec-
ied. Values in the RMCs that establish membership of pre-requisite
roles set the corresponding variables appearing in
activation conditions. Activation succeeds only if all conditions
can be met, and subject to a consistent assignment of
values to variables. In this case the parameters of the new
role r 0 are set from the variable values established during
unication.
Environmental constraints are in detail application spe-
cic, but a common and useful form is the ability to check
information in a database during role activation. Provided
the database itself can be identied then such a constraint
can be viewed as a predicate assertion. For a relational
database the natural interpretation is of the occurrence of a
tuple in a relation named by the constraint. In a deductive
database the predicate assertion species a query directly,
and unication over the variables involved has a direct counterpart
during query evaluation.
Parameterised appointment certicates are similar to parameterised
roles. If an appointment certicate with k parameters
appears as a precondition for role activation then
the activation rule includes a k-ary predicate. Variable values
are matched against other occurrences of the same named
variable within the rule.
A parameterised appointment certicate is valid only if
its holder is active in all of its prerequisite roles. In ad-
dition, parameters of credentials (RMCs) associated with
these roles may be required to match parameters of the appointment
certicate. An appointment certicate may also
be subject to one or more environmental constraints. The
relationship between a parameterised appointment certi-
cate and its prerequisite roles is specied in a validity rule,
dened as follows.
Denition 11. A validity rule for a parameterised appointment
certicate ! is dened as a sequent (x1
Note that only parameterised roles or environmental constraints
are allowed in the premises part of a validity rule.
During role activation any appointment certicates are validated
before the activation rule is evaluated. Unication
of variables in the validity rule may constrain undened parameters
of the appointment certicate; the values set form
part of the context during role activation.
The roles held by a user determine that user's privileges.
A privilege can typically be considered as a specic access
right at a service. Roles are parameterised, and parameter
values can be propagated to privileges at request
time. For example, the privileges corresponding to a role
writer(userid) activated at a le service may be restricted
to les that are owned by the user named userid. We do not
go into details here.
The rst prototype implementation of OASIS used simple
parameter matching at role activation time, essentially setting
parameters when they were rst encountered and denying
role activation if there was a later con
ict. Parameters
were strings, and the only value comparison supported was
equality. Database look-up was supported by an associative
tuple store.
If an environmental constraint appears in a membership
rule then the service which evaluates it must have an active
implementation. One reason for using such a naive database
was that it was easy to set up event channels for it; if a
query during activation represented a membership condition
then an event channel was established, and the role activation
service could be notied if the condition became false
subsequently. We have just started to experiment with the
POSTGRES object-relational database management system
(DBMS), which allows agents external to the DBMS to set
triggers in order to receive notication of database update.
Initial experiments are encouraging, but a lot of work remains
to be done. If this approach is successful then it
would be natural to regard parameter k-tuples as instances
of classes, and to enforce type checking of individual param-
eters. That would be an obvious improvement.
5. EXAMPLES
Suppose that privacy legislation has been passed whereby
someone who has paid for medical insurance may take certain
genetic tests anonymously. The insurance company's
membership database contains the members' data; the genetic
clinic has no access to this and the insurance company
may not know the results of the genetic test, or even
that it has taken place. The clinic, for accounting purposes,
must ensure that the test is authorised under the scheme. A
member of the scheme is issued a computer-readable membership
card containing an appointment certicate and the
expiry date. In the simplest scheme the membership card
is authenticated at the clinic, the member enters the unpa-
rameterised role paid up patient and the test is carried out.
patient
In the presentation above paid up patient is an unparame-
terised initial role with no explicit preconditions. Checking
the expiry date on the membership card is part of the system
authentication process. A more likely scenario is that the activation
rule for paid up patient comprises the appointment
certicate and an environmental constraint requiring that
the date of the (start of the) treatment is before the expiry
date of the insurance scheme membership. The appointment
certicate is validated at the issuing service (a trusted
third party) before role activation can proceed. In this case
the appointment certicate becomes the membership rule
for the role paid up patient ; if the appointment certicate is
found to be fraudulent treatment is terminated.
It is easy to express the constraint on the expiry date using
parameters. Suppose that the expiry date is a protected
eld of the appointment certicate, and the environmental
constraint 1 checks that a temporal argument lies in the
future. The following activation rule matches the parameter
t, reading it from the appointment certicate and supplying
it as argument to 1 .
patient
An initial role logged in user(uid, machine) might be dened
so that the user-id and the machine at which the login
has taken place can be carried forward and checked as environmental
conditions on subsequent role activation. Again,
at the engineering level, the parameters are protected elds
in the role membership certicates. If login can be at any
computer in the administrative domain we dene the role
logged in user(uid) with a single parameter. In the health-care
domain everyone has a unique NHS identier which
could be used as a parameter.
We now work through an example scenario from an A&E
department of a hospital. Let us suppose that some of
the roles involved are nurse(x), screening nurse(x), doctor(x)
and treating doctor(x,y) where x is the identity of the role
holder in each case and y is the patient being treated. In
outline, as hospital sta come on duty they login and activate
roles such as nurse, screening nurse and doctor. When
someone goes o-duty they logout and the roles they hold
are deactivated. As an example of how dynamic appointment
might be used we suppose that a screening nurse assigns
each patient that arrives to a particular doctor who
becomes the treating doctor for that patient.
There is an electronic health record (EHR) service in the
hospital domain which interacts with a National EHR ser-
vice, external to the domain, in order to assemble any re-
quired, and authorised, records of treatments the patient has
had. Let us assume that the general policy is that screening
nurses may read patients' contact and emergency data
only, and that treating doctors may read the EHR of any
patient y they are treating while they are active in the role
treating doctor(x,y). The EHR service recognizes the A&E
service roles described above (a service-level agreement) and
implements this policy.
For the key roles in this scenario we now dene the activation
rule and the membership rule. We also demonstrate
long-term and dynamic appointment.
When a doctor or nurse is employed at the hospital their
academic and professional credentials are checked and they
are issued with an appointment certicate parametrised with
their identity information. This might be on a computer
readable card or be stored in the administration lespace.
For the role doctor(x) the activation rule comprises x 's appointment
certicate. The membership rule is identical to
the activation rule since the appointment certicate must
remain valid for x to remain active in the role.
The role nurse(x) has a similar structure.
For the role screening nurse(x) the activation rule comprises
the prerequisite role nurse(x) and has no appointment
or environmental conditions. The membership rule is identical
to the activation rule.
For the role treating doctor(x,y) the activation rule comprises
the prerequisite role doctor(x) and there is no environmental
condition. An appointment certicate is required.
This is a certicate allocated by the screening nurse to doctor
x authorising her to treat patient y.
doctor(x treating doctor(x ; y)
The role doctor(x) could also be a prerequisite role of the
appointment certicate, but it is redundant in this example.
Note that if the screening nurse goes o duty and logs out,
she deactivates her role nurse(x) causing the dependent role
screening nurse(x) to be deactivated. The appointment cer-
ticate !3(x; y) is not invalidated at the end of her session.
The membership rule of the role treating doctor(x,y) is once
again identical to the activation rule. First, x must remain
active in the prerequisite role doctor(x), in order to ensure
that the role treating doctor(x,y) is deactivated at the end
of the session. There are two reasons for making !3(x; y)
a membership condition as well. The screening nurse may
wish to reassign the patient to another doctor, and in any
case the appointment should be revoked when patient y is
discharged. Note that x may still be on duty when this
happens.
A given doctor will be assigned to a number of dierent
patients while on duty and will activate the role treating
doctor(x,y) for each of them. The role treating doctor(x,y)
of the A&E service gives doctor x the privilege to access patient
y's health record at the EHR service. Other hospital
services such as the Pharmacy service and the X-ray service
will also be OASIS-aware and require the A&E role membership
certicate treating doctor(x,y) on invocation. Such
services will record the parameters x and y for accounting
and audit.
6. CONCLUSION
OASIS is an access control system for open, interworking
services in a distributed environment modelled as domains
of services. Services may be developed independently but
service level agreements allow their secure interoperation.
OASIS is closely integrated with an active, event-based middleware
infrastructure. In this way we continuously monitor
applications within their environment, ensuring that security
policy is satised at all times. We therefore address the
needs of distributed applications that require active security.
Any formalisation must take account of the relationship between
OASIS and the underlying active platform.
In this paper we have formalised the OASIS model without
reference to domains. Formal specication is crucial in
order to manage access control policy for future, large scale,
widely distributed, multi-domain systems. A formal model
allows policy components established across a number of domains
to be checked for consistency. This is necessary, since
otherwise policy cannot be deployed by domains acting au-
for example, a government edict might require
changes of policy across heterogeneous healthcare domains.
Automation is essential to minimise human error, and it can
only be used where a formal model exists.
OASIS is role based: services name their client roles and
enforce policy for role activation and service invocation, expressed
in terms of their own and other services' roles. A
signed role membership certicate is returned to the user on
successful role activation and this may be used as a credential
for activating other roles, according to policy.
We do not use role delegation. Instead, we have dened
appointment which we believe to be both more intuitive and
more applicable in practice. Appointments may be long-
lived, such as academic and professional qualication, or
transient, such as standing in for a colleague who is called
away while on duty. On appointment, the appointee is issued
with an appointment certicate which may be used,
together with any other credentials required by policy, to
activate one or more roles.
In addition to role membership certicates and appointment
certicates role activation rules may include environmental
constraints. Examples are user-independent constraints
such as time of day and conditions on user-dependent
parameters. For example, it may be necessary to perform
database lookup at a service to ascertain that the user is a
member of some group. Alternatively, a simple parameter
check may ascertain that the user is a specied exception to
a general category who may activate the role.
The membership rule for a role indicates those security
predicates for activating the role that must remain true for
the role to continue to be held. Event channels are set up
between services to ensure that all conditions of the membership
rule remain true. Should any condition become false
this triggers an event notication to the role-issuing service
and the role is deactivated for that user. By this means we
maintain an active security environment.
OASIS is session based. Starting from initial roles, such
as \authenticated, logged-in user", a user may activate a
number of roles by submitting the credentials required to
satisfy an activation rule. The activated roles therefore form
trees dependent on initial roles. Should any membership
condition for any role become false the dependent subtree is
collapsed. If a single initial role is deactivated (the user logs
out), all the active roles collapse and the session terminates.
Our application domains require parameterisation of roles.
For example, in the healthcare domain a patient might specify
\all doctors except my uncle Fred Smith may read my
health record". For a ling system it is necessary to indicate
individual owners of les as well as groups of users.
Future work involves the detailed modelling of role pa-
rameters. In practice, distributed systems comprise many
domains; for example the healthcare domain comprises hos-
pitals, primary care practices, research institutes etc. We
will generalise our naming structure to include domains ex-
plicitly. We are working on the management of policy for
role activation and service use. Policy may derive from local
and national sources and will change over time. Policy
stores will be managed using OASIS in our active environ-
ment. The formalisation of OASIS will provide a rm basis
for requirements such as checking the consistency of policies.
7.

ACKNOWLEDGEMENT

We acknowledge the support of the Engineering and Physical
Sciences Research Council (EPSRC) under he grant OASIS
Access Control: Implementation and Evaluation. Members
of the Opera research group in the Computer Laboratory
made helpful comments on earlier drafts of this paper.
The ideas that lie behind denition 11 were introduced by
John Hine, see [12]. We are grateful to Jon Tidswell and
the anonymous referees for constructive criticism which has
much improved this paper.
8.



--R

An authorization model for work ows.
Translating role-based access control policy within context
Generic support for distributed applications.
Framework for role-based delegation models

A exible model for the speci
Generalized role-based access control for securing future applications

Role templates for content-based access control
Towards a more complete model of role.
OASIS: Access Control in an Open
An architecture for distributed OASIS services.
Mutual exclusion of roles as a means of implementing separation of duty in role-based access control systems


Access rights administration in role-based security systems
The role graph model and con ict of interest.
The protection of information in computer systems.
Role activation hierarchies.

Separation of duty in role-based environments



--TR
Role-Based Access Control Models
A flexible model supporting the specification and enforcement of role-based authorization in workflow management systems
Team-based access control (TMAC)
Mutual exclusion of roles as a means of implementing separation of duty in role-based access control systems
Role templates for content-based access control
Role activation hierarchies
Towards a more complete model of role
Control principles and role hierarchies
Team-and-role-based organizational context and access control for cooperative hypermedia environments
The role graph model and conflict of interest
A role-based access control model and reference implementation within a corporate intranet
The uses of role hierarchies in access control
An architecture for distributed OASIS services
Generic Support for Distributed Applications
Access Rights Administration in Role-Based Security Systems
Task-Based Authorization Controls (TBAC)
An Authorization Model for Workflows
Translating Role-Based Access Control Policy within Context
Framework for role-based delegation models
Separation of Duty in Role-based Environments

--CTR
Jacques Wainer , Akhil Kumar , Paulo Barthelmess, DW-RBAC: A formal security model of delegation and revocation in workflow systems, Information Systems, v.32 n.3, p.365-384, May, 2007
Mohammad A. Al-Kahtani , Ravi Sandhu, Induced role hierarchies with attribute-based RBAC, Proceedings of the eighth ACM symposium on Access control models and technologies, June 02-03, 2003, Como, Italy
Jason Crampton, Administrative scope and role hierarchy operations, Proceedings of the seventh ACM symposium on Access control models and technologies, June 03-04, 2002, Monterey, California, 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
Gang Yin , Huai-min Wang , Dian-xi Shi , Yan Jia , Meng Teng, A rule-based framework for role-based constrained delegation, Proceedings of the 3rd international conference on Information security, November 14-16, 2004, Shanghai, China
Jean Bacon , Ken Moody , Walt Yao, Access control and trust in the use of widely distributed services, SoftwarePractice & Experience, v.33 n.4, p.375-394, 10 April
Hua Wang , Jiuyong Li , Ron Addie , Stijn Dekeyser , Richard Watson, A framework for role-based group deligation in distributed environments, Proceedings of the 29th Australasian Computer Science Conference, p.321-328, January 16-19, 2006, Hobart, Australia
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
Longhua Zhang , Gail-Joon Ahn , Bei-Tseng Chu, A rule-based framework for role-based delegation and revocation, ACM Transactions on Information and System Security (TISSEC), v.6 n.3, p.404-441, August
Luc Moreau , Christian Queinnec, Resource aware programming, ACM Transactions on Programming Languages and Systems (TOPLAS), v.27 n.3, p.441-476, May 2005
Tolone , Gail-Joon Ahn , Tanusree Pai , Seng-Phil Hong, Access control in collaborative systems, ACM Computing Surveys (CSUR), v.37 n.1, p.29-41, March 2005
Jean Bacon , Ken Moody , Walt Yao, A model of OASIS role-based access control and its support for active security, ACM Transactions on Information and System Security (TISSEC), v.5 n.4, p.492-540, November 2002
Gustaf Neumann , Mark Strembeck, An approach to engineer and enforce context constraints in an RBAC environment, Proceedings of the eighth ACM symposium on Access control models and technologies, June 02-03, 2003, Como, Italy
Mark Strembeck , Gustaf Neumann, An integrated approach to engineer and enforce context constraints in RBAC environments, ACM Transactions on Information and System Security (TISSEC), v.7 n.3, p.392-427, August 2004
RBAC;service level agreements;certificates;OASIS;policy;role based access control