Organization based access control

Anas Abou El Kalam, Rania El Baida, Philippe Balbiani, Salem Benferhat,

Frederic Cuppens, Yves Deswarte, Alexandre Miege, Claire Saurel, Gilles
Trouessin

To cite this version:

Anas Abou El Kalam, Rania El Baida, Philippe Balbiani, Salem Benferhat, Frederic Cuppens, et al..
Organization based access control. 4th International Workshop on Policies for Distributed Systems
and Networks (POLICY 2003), IEEE, Jun 2003, Lake Como, Italy. pp.120–131, �10.1109/POL-
ICY.2003.1206966�. �hal-04003608�

HAL Id: hal-04003608

https://hal.science/hal-04003608v1
Submitted on 24 Feb 2023

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 Organization based access control
Anas Abou El Kalam¶ Rania El Baida§ Philippe Balbiani§∗
Salem Benferhat† Frédéric Cuppens§∗ Yves Deswarte¶
Alexandre Miège Claire Saurel Gilles Trouessin‡

Cril† Ernst & Young Audit‡ Irit§ Laas¶ Onera

Abstract have special permissions in specific contexts,

such as the context of urgency (see section 5).
None of the classical access control models such as
DAC, MAC, RBAC, TBAC or TMAC is fully satisfac- 2. Rules that specify obligations or recommenda-
tory to model security policies that are not restricted tions. Classical access control models are gen-
to static permissions but also include contextual rules erally restricted to permissions. Some of them
related to permissions, prohibitions, obligations and include prohibitions. More recently, including
recommendations. This is typically the case of se- obligations in the security policy specification
curity policies that apply to the health care domain. was also suggested[9, 10]. As far as we know, rec-
In this paper, we suggest a new model that provides ommendations have never been considered pre-
solutions to specify such contextual security policies. viously.
This model, called Organization based access control,
3. Rules that are specific to the organization. In
is presented using a formal language based on first-
particular, the organization may be structured
order logic.
into several sub-organizations having their own
security policy. The model should provide
1 Introduction means to specify the different security policies
within a unique framework.
Several access control models have been proposed:
DAC[1], MAC[2, 3], RBAC[4, 5, 6], TBAC[7] or This paper suggests a model that attempts to solve
TMAC[8]. None of these models is fully satisfactory, these problems. The concept of organization is central
seeing that they are difficult to apply to organizations in this model. The specification of the security pol-
that use security policies including: icy is completely parameterized by the organization so
that it is possible to handle simultaneously several se-
1. Rules that specify contextual permissions or pro- curity policies associated with different organizations.
hibitions. There are many examples of rules The model is not restricted to permissions, but also
that apply only to specific circumstances. For includes the possibility to specify prohibitions, obliga-
instance, in the health care domain, physicians tions and recommendations.
∗ Corresponding
The remainder of this paper is organized as follows.
authors: [email protected] and cup-
[email protected].
Sections 2 and 3 present basic models for discretionary
† Cril-CNRS, Centre de recherche en informatique de Lens, access control and role based access control. Section 4
Université d’Artois, Rue Jean Souvraz, SP18, 62307 Lens presents our new model, the “Organization based ac-
Cedex. cess control” (ORBAC). Section 5 defines a language
‡ Ernst & Young Audit, 1 place Alphonse Jourdain, 31000

Toulouse.
based on first-order logic that will be used to spec-
§ Irit-CNRS, Institut de recherche en Informatique de ify an ORBAC security policy. Section 6 develops an
Toulouse, Université Paul Sabatier, 118 route de Narbonne, example of security policy in this language. Section
31062 Toulouse Cedex 4. 7 shows how to specify various constraints. Finally
¶ Laas-CNRS, Laboratoire d’analyse et d’architecture des

systèmes, 7 avenue du Colonel Roche, 31077 Toulouse Cedex

section 8 concludes the paper.
4. This work is supported by the RNRT project MP6.
 Office national d’études et de recherches aérospatiales, Cen-

tre de Toulouse, BP 4025, 31055 Toulouse Cedex 4.

2 Discretionary access control First, the concept of permission is primitive. When
specifying the security policy of a given application,
Harrisson, Ruzzo and Ullman[11] define a security pol- the RBAC model must be refined to make explicit
icy model, the HRU model, that applies to subjects, the structure of permissions. It is argued that this is
objects and actions. Intuitively, a subject is an ac- because this structure might depend on the applica-
tive entity. In the context of an information system, tion. We consider that it would be better to include
it includes the users of this system and, generally, the a generic structure of permissions in the model. In
processes that run on behalf of these users. The set of our model, permissions as well as prohibitions, obli-
objects contains the set of all active entities. It also in- gations and recommendations are represented by re-
cludes non-active entities. For instance, in an informa- lationships. Second, the concept of role hierarchy is
tion system, files and directories are objects. Actions not free of ambiguity. In particular, it is generally
enable the subject to have direct access to objects. incorrect to consider that it corresponds to an orga-
They generally correspond to elementary actions such nizational hierarchy. For instance, the director of an
as reading a file or writing a file. In this model, the hospital is the head of the physicians of this hospi-
security policy is limited to the specification of permis- tal. However, director is an administrative position
sions, i.e. relationships between subjects, objects and and it is not required to be a physician to hold this
actions. These relationships are generally represented position. Therefore, it would be incorrect to consider
by a matrix A of permissions. If s is a subject and o that the role director inherits all the permissions of
is an object then A(s, o) represents the set of actions the role physician. This has been acknowledged by
α that subject s is permitted to execute on object other authors, including the possible need to maintain
o. In the HRU model, it is necessary to enumerate, different hierarchies. Third, the distinction between
through a matrix of permissions, all the triples s, o, α the concepts of role and group is not clear. Group is
that correspond to a permission granted by the secu- a concept that was used before the definition of the
rity policy. When new subjects, new objects or new RBAC model and there were many discussions about
actions are introduced in the system, it is necessary the difference between access control models based on
to update the security policy in order to record the user groups and RBAC. The ORBAC model suggested
permissions granted to these new entities. As a result, in section 4 attempts to clarify this point.
the updating of security policies specified according to In other respect, it is not possible, in the RBAC
this model become quite complicated. Another limit model, to specify a permission that depends on a
of the HRU model is that it only enables the admin- given context. More precisely, if a given permission
istrator to specify permissions. Neither prohibitions, is granted to a given role, then all users that play this
obligations nor recommendations are included. role will inherit the given permission. Therefore, it is
not possible to specify that a physician is permitted
to have a direct access to the patient records, unless
3 Role based access control he/she is one of the physician’s patient[12, 13]. More-
over, as mentioned in the previous section, another
In the Role based access control model, the RBAC
limit of the RBAC model is that it only enables the
model, the security policy does not directly grants per-
administrator to specify permissions. Finally, addi-
missions to users but to roles[5]. A given user will ob-
tional limits appear when the RBAC model is used to
tain permissions by playing roles, in which case this
specify the security policy of a system that includes
user will inherit all the permissions associated with
several organizations.
these roles. It is possible to refine this model by includ-
ing the concepts of session and role hierarchy. Within
a session, a user is not obliged to activate all his/her 4 Organization based access
roles but only the subset of his/her roles that are nec-
essary to perform a given task. The role hierarchy is control
useful because permissions are inherited through this
hierarchy. This simplifies the security policy specifi- To overcome their limitations, several authors have
cation. In the complete model, it is also possible to recently proposed improved versions of these access
specify constraints. For instance, we may specify that control models. Some models include temporal con-
there is no user that can play both roles anaesthetist straints and support the periodic activation of roles
and surgeon. [14, 15]. Other models considers that each organiza-
The RBAC model has the following drawbacks. tion has to define its own internal security policy while
respecting the constraints imposed by the global secu- entities together: the relationship Employ (see fig-
rity policy [16]. And finally there are models based ure 1). If org is an organization, s a subject and r a
on the notion of coalitions, i.e., sets of organizations role, then Employ(org, s, r) means that org employs
that collaborate together to fulfil their missions [17]. subject s in role r. Unlike the TMAC model or the
In this paper, we try to overcome the limitations of
these access control models by considering the con- Subject Employ Role
cept of organization together with the concept of con- 0,n 0,n

text. In this section, we present our ORBAC model

using a diagrammatic language based on the entity-
relationship model. A presentation of our ORBAC 0,n

model using a formal language based on first-order

logic will be proposed in section 5. In accordance with
Organization
the entity-relationship model, the entities and the re-
lationships of our ORBAC model may be associated
with attributes. Since these attributes are generally
specific to a particular application, we do not include Figure 1: The Employ relationship
them in the diagrammatic presentation.

RBAC model which consider binary relations between

4.1 Organizations
organizations and subjects or between subjects and
The most important entity in our model is the en- roles, notice that our model consider a ternary rela-
tity Organization. In the health care domain, we tion between organizations, subjects and roles. Again,
can take the following organizations: “Languedoc pri- let us remark that subjects might be users as well as
vate clinic”, the “casualty department of Purpan hos- organizations. To illustrate the truth of this, one has
pital”, the “intensive care unit of Rangueil hospital”, only to mention the examples:
etc. Roughly speaking, an organization can be seen
• Employ(P urpan, John, cardiologist): “the
as an organized group of active entities, i.e. subjects,
Purpan hospital employs John as a cardiolo-
playing some role or other. Notice that a group of
gist” and
subjects does not necessarily correspond to an orga-
nization. More precisely, the fact that each subject • Employ(Rangueil, ICU 31, intensive−care−
plays a role in the organization corresponds to some unit): “the Rangueil hospital employs ICU31
agreement between the subjects to form an organiza- as an intensive care unit”.
tion.
4.3 Objects and views
4.2 Subjects and roles
In our model, the entity Object will mainly cover in-
The entity Subject is used differently from one secu- active entities such as data files, emails, printed forms,
rity model to another. In our ORBAC model, a sub- etc. In the health care domain, we will also have to
ject will be either an active entity, i.e. a user, or an consider objects like administrative records, medical
organization. Examples of subjects therefore include records and surgical records of patients. By means
users such as “John”, “Mary”, “Peter”, etc, or organi- of the entity Role, we will be able to structure the
zations such as the “accounts department of Langue- subjects and to update easily security policies when
doc private clinic”, the “casualty department of Pur- new subjects are added to the system. Seeing that
pan hospital”, the “intensive care unit of Rangueil we will also have to structure the objects and to add
hospital”, etc. In our model, the entity Role is used new objects to the system, we believe that a similar
to structure the link between subjects and organiza- entity regarding objects is needed: the entity V iew.
tions. In the health care domain, the roles “cardi- Roughly speaking, as in relational databases, a view
ologist”, “nurse”, “physician”, etc, will be played by corresponds to a set of objects that satisfy a common
users whereas the roles “casualty department”, “res- property. For instance, in a file management system,
cue team”, “intensive care unit”, etc, will be played by the view “administrative record” corresponds to the
organizations. Seeing that subjects play roles in orga- administrative records of patients whereas the view
nizations, we need a relationship that joins up these “medical record” corresponds to the medical records
of patients. Seeing that views characterize the ways
objects are used in organizations, we need a relation- Consider (see figure 3) will be used to join up the en-
ship that links together these entities: the relationship tities Organization, Action and Activity. More pre-
U se (see figure 2). If org is an organization, o is an ob- cisely, if org is an organization, α is an action and a is
ject and v is a view, then U se(org, o, v) means that org an activity, then Consider(org, α, a) means that org
uses object o in view v. We wish to focus the attention considers that action α falls within the activity a. Let

Object Use View Action Consider Activity

0,n 0,n 0,n 0,n

0,n 0,n

Organization Organization

Figure 2: The U se relationship Figure 3: The Consider relationship

on the fact that our model considers a ternary relation us remark again that Consider is a ternary relation
between organizations, objects and views. Our aim is between organizations, actions and activities. What
to make ourselves able to characterize organizations we have in mind is to be able to characterize organi-
that give different definitions to the same view. Take zations that differently structure the same activities.
the case of the view “medical record” defined in Pur- We should consider, for instance, that activity “con-
pan hospital as a set of Word documents and defined sulting” corresponds, in Purpan hospital, to an action
in Rangueil hospital as a set of Latex documents: “read” that can be ran on data files whereas it corre-
• U se(P urpan, F 31.doc, medical−record): “the sponds, in Rangueil hospital, to action “select” that
Purpan hospital uses F31.doc as a medical can be performed on relational databases:
record” and • Consider(P urpan, read, consulting): “the Pur-
• U se(Rangueil, F 32.tex, medical−record): “the pan hospital considers read as a consulting” and
Rangueil hospital uses F32.tex as a medical • Consider(Rangueil, select, consulting): “the
record”. Rangueil hospital considers select as a consult-
ing”.
4.4 Actions and activities
Security policies specify the authorized accesses to in- 4.5 Security policy (first definition)
active entities by active entities and regulate the ac-
Using the entities and the relationships introduced
tions carried out in the system. In our model, the
in the previous sections, we are now in a posi-
entity Action will mainly contain computer actions
tion to define security policies applying to such or
such as “read”, “write”, “send”, etc. Following the
such organization. A security policy specifies the
line of reasoning suggested in sections 4.2 and 4.3
authorized accesses of a system through a set of
where subjects and objects were abstracted by means
permissions, prohibitions, obligations and recom-
of roles and views, a new entity will also be used
mendations. In the following discussion, we consider
to abstract actions: the entity Activity. Seeing that
only the concept of permission, given that similar
roles associate subjects that fulfil the same functions
arguments can be developed regarding the concepts of
and views correspond to sets of objects that satisfy
prohibition, obligation and recommendation. What
a common property, activities will join actions that
we have in mind is to extend our model with a
partake of the same principles. In our model, ac-
relationship P ermission for the purpose of being
tivities like “reading”, “writing”, “consulting”, etc,
able to join together organizations, roles, views and
will be of the utmost interest. Since different or-
activities. More precisely, if org is an organization,
ganizations may decide that one and the same ac-
r is a role, v is a view and a is an activity, then
tion comes under distinct activities, the relationship
P ermission(org, r, v, a) means that organization org Action
grants role r permission to perform activity a on view
v. For example, take the case of Purpan hospital
granting role “medical secretary” permission to
perform activity “creation” on view “administrative 0,n

record”, a security requirement expressed by the fol-

lowing fact P ermission(P urpan, medical−secretary,
Subject Define Object
administrative− record, creation). However, the se- 0,n 0,n

curity requirement expressed by P ermission(P urpan,

physician, medical−record, consulting) says that
Purpan Hospital grants role “physician” permission 0,n 0,n
to perform activity “consulting” on view “medical
record”. It is highly likely that this security require-
ment is not exactly what Purpan hospital wants Organization Context
to specify: in normal circumstances, a physician
is permitted to consult the contents of only those
patient medical records for which he is the attending
Figure 4: The Def ine relationship
physician. The truth of the matter is that the OR-
BAC model described above simply cannot cope with
such security requirement: given an organization,
users inherit permissions from the roles they play in latter fact is true then Mary must be the attending
that organization. To solve this problem, we propose physician of the patient concerned by medical record
to extend our model with a new entity. F32.tex: in normal contexts such as “attending
physician”, physicians are permitted to consult the
4.6 Contexts contents of only those patient medical records for
which they are the attending physician.
Roughly speaking, contexts will be used to specify
the concrete circumstances where organizations
4.7 Security policy (final definition)
grant roles permissions to perform activities on
views. In the health care domain, our new entity In view of our new entity Context, we can now
Context will cover circumstances such as “urgency”, give the final definition of security policies applying
“industrial medicine”, “attending physician”, etc. to such or such organization. The relationship
Every context can be seen as a ternary relation P ermission now corresponds to a relation be-
between subjects, objects and actions defined within tween organizations, roles, views, activities and
such or such some organization. Therefore, entities contexts. The relationships P rohibition, Obligation
Organization, Subject, Object, Action and Context and Recommendation are defined similarly (see
are linked together by the relationship Def ine (see figure 5). If org is an organization, r is a role, v
figure 4): if org is an organization, s is a subject, is a view, a is an activity and c a context then
o is an object, α is an action and c a context, then P ermission(org, r, v, a, c) means that organization
Def ine(org, s, o, α, c) means that within organization org grants role r permission to perform activity a on
org, context c is true between subject s, object o and view v within context c. For instance, the security
action α. The conditions required for a given context policy of Purpan hospital may include the facts
to be linked, within a given organization, to subjects, P ermission(P urpan, physician, medical−record,
objects and actions will be formally specified by consulting, urgency) “Purpan hospital grants
logical rules. This issue will be addressed in section 5. physicians permission to consult medical
In the meantime, let us consider the following facts: records within the context urgency” and
Def ine(P urpan, John, F 31.doc, read, urgency) P ermission(P urpan, physician, medical−record,
and Def ine(Rangueil, M ary, F 32.tex, read, consulting, attending−physician) “Purpan hospital
attending− physician). If the former fact is true grants physicians permission to consult medical
then there is no need for John to be the attending records within the context attending physician”.
physician of the patient concerned by medical record
F31.doc: in circumstances such as “urgency”, physi-
cians have a direct access to medical records. If the
 Action, Activity and Context) and 12 relationships
Organization Context
(Employ, U se, Consider, P ermission, P rohibition,
Obligation, Recommendation, Is− permitted,
0,n
0,n 0,n
0,n
Is− prohibited, Is− obliged, Is− recommended and
Role
0,n
0,n 0,n
0,n Def ine).
Permission View
0,n 0,n
0,n Prohibition 0,n
0,n
0,n
0,n Obligation 0,n Action

Recommendation

0,n 0,n
0,n 0,n
0,n 0,n
0,n 0,n
0,n Subject Is_permitted Object
0,n 0,n
0,n 0,n 0,n
Is_prohibited 0,n
0,n
0,n 0,n
Activity Is_obliged
0,n
Is_recommended

0,n Define Consider 0,n

0,n

0,n 0,n
0,n

Employ Organization Context Use

Figure 5: The P ermission, P rohibition, Obligation 0,n

and Recommendation relationships 0,n

0,n 0,n 0,n 0,n

0,n 0,n 0,n
0,n 0,n
0,n 0,n
Role Permission View
0,n 0,n
0,n 0,n
0,n
Prohibition 0,n

4.8 Concrete authorization 0,n

Obligation 0,n

Recommendation

The relationship P ermission enables a given organi- 0,n

0,n

0,n

zation to specify permissions granted in a given con- 0,n

text. Such permissions correspond to a ternary re- Activity

lation between roles, views and activities. However,

down-to-earth access control must provide a frame-
work for describing the concrete actions that may Figure 6: The ORBAC model
be performed by subjects on objects. For the pur-
pose of modelling concrete permission, we introduce
in our model the relationship Is− permitted as a re- 5 Language and axiomatical
lationship between subjects, objects and actions, i.e.
if s is a subject, o is an object and α is an ac- presentation
tion then Is permitted(s, o, α) means that subject s The purpose of this section is to present a logical
is permitted to perform action α on object o. Re- framework that provides a means of representation
lationships such as Is− prohibited, Is− obliged and and reasoning about permissions, prohibitions, obli-
Is− recommended could be defined in the same way. gations and recommandations in a given universe of
Our relationship Is− permitted is similar to the no- entities. What we have in mind is to associate a first-
tion of permission suggested in the model HRU. There order language L to the entity-relationship diagram
is, however, a difference of major importance. In the described above. Our first-order language will pro-
original model HRU, each authorized triple s, o, α vide a syntax capable of expressing precise statements
must be explicitly stated, although more expressive about the relationships holding between entities. Each
discretionary access control models where permissions expression of L will contain symbols from a particular
are logically derived have been proposed. In our limited vocabulary separated into four groups: con-
model, triples that are instances of the relationship stant symbols, individual variables, relation symbols
Is− permitted are logically derived from permissions and function symbols.
granted to roles, views and activities by the relation- The constant symbols will correspond to the in-
ship P ermission. This is modelled by a general rule stances of the entities of our diagram. As a
that will be presented in section 5. Explicit instances result, there will be as many types θ of con-
of the relationship Is− permitted may be viewed as stant symbols as there are entities in our dia-
exceptions to the general security policy specified by gram, i.e. 8: Organization, Subject, Object,
the relationship P ermission. Action, Role, V iew, Activity and Context. For
Figure 6 resumes our security model. It contains 8 instance, we will have: constant symbols of type
entities (Organization, Subject, Role, Object, V iew, Organization like P urpan, Rangueil, ICU 31, etc,
constant symbols of type Subject like Jean, M ary, ture of the attribute it corresponds to. If a function
ICU 31, etc, constant symbols of type Object like symbol corresponds to the attribute N ame, then it is
F 31.doc, F 32.doc, F 33.tex, etc, constant symbols of type Subject and its range is a set of names. Simi-
of type Action like read, write, consult, etc, con- larly, a function symbol corresponding to the attribute
stant symbols of type Role like physician, nurse, Age will be of type Subject and its range will be the
intensive−care− unit, etc, constant symbols of type set of all positive integers. Take another example: if
V iew like administrative− record, medical− record, a function symbol must correspond to the attribute
surgical− record, etc, constant symbols of type Blood− group, then it is of type Subject and its range
Activity like reading, writing, consulting, etc. Con- is {A, AB, B, O}. Since there might exist nameless
stant symbols will be denoted by lower case Latin let- subjects or subjects the blood group of which is not
ters like a, b, c, etc. known, then the function symbols of L will only repre-
Similarly, there will be individual variables for each sent partial mappings between entities and associated
type θ. They will be denoted by lower case Latin let- ranges. In many real situations, we are not able to as-
ters like x, y, z, etc. For all types θ, constant symbols sign a single value of an attribute to an entity. To deal
of type θ and individual variables of type θ will also with such situations on a conceptual level, we will use
be called θ-terms. unary function symbols the associated ranges of which
As for the relation symbols of L, denoted by are power sets. To illustrate the truth of this, one has
capital Latin letters P , Q, R, etc, they will cor- only to mention the attribute Attending− physician:
respond to the 12 relationships of our diagram. the associated function symbol is of type Subject and
Each relation symbol P of L is assumed to be a the associated range is a set of finite sets of names.
typed relation. More precisely: Employ is a relation In order to draw conclusions from the partial in-
symbol of type (Organization, Subject, Role), formation represented by function symbols, we need
U se is a relation symbol of type to introduce concrete binary relations, denoted by σ,
(Organization, Object, V iew), Consider is a relation τ , μ, etc, between domains. The type of a concrete
symbol of type (Organization, Action, Activity), binary relation is the pair consisting of the domains
P ermission, P rohibition, Obligation and it corresponds to. Equality is probably the simplest
Recommendation are relation symbols of type concrete binary relation we will have to consider. We
(Organization, Role, V iew, Activity, Context), should consider the following examples:
Is− P ermitted, Is− P rohibited, Is− Obliged
and Is− Recommanded are relation sym- • If t and u are terms of type Subject,
bols of type (Subject, Object, Action) and then Attending− physician(t) =
Def ine is a relation symbol of type Attending− physician(u) means that subjects t
(Organization, Subject, Object, Action, Context). and u have the same attending physicians,
Using terms and relations, we can introduce • If t and u are terms of type Subject, then
the atomic formulas of L as follows: if t1 is a Age(t) = Age(u) means that subjects t and u
θ1 -term, . . ., tn is a θn -term and P is a rela- have the same age and
tion symbol of type (θ1 , . . . , θn ) then P (t1 , . . . , tn )
is an atomic formula. Examples of atomic for- • If t and u are terms of type Subject, then
mulas are Employ(P urpan, John, physician) Blood− group(t) = Blood− group(u) means that
and P ermission(Rangueil, medical−secretary, subjects t and u have the same blood group.
administrative− record, creation, normal).
At this point, our language is not expressive enough Obviously, there are cases where other concrete binary
to capture the possibility to compare entities. In many relations must be considered. For instance:
applications, we are given a universe of entities and we • If t and u are terms of type
wish to derive information about some of their prop- Subject, then Attending− physician(t) ∩
erties. From a formal point of view, function symbols Attending− physician(u) = ∅ means that sub-
will be of use to us for describing or defining these en- jects t u have a common attending physician,
tities. Function symbols will be denoted by lower case
Latin letters like f , g, h, etc. Each function symbol • If t and u are terms of type Subject, then
f corresponds to some attribute, hence it is a typed Age(t) < Age(u) means that subject t is younger
function and it has an associated range Vf . The type than subject u and
and the range of a function symbol depend on the na-
 • If t and u are terms of type Subject, then 1. ∀s∀o∀α∀r∀v∀a∀c
Blood− group(t) ∼ Blood− group(u) means that P ermission(org, r, v, a, c)∧
the blood groups of t and u are compatible. Employ(org, s, r)∧
U se(org, o, v)∧
Such kind of formulas will also be considered as atomic
Consider(org, α, a)∧
formulas. Finally the formulas of L are defined as
Def ine(org, s, o, α, c) → Is− permitted(s, o, α):
follows:
if organization org, within the context c, grants
• an atomic formula is a formula, role r permission to perform activity a on view
v, if org employs subject s in role r, if org uses
• if A is a formula then ¬A “not A” is a formula, object o in view v, if org considers that action α
• if A and B are formulas then (A ∧ B) “A and falls within the activity a and if, within org, the
B” and (A ∨ B) “A or B” are formulas and context c is true between s, o and α then s has
permission to perform α on o,
• if A is a formula and x is an individual variable
then ∀xA “for all possible values of variable x, 2. ∀r∀v∀a∀c(Obligation(org, r, v, a, c) →
A” and ∃xA “there exists possible values of vari- Recommendation(org, r, v, a, c): every obli-
able x such that A” are formulas. gation is also a recommendation,
We shall use in our expressions the shorthands → and 3. ∀r∀v∀a∀c(Recommendation(org, r, v, a, c) →
↔ as in Boolean logic: (A → B) is (¬A ∨ B), and P ermission(org, r, v, a, c): every recommenda-
(A ↔ B) is ((A → B) ∧ (B → A)). We shall also tion is also a permission and
omit parentheses when there is no risk of ambiguity.
Examples of formulas are: 4. ∀r∀v∀a∀c(P ermission(org, r, v, a, c) →
¬P rohibition(org, r, v, a, c): no permission
• ∀s(Employ(Rangueil, s, P hysician) → is a prohibition.
Employ(Rangueil, s, T reating−staf f )) “every
physician in the Rangueil hospital is also Axiom 1 describes how abstract permissions between
employed as a treating staff” and roles, views and activities can be transformed into con-
crete permissions between subjects, objects and ac-
• ∀r∀v∀a(P ermission(Rangueil, r, v, a, tions. Similarly, axioms for obligation, recommenda-
attending−physician) → tion and prohibition are defined.
P ermission(Rangueil, r, v, a, urgency)) “if
Rangueil hospital grants role r permission
to perform activity a on view v in the con- 6 Example of a security policy
text attending physician then it grants the
corresponding permission within the context In this section, we show how a simple security policy
urgency”. can be expressed in our first-order language.
The truth value of a formula is determined by the val-
ues of its subformulas in a given model. The models 6.1 Subjects and roles
for our language consists, first, of 8 nonempty sets We consider only one organization: Purpan hospital
corresponding to the 8 entities of our diagram and, (see figure 7). Purpan hospital employs several sub-
second, of 12 relations corresponding to the 12 rela- jects: John as a director, Mary as an administrative
tionships of our diagram. We shall assume that the assistant, ST1 as a surgical team and RT2 as a radi-
precise formulation of the key definition of a formula ological team. In our language, this is represented by
being true in a model is already quite familiar to the the following instances of the Employ relationship:
reader.
Axioms of a first-order theory are usually subdi- • Employ(P urpan, John, director),
vided into logical axioms and nonlogical axioms. The
logical axioms provide a basis for proving all theorems • Employ(P urpan, M ary, administrative−assistant),
of first-order classical logic, whereas the nonlogical ax- • Employ(P urpan, ST 1, surgical−team) and
ioms deal with some specific subject matter. Apart
from the logical axioms, all security policies will be • Employ(P urpan, RT 2, radiological−team).
based on the following list of nonlogical axioms for all
organizations org:
 John • medical− record: this corresponds to the patient
(director) medical records and
Purpan_hospital
(hospital)
Mary • surgical− record: this corresponds to private
(admin_assistant)
records managed by the surgical team.
We consider that objects belonging to these views have
an attribute, called N ame. If F31.doc is a record be-
Red_team White_team longing to one of these views, then N ame(F 31.doc)
(surgical_team) (radiology_team)
provides the name of the patient who is associated
Jane Dick
with record F31.doc. We also assume that various
(head_surgeon) (radiologist) records are directly managed by Purpan hospital, for
Paul Fred instance in a relational database. In our model, this
(surgeon) (radiologist_assistant) means that various facts have the following forms:
Peter Peter
(nurse) (radiologist_assistant) • U se(P urpan, F 31.doc, administrative−record),
Max Lucy • U se(P urpan, F 32.doc, medical−record) and
(anesthetist) (medical_secretary)
• U se(P urpan, F 33.tex, surgical−record).
Figure 7: A simple organization
ST1, the surgical team, and RT2, the radiological
In these facts, director, administrative− assistant, team, actually share the database managed by Pur-
surgical− team and radiological− team are roles. We pan hospital. This means that they use the same ob-
can similarly specify that the sub-organization ST 1 jects in the same view as the hospital. This can be
employs other subjects: Jane as the head of the surgi- expressed by the following rules:
cal team, Paul as a surgeon, Peter as a nurse and Max • ∀o∀v(U se(P urpan, o, v) → U se(ST 1, o, v) and
as an anaesthetist. In our language, this is represented
• ∀o∀v(U se(P urpan, o, v) → U se(RT 2, o, v).
by other instances of the relationship Employs such
as: We can define a fourth view, called patient−record
with three attributes Administrative− record,
• Employ(ST 1, Jane, head−surgeon), M edical−record and Surgical− record as follows:
• Employ(ST 1, P aul, surgeon), • ∀o(U se(P urpan, o, patient− record) ↔
∃o1 ∃o2 ∃o3 U se(P urpan, o1 , admin− record) ∧
• Employ(ST 1, P eter, nurse) and
U se(P urpan, o2 , medical record) ∧
• Employ(ST 1, M ax, anaesthetist). U se(P urpan, o3 , surgical record) ∧
Administrative− record(o) =
Various subjects employed by the radiological team o1 ∧ M edical−record(o) = o2 ∧
would be similarly represented. In the sequel, we shall Surgical−record(o) = o3 ∧ N ame(o1 ) =
consider that the entity Subject is associated with an N ame(o2 ) = N ame(o3 )).
attribute P atient that provides the set of patients
of any given subject. Therefore, our language in- The view patient− record corresponds to the com-
cludes a partial function P atient with domain Subject plete patient’s record. In a relational database,
and range a set of finite sets of names. For instance this would be obtained by joining the views
P atient(P urpan) and P atient(Dick) provide the sets administrative− record, medical− record and
of patients associated to Purpan hospital and Dick re- surgical− record, considered as relations, through
spectively. attribute N ame.

6.2 Objects and views 6.3 Actions and activities

We consider objects that belong to the following views: We only consider activities that perform a direct
access to the records, namely creation, consulting,
• administrative− record: objects belonging to writing, etc. If we assume that the records are man-
this view provide various administrative data aged through a relational database, these activities
about patients such as their name, their address, will respectively correspond to actions such as insert,
their age, etc, select, update, etc. This is specified by rules such as:
 • Consider(P urpan, select, creation), third permissions specify that RT2 permits physicians
to consult a medical or a surgical record if this record
• Consider(P urpan, select, consulting) and corresponds to a patient of RT2. As one may notice,
• Consider(P urpan, update, writing). the permissions associated with the role physician can
change from one organization to another and the re-
spective context may be also different. In our example,
6.4 Context this is especially useful since the circumstances where
We shall only model two different contexts in our ex- a physician will consult a medical record may be dif-
ample: “attending physician” and “attending team”. ferent in a surgical team or a radiology team.
The context “attending physician” is defined within
ST1, the surgical team, as follows: 6.6 Hierarchies
• ∀s∀o∀α(def ine(ST 1, s, o, α, attending− Up to now, we do not discuss the notion of role hierar-
physician) ↔ N ame(o) ∈ P atient(s)) that is, chy in our model. This notion was first introduced in
in ST1, the context “attending physician” is the RBAC model [6] so that permissions are inherited
true between subject s, object o and action α through this hierarchy. In our approach, role hierar-
if and only if o is a record corresponding to a chy is not modelled as a basic concept. Inheritance
patient of subject s. of permissions, within ST1 between a role r1 , for in-
stance physician, and role r2 , for instance surgeon, is
The context “attending team” is defined as follows: specified by the following rule:
• ∀s∀o∀α(def ine(ST 1, s, o, α, attending−team) ↔
• ∀v∀a∀c(P ermission(ST 1, r1 , v, a, c) →
∃r(Employ(ST 1, s, r) ∧ N ame(o) ∈
P ermission(ST 1, r2 , v, a, c).
patients(ST 1)) that is, in ST1, the con-
text “attending team” is true between subject So, we may insert a relation Sub− role(ST 1, r1 , r2 ) in
s, object o and action α if and only if s plays our language but instances of this relation would be
some role in ST1 and o is a record corresponding simply defined as equivalent to the above rule. No-
to one of the patients treated by ST1. tice however that, in our model, we can specify that
inheritance between two given roles only applies to a
As for the context urgency, it may be defined as fol-
given organization and would be false in another one.
lows within ST1:
For instance, we can specify that, in Purpan hospital,
• ∀s∀o∀α(def ine(ST 1, s, o, α, urgency) ↔ true) the role director inherits the permissions of the role
that is, in ST1, the context “urgency” is always physician. This would be expressed by the following
true between subjects, objects and actions. rule:

• ∀v∀va∀c(P ermission(P urpan, physician, v, a, c)

6.5 Security policy → P ermission(P urpan, director, v, a, c).
We have no room in this paper to develop a complete But of course, this rule might not be available if we
specification of a security policy that applies to an hos- change P urpan into another hospital in which it would
pital. We shall only present few examples to illustrate be possible to be director without being physician. In
the capabilities of our model. So let us consider the our model, it is also possible to specify that inheri-
following permissions: tance between roles applies to prohibition, obligation
• P ermission(RT 1, physician, medical−record, or recommendation. It is also useful to specify a hi-
consulting, attending−physician), erarchy between views and to consider that permis-
sions are inherited through this hierarchy, and simi-
• P ermission(RT 2, physician, medical−record, larly for a hierarchy between activities. For instance,
consulting, attending−team) and we may consider that views administrative− record,
medical− recod and surgical− record are sub-views of
• P ermission(RT 2, physician, surgical−record, view patient− record, so that a given role who is per-
consulting, attending−team). mitted to perform an activity on view P atient−record
First permission specifies that RT1 permits physicians would also be permitted to perform the same activity
to consult a medical record if this medical record cor- on the sub-views. In our language, this would be ex-
responds to a patient of these physicians. Second and pressed by the following rule:
 • ∀r∀a∀c(P ermission(P urpan, r, patient− record, • how this organization is defining contexts that
a, c) → P ermission(P urpan, r, administrative− apply to users who are performing actions on ob-
record, a, c) jects, this is modelled through the relationship
Def ine.
and similarly for the views medical− record and
surgical− record. Using these concepts, a security policy that applies
to a given organization is defined as a collection of
permissions, prohibitions, obligations and recommen-
7 Constraints dations. A permission corresponds to a fact having
the form P ermission(org, r, v, a, c) to be read, in or-
Constraints were introduced in the RBAC model [6]. ganization org, within context c, role r is permitted to
In our model, constraints are expressed by rules that perform activity a on view v. P rohibition, Obligation
apply to various relations. We shall only give few ex- and Recommendation are similarly interpreted. We
amples: also have shown how to derive concrete permissions,
• ∀s(Employ(P urpan, s, surgical−team) → prohibitions, obligations and recommendations that
(∃s1 Employ(s, s1 , surgeon) ∧ apply to subjects, objects and actions. Several prob-
∃s2 Employ(s, s2 , anaesthetist) ∧ lems have not been addressed in this paper. First, it
∃s3 Employ(s, s3 , nurse)): this rule says may happen that the security policy is conflicting. For
that, if Purpan hospital employs s as a surgical instance, for a given subject, a given object and a given
team, then s employs a surgeon, an anaesthetist action, we have to detect and solve situations where
and a nurse, it is possible to derive both a concrete permission and
a concrete prohibition. Several proposals have been
• ∀s¬(Employ(P urpan, s, surgeon) ∧ suggested to deal with this problem[18, 19, 20]. The
Employ(P urpan, s, anaesthetist)): this rule approach we suggest to solve this problem is based
says that, in Purpan hospital, no subject s on possibilistic logic which enables us to automati-
can be employed both as a surgeon and an cally derive priority between facts that represent the
anaesthetist and security policy[21]. Due to space limitation, we do
not address the problem of administrating a secu-
• ∀s∀s (Employ(P urpan, s, director) ∧ rity policy defined in our model. A complete model
Employ(P urpan, s , director) → s = s : should clearly include such an administration model.
this rule says, in Purpan hospital, there is only For instance, [22] suggests the ARBAC model to ad-
one user who is playing the role director. ministrate RBAC security policy. The administration
We can similarly express other constraints model for ORBAC will be presented in a forthcoming
that apply to the relationships U se, Consider, paper. Finally, we have also to show how to specify
Def ine, P ermission, Obligation, P rohibition or security properties in the ORBAC model. In partic-
Recommendation. ular, we have to include means to specify when the
security policy is violated, and what happens in this
case, for instance when an obligation is not enforced.
8 Conclusion This represents further work that remains to be done.

This paper has presented a new security policy model

that aims to solve several limits of previous models. References
This model, called ORBAC, is centered on the con-
cept Organization. All other concepts that are used [1] B. Lampson, “Protection,” in 5th Princeton Sym-
to define a security policy depend on a given organi- posium on Information Sciences and Systems,,
zation: March 1971, pp. 437–443.

• how this organization is employing subject, this [2] D. E. Bell and L. J. LaPadula, “Secure computer
is modelled through the concept Role, systems: Unified exposition and multics interpre-
tation,” Tech. Rep. ESD-TR-73-306, The MITRE
• how this organization is using objects, this is Corporation, March 1976.
modelled through the concept V iew,
[3] K. J. Biba, “Integrity consideration for secure
• how this organization is performing actions, this computer systems,” Tech. Rep. MTR-3153, The
is modelled through the concept Activity and MITRE Corporation, June 1975.
 [4] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Access Control in Electronic Commerce Ap-
Kuhn, and R. Chandramouli, “Proposed NIST plications,” in 32nd Annual Hawaii Interna-
Standard for Role-Based Access Control,” ACM tional Conference on System Sciences (HICSS-
Transactions on Information and System Secu- 32), Maui, Hawaii, January 5–8 1999.
rity, vol. 4, no. 3, pp. 222–274, August 2001.
[14] E. Bertino, P.A. Bonatti, and E. Ferrari, “TBAC:
[5] S. I. Gavrila and J. F. Barkley, “Formal Specifica- A Temporal Role-Based Access Control for the
tion for Role Based Access Control User/Role and world wide web,” in Fifth ACM Workshop
Role/Role Relationship Management,” in Third on Role-Based Access Control, Berlin, Germany,
ACM Workshop on Role-Based Access Control, July 2000.
october 22–23 1996, pp. 81–90.
[15] J.B.D. Joshi, E. Bertino, and A. Ghafoor, “Tem-
[6] R. Sandhu, E. J. Coyne, H. L. Feinstein, and poral Hierarchies and Inheritance Semantics for
C.E. Youman, “Role-based access control mod- GTRBAC,” in Seventh ACM Symposium on Ac-
els,” IEEE Computer, vol. 29, no. 2, pp. 38–47, cess Control Models and Technologies (SACMAT
1996. 02), Monterey, California, USA, June 2002.

[7] R. Thomas and R. Sandhu, “Task-based Autho- [16] R. Viviani, “A Type/Domain Security Policy for
rization Controls (TBAC): A Family of Models Internet Trasmission Sharing and Archiving of
for Active and Enterprise-oriented Authorization Medical and Biological Data,” in International
Management,” in 11 th IFIP Working Confer- Workshop, Policies for Distriuted Systems and
ence on Database Security, Lake Tahoe, Califor- Networks (Policy 01), Bristol, UK, January 2001.
nia, USA, 1997. [17] E. Kohen, R. K. Thomas, W. Winsborough, and
[8] Roshan K. Thomas, “TMAC: A primitive for D. Shands, “Models for Coalition-Based Ac-
Applying RBAC in collaborative environment,” cess Control (CBAC),” in Seventh ACM Sympo-
in 2nd ACM, Workshop on RBAC, FairFax, Vir- sium on Access Control Models and Technologies
ginia, USA, November 6–7 1997, pp. 13–19. (SACMAT 02), Monterey, California, USA, June
2002.
[9] C. Bettini, S. Jajodia, X. S. Wang, and D. Wije-
[18] E. Bertino, S. Jajodia, and P. Samarati, “Sup-
sekera, “Obligation Monitoring in Policy Man-
porting Multiple Access Control Policies in
agement,” in International Workshop, Poli-
Database Systems,” in IEEE Symposium on Se-
cies for Distributed Systems and Neworks (Policy
curity and Privacy, Oakland, USA, 1996.
2002), Monterey CA, June 5–7 2002.
[19] G. Dinolt, L. Benzinger, and M. Yatabe, “Com-
[10] N. Damianou, N. Dulay, E. Lupu, and M. Sloman, bining Components and Policies,” in Proc. of the
“The Ponder Policy Specification Language,” in
Computer Security Foundations Workshop VII,
International Workshop, Policies for Distributed
Franconia, USA, 1994.
Systems and Neworks (Policy 2001), Bristol, UK,
2001, pp. January 29–31. [20] F. Cuppens, L. Cholvy, C. Saurel, and J. Carrère,
“Merging Regulations: analysis of a practical ex-
[11] M. A. Harrison, W. L. Ruzzo, and J. D. Ullman, ample,” International Journal of Intelligent Sys-
“Protection in Operating Systems,” Communi- tems, vol. 16, no. 11, November 2001.
cation of the ACM, vol. 19, no. 8, pp. 461–471,
August 1976. [21] S. Benferhat, R. El Baida, and F. Cuppens,
“Modlisation des politiques de scurit dans le
[12] J. Barkley, K. Beznosoz, and J. Uppal, “Sup- cadre de la thorie des possibilits,” in Rencontres
porting Relationships in Access Control Usiong Francophones de la Logique Floue et ses Applica-
Role Based Access Control,” in Proceeding for tions, Montpellier, France, October 2002.
the ACM workshop on RBAC, Fairfax, Virginia,
USA, October 28–29 1999. [22] Ravi Sandhu, Bhamidipati, and Qamar Mu-
nawer, “The ARBAC97 Model for Role-Based
[13] E. C. Cheng, “An Object-Oriented Organiza- Administration of Roles,” ACM Transactions on
tional Model to Support Dynamic Role-based Information and System Security, vol. 2, no. 1,
February 1999.