Available online at www.sciencedirect.

com

The Journal of Systems and Software 81 (2008) 1306–1326

www.elsevier.com/locate/jss

Role engineering: From design to evolution of security schemes

Gilles Goncalves a, Aneta Poniszewska-Maranda b,*
a
LGI2A – Universite d’Artois, Technoparc-Futura, Bethune, France
b
Institute of Computer Science, Technical University of Lodz, Poland

Received 30 March 2007; received in revised form 21 August 2007; accepted 2 November 2007
Available online 21 November 2007

Abstract

This paper presents a methodology to design the RBAC (Role-Based Access Control) scheme during the design phase of an Infor-
mation System. Two actors, the component developer and the security administrator, will cooperate to define and set up the minimal
set of roles in agreement with the application constraints and the organization constraints that guarantee the global security policy of
an enterprise. In order to maintain the global coherence of the existing access control scheme, an algorithm is proposed to detect the
possible inconsistencies before the integration of a new component in the Information System.
Ó 2007 Elsevier Inc. All rights reserved.

Keywords: Security of information system; Access control; Role engineering; Role-based access control model; Constraints; UML (Unified Modelling
Language)

1. Introduction
Nowadays, with the world market development and the
acceleration of information exchanges, the Information
System (IS) of a company becomes increasingly strategic.
In this situation it becomes clear that a security system spe-
cific to the certain requirements needs to be developed to
protect the Information System against the threats from
the inside and outside of the organization.
The objective of information security is to reduce these
risks to the admissible level for the organization function-
ality. A financial compromise has to be found between
the price needed to pay to set up that level of safety in
the company and the loss caused by the absence or bad
functioning of any service given by the information system.
Therefore, the first question that should be asked is:
which menaces this information system has to face? Risks
analysis allows identifying the threats that press heavy on
the information system. It is then necessary to define the
security policy to set up the efficacious protections to
*
Corresponding author. Tel.: +48 42 632 80 65; fax: +48 42 630 34 14.
E-mail address: anetap@ics.p.lodz.pl (A. Poniszewska-Maranda).
secure the data against the threats identified earlier. Having
this policy defined, it is necessary to have the possibility to
configure the components of security architecture in order
to apply the security rules. The security of an information
system concerns all fields of information activity and all
actors of the company. With respect to application
domain, all security measures should concern (Tipton
and Krause, 2006; Tudor, 2006; Peltier et al., 2004):
– physical security: concerns all aspects of the material
components of a system and their environment,
– operating security: concerns the proper functionality of a
system, i.e. providing the availability and performance
of a system,
– logical security: assures the confidentiality and integrity
of data or services by controlling their accesses; concerns
the access control management based on the identifica-
tion, authentication and authorization,
– application security: concerns the protection of applica-
tions connected with the enterprise functionality and
the verification of a new applications introduced into
the system as regards their integrity and safety for the
enterprise,

0164-1212/$ - see front matter Ó 2007 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2007.11.003
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
– telecommunication and network security: the communica-
tion architecture should be evolutionary and safe for
both the users and data stored in the system.
As shown above, the system security is a complex approach
that requires, at the same time, the structuring methodolo-
gies to make its realization easy, and a strong implication
of the management team and its staff to assure their
success.
The logical access of the authorized persons to different
components (i.e. data, services) of an information system is
in the focus of studies presented in this paper. Therefore,
each identified user of a system does not have access to
all the functions and activities of the information system.
In an information system, data protection against
improper disclosure or modification is an important
requirement. The access control regulates what a user can
do directly and what the programs executed on behalf of
the user are allowed to do. The system administrators have
to implement access control mechanisms to protect the
confidentiality and integrity of applications and its data.
In the past, the user access was granted by adding neces-
sary permissions to each individual application, which
made the administration, involving many users and several
different applications, complicated and ineffective.
The alternative is not to assign users directly to permis-
sions for each application but to assign users to roles and
the permissions to roles for each application. Then any
change in the user’s position or their needs can be solved
by the administrator simply by assigning the user to
another role. Since roles contain appropriate permissions,
the administrator does not have to update authorizations
for each user application. Such situation can be solved by
using the role-based access control (RBAC) model as an
access control model in the security processes of an infor-
mation system. The RBAC model is an interesting alterna-
tive to the traditional access control models, like MAC
(Mandatory Access Control) (Bell and La Padula, 1975;
Sandhu, 1994; Sandhu and Jajodia, 1993) or DAC (Discre-
tionary Access Control) (Harrison et al., 1976; Castaro
et al., 1994; Sandhu, 1994; Sandhu and Jajodia, 1993).
The security administration in an information system is
a complex task. Numerous security constraints should be
formulated in order to define the security policy in a proper
way. The security constraints specified for an application
give the possibility to manage its complexity. The applica-
tion developer can define the security constraints associated
with this application. On the other hand, with his good
knowledge of the global security policy, the security admin-
istrator can set up the constraints on the global level. The
main difficulty is to assure the global coherence of all ele-
ments (applicative and organizational) when a new applica-
tion with new elements, i.e. roles, functions, permissions is
added into the existing information system.
The method developed in the project described in this
paper was supported by the object-oriented design
described in the UML. Owing to its high level diagrams,
1307
the UML (Booch et al., 1998; OMG, 2000, 2004) allows
to specify clearly the information system needs and facili-
tates the dialogue between different actors (i.e. user, devel-
oper, administrator) that interact in its design.
The objective of this paper is to present a security
schema of an information system basing on the RBAC
model. Such schema is created first of all during the design
phase of a system. In this creation process two actors
should cooperate with each other, the component devel-
oper and the security administrator, to determine the min-
imal set of user roles in agreement with the constraints that
guarantee the global security coherence of the system. The
paper describes this creation process proposing in the last
part the coherence algorithm in the field of access control
security of the information systems.
The paper is composed as follows: Section 2 presents
different models to control the logical access to the system
components and Section 3 the design methods of the infor-
mation systems. Section 4 gives the objective of our project
concerning the principal work about the role engineering.
Next, in Section 5 we present the general scheme of the pro-
posed approach to define and assign the roles to the infor-
mation system actors. The last Section 6 proposes more
precisely the management of global coherence of security
constraints in an evolutionary approach of the security
scheme (i.e. addition of new components to the existing
information system): the integration chain of constraints
in a coherent system, the definition of the system coherence
and the verification of the security system coherence. This
verification is realized using a proposed algorithm to assure
the system coherence.
2. Access control models
The purpose of access control is to limit the actions or
operations that a legitimate user of an information system
can perform. The access control in information system is
responsible for granting direct access to the system objects
in accordance with the modes and principles defined by
security policies. An access control system defines:
– Subject: the active entity of a system; very often it is a
user or an application that will interact with the IS.
– Object: the passive entity of the IS; it corresponds with
the information or the resources which the subjects
can access.
– Action: presents an activity realized during the access to
an object, for example: somebody desires to read or
write information or to execute an operation.
It is possible to assure the confidentiality of the informa-
tion (i.e. protection against the improper disclosure) and
its integrity (i.e. protection against the improper modifica-
tion) by prohibiting the direct access carried out by the
non-authorized subjects. The flow control or inference con-
trol should be set up to protect it against the indirect acces-
ses carried out by the authorized subjects abusing their
1308 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
privileges. If it is not possible to set up this control, the cod-
ing or signature mechanisms can be used to make the infor-
mation unintelligible or incoherent for the malicious
subject (Tipton and Krause, 2006; Tudor, 2006; Peltier,
2001).
The access control mechanism is composed of two com-
ponents (Fig. 1):
– the set of access policies and access rules: information
stored in the system is accessible via access modes that
determine the possibilities of accessing objects by
subjects,
– the set of control procedures (security mechanisms) that
check queries (i.e. requests for access) in agreement with
the suitable principles and rules; the access may be
allowed, denied or modified, including the filtering out
of the unauthorized data.
The security models have been defined in literature to
facilitate the process of setting up such architecture. The
discretionary model, DAC model (Discretionary Access
Control model) (Harrison et al., 1976), manages the users’
access to information based on the user identification and
on the rules defined for each user (i.e. subject) and each
object in the system using the access control matrix. For
each subject and object in a system there are authorization
rules that define the access modes of the subject to the
object. The access to an object in a specific mode is granted
only for subjects, for which an authorization rule exists and
is verified, otherwise it is denied. The most common form
of access administration is the ownership policy based on
the ownership of an object, which allows the object owner
to grant or deny another user the access rights to this
object. The management of discretionary models is difficult
because of the size of access control matrix and moreover
they are poorly adapted to the flow control (Castaro
et al., 1994; Sandhu, 1994; Sandhu and Jajodia, 1993).
For this reason, the mandatory model (MAC model -
Mandatory Access Control model) (Bell and La Padula,
1975; Sandhu, 1994; Sandhu and Jajodia, 1993), was pro-
posed. In this model each subject has their own authoriza-
tion level, which allows them the access to objects starting
from the classification level, which has lower or equal
range. The main inconvenience of this model is its static
Refused access
Access Control
request procedures Authorised access
Moditification request
Security
Access rules
policy
Fig. 1. Components of the access control system.
character (i.e. the absence of possibility to delegate the
rights) and its rigid centralized management.
The role-based access control model represents an inter-
esting alternative to these traditional models. The role-
based access control model - RBAC model - was defined
in the nineties of 20th century (Sandhu et al., 1996; Ferra-
iolo and Kuhn, 1992; Jajodia et al., 1998). This model
requires the identification of roles in a system. The role is
properly viewed as a semantic construction around which
access control policy is formulated. The role can represent
competency to do a specific task, and it can embody the
authority and responsibility. Ferraiolo et al. have proposed
in Ferraiolo et al. (2001) the NIST RBAC model and have
specified the functions to manage and maintain this model.
The RBAC model obtained the ANSI norm in March 2004
(ANSI INCITS, 2004).
Since the work of Sandhu and Ferraiolo on the RBAC
model many other access control models were proposed
to integrate other functional and organizational facilities
relative to the enterprise structures. The team notion pro-
posed in the TMAC model (Thomas, 1997; Georgiadis
et al., 2001), the task notion used in the TBAC model
(Coulourisand et al., 1998) or the organization notion of
the ORBAC model (El Kalam et al., 2003) were created
to better describe the cooperative enterprise activities.
However, the RBAC model seems to be the most popular
and most stable and for these reasons it was chosen at
the beginning of our study.
Recently, the arrival of the new trades joined with the
Internet development (i.e. e-business, supply chain manage-
ment, etc.) caused the necessity of new access protocols to
the IS objects, which should be more complex and more dis-
tributed. Park and Sandhu defined in UCON ABC model (Park
and Sandhu, 2004) the usage control as an access control
generalization used for security policy evaluation before
the access (as usual) and during the access to information
because security policy can dynamically vary. The security
policy based on the UCON ABC model is a set of authoriza-
tions (permissions), obligations and conditions to satisfy.
The definition of roles in the RBAC model implies the
determination of organizational roles of each person in a
given organization. This model provides support for sev-
eral important security principles (i.e. least privilege, privi-
lege abstraction and separation of duties) but does not
dictate how they should be put into practice. How to set
up the model in a new or an existing information system?
How to define the role engineering?
3. Design methods of information systems
Attempting to answer the previous questions, we stud-
ied, on one hand, the design methods of the information
systems and, on the other hand, the design methods of
information system security used in Europe. We tried to
identify the aspects in relation with the access control for
each of these methods. Taking this approach into consider-
ation, two distinct schools of design methods were
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
observed. However, no global method takes into account
both the design of information systems and the associated
security scheme.
On the level of design methods of the information sys-
tems the analytical approach (i.e. Cartesian approach)
can be distinguished, for example by SADT (Structured
Analysis Design Technique) developed by Doug Ross in
1977 (Ross, 1977) which operates on the division of compli-
cated system into functional blocks, and the systematic
method based on the general theory of biologic systems
that analyses a complex system as a whole (Le Moigne,
1994). In practice, these two approaches are used together
in the methods like Merise or Ossad to analyze the systems
which are simultaneously complicated and complex.
The Merise method (Melese, 1972) is imposed as a stan-
dard in design of information systems since the 80-ties in
Europe and it evolved with the strong development of
the object-oriented methods (Gabay, 1998; Kettani et al.,
1998). Merise proposes different abstraction models to
describe the information system and methodological steps
to design these models. In the organizational model, it is
possible to specify‘‘Who makes What, When and Where”
using the actor concept and the action/behavior concept.
The Ossad method (Chappelet and Snella, 1997), the
result of the ESPRIT project (European Strategic Program
for Research in Information Technology), is principally
based on the evolution of the organization in an enterprise.
In its descriptive model, the notions of role and action
allow to specify‘‘Who makes What” using the graphs.
Considering the methods related to the security manage-
ment we examined the Marion method and the Mehari
method currently used in Europe and in Quebec. They pro-
vide recommendations and the analysis of risks in the
information systems (Lamere, 1991). The Marion method
invented and developed since 1990 by CLUSIF (Club de
la Scurit des Systmes d’Information Franais – French Club
of Information System Security) allows defining three
schemes for the security of information systems. On the
local scheme, it is possible to specify the logic access con-
trol of an information system. The definition of general
access control rights is realized on the level of preliminary
scheme, which integrates the global policy of an enterprise.
The Mehari method (Methode Harmonise d’Analyse de
Risques – Harmonized Method of Risk Analysis), the
result of work on Melisa and Marion, is also realized by
CLUSIF and replaces the Marion method. It is composed
of guides, a set of knowledge database and motors. Logical
access control can also be taken into account by this
method.
To conclude our prospective work, there are not many
recommendations touching the access control on the level
of design methods like the Merise method. Moreover, there
are no methodologies to specify and to set up a role-based
model. Many research works on the role engineering (Sec-
tion 4) are currently studied, but in many cases they are not
connected to the design and the evolution of Information
System, which they are supposed to make safe.
1309
Considering that, the main objective of our work is to
propose a global approach to simultaneously design both
the Information System and its associated security scheme.
The security scheme, which is being focused on here, is
based on the access control model of RBAC type.
4. Role engineering
The research of roles to set up in an organization is a
complex task because very often the functions of actors
in an organization are few or badly formalized. Moreover,
the role concept is an abstract approach – it does not cor-
respond to a particular physical reality and therefore it is
very difficult to give definitions that comprise the whole
world. To conclude, the research of roles needs, like many
other scientific domains, a real engineering approach that
provides a guide to comprehend and maintain them.
Historically, Coyne in (Coyne (1996)) defined the role
engineering as the process of defining roles, permissions,
role hierarchies, constraints and assigning the permissions
to the roles. This is the preliminary stage before setting
up the access control system of RBAC type.
In order to explain the determination of roles and/or the
research of their associated permissions, many concepts
were proposed. Fernandez and Hawkins (1997) used
the‘‘use case” formalism to define the permissions associ-
ated to a given role.
Thomsen et al. (1998) proposed the RBAC-FNE model
(Role-Based Access Control Framework for Network
Enterprises) based on seven layers that may be exploited
by various users (i.e. application developer or system
administrator). The access to particular layers is connected
with functions and duties that a given user has obtained.
Among the seven layers, four are accessible to the applica-
tion developer and the remaining three - to the system
administrator. Epstein and Sandhu (1999) provided an
UML specification of the previous RBAC-FNE model.
Rockle et al. (2000) proposed in their work the process-
oriented approach for role finding starting from the busi-
ness processes of the enterprise. Their approach provides
the method to find the roles but does not address the prob-
lem of how to find the permissions and how to assign per-
missions to roles.
Schimpf (2000) proposed to organize the role engineer-
ing process and to follow a clearly defined life-cycle model
for roles. The maintenance and evolution of roles are taken
into account.
In his approach, Epstein and Sandhu (2001) proposed to
determine the roles and their associated permissions start-
ing from an extension of the RBAC model which includes
three new concepts between roles and permissions: jobs,
workpatterns and tasks.
Using a role classification, Crook et al. (2002) to identify
the roles in connection with the organizational structure of
an enterprise. Neumann and Strembeck (2002) proposed to
determine functional roles (and their associated permis-
sions) of an enterprise starting from the scenarios. A role
1310 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
is depicted using a collection of scenarios and each scenario
is associated with a set of particular access operations.
In the work of He and Antn (2003) a goal-driven role
engineering process is described, taking into account the
user privacy preferences. A‘‘Top-Down” approach allows
defining first the roles and next the permissions associated
with these roles.
As it was shown below, the problems arising from the
installation of hierarchy of roles and constraints have been
only superficially touched in these works. Moreover,
whereas everyone agrees that safety must be taken into
account as quickly as possible, the proposed role engineer-
ing approaches are often disconnected from the design and
the evolution of Information System for which they are
provided.
5. The global method
In the presented project we decided to approach the
access control problem of Information System by propos-
ing the associated RBAC model from its preliminary
design to its future evolutions (i.e. additions of the new
components into the information systems).
The objectives are, on one side, to make the work of
security administrator easier and, on the other side, to have
better coherence between the global security constraints of
an enterprise and the constraints related to different appli-
cations that compose the Information System.
First, the extension of standard RBAC model is intro-
duced for the specification of access control in the informa-
tion system. Next, the methodology that helps to set up
such a model is discussed, together with the development
and integration of a new component in the existing Infor-
mation System.
5.1. Extended RBAC model
The complexity of actual organizations (i.e. matrix
based organizational structure) has guided our proposition
to extend the standard RBAC model by role management
facilities that allow a finer distribution of responsibilities in
an enterprise (Fig. 2). For this reason, the function concept
is introduced (Poniszewska-Maranda et al., 2005). Such
distribution is also used in the OSSAD approach (Chapp-
elet and Snella, 1997) with the function level and activity
* 0..* * 0..*
Users * Roles * Functions *
* *
1 1..*
* Session
1..*
Operation
Fig. 2. Extension of RBAC model.
level given in the abstract model. Epstein and Sandhu
(2001) also proposed the analogue extension but with a
finer role distribution that contains three supplement levels
(job, workpattern, task).
Persons employed by a company can have many profes-
sional responsibilities. Therefore, a set of roles can be
attached to them. Each role defined in the extended RBAC
model allows the realization of a specific task associated
with an enterprise process. Since every role can contain
many functions that a user can apply, it is possible to
choose functions of the system that are necessary for it.
Consequently, a role can be viewed as a set of functions
that this role can take to realize a specific job. Because each
function can perform one or more operations, a function
needs to be associated with a set of related permissions.
To perform an operation one has the access to a required
object, so necessary permissions should be assigned to the
corresponding function. This way all the tasks and required
permissions are identified and they can be assigned to the
users to give them the possibility to perform the responsi-
bilities involved when they play a particular role.
This supplement level (i.e. the function level) allows
more flexibility in the security management and the parti-
tion of responsibilities. For example, the necessity arises
to set up a new organization in an enterprise or to integrate
a new application in the information system. This situation
generally causes the necessity to redistribute the functions
to different actors of this enterprise. In this case, the secu-
rity administrator should only modify the allocations of
functions to the roles, with the new reorganization in mind.
The users will always have the same roles but with new
assigned functions. Likewise, if a function should be chan-
ged in the enterprise, it is possible to update the allocations
of its permissions without any changes for the roles that
use this function. In order to do that, three supplement
relations have been introduced into the RBAC model:
– R–F relation, which assigns functions to roles,
– F–P relation, which realizes an association between per-
missions and functions
– F–F relation, which allows the inheritance relation between
the functions.
In the presented approach, one or more permissions can be
associated with each function. We consider an object-ori-
ented information system in which the properties of each
object are only accessible by the specific methods, like it
is in the IRIS model (Ahad et al., 1992). The hypothesis
of closed world allows to manage only the positive autho-
Permissions rizations. Therefore, the principle of least privilege is
*
* * adopted for the assignment of permission to the function.
1 1 Permission determines the right of particular method exe-
Method Object
cution on a particular object (Bhamidipati and Sandhu,
* *
1997). Thus the definition of permission can be formulated
1 1
Class
as follows:
A permission is defined by a function p(m, o), where m is a
method that can be executed on a set of object instances o
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
and the set o can be determined by a set of constraints cst(p)
concerning this permission.
By default, the permission is given to all instances of the
object class except the contrary specification. As a result,
this permission has to be defined only on these instances
of object class that satisfy a particular constraint (Section
6). This constraint precisely defines that the permission is
valid only for a subset of instances of the object class.
Distribution of roles can be exemplified by an applica-
tion found in a typical university information system.
The user‘‘professor” can have two roles: Teacher and
Researcher, to perform his teaching activity and research-
ing activity. The teaching role has a number of functions:
prepare lectures, give lectures, prepare exams, record
results, modify results, etc. The researching role contains
functions like: create a theory, test the theory, document
the results, etc. These functions are mapped to sets of per-
missions that grant the accesses to perform the works
required by each function. Fig. 3 presents the relations
between these elements.
5.2. Representation of extended RBAC model using the
UML concepts
The Unified Modelling Language (UML) is a high-pro-
file approach to model the information systems (Booch
et al., 1998; OMG, 2000; OMG, 2004). Being a standard
modelling language in the area of software engineering
the UML has also become a support for object-oriented
approaches. It contains a suite of diagrams for requirement
analysis, design and implementation phases of the system
development.
The use case diagram represents the functions of the sys-
tem from the users’ point of view. It determines the behav-
iour of the system without defining the internal structure of
the functions. According to the definition of UML meta-
model, each use case diagram contains some use cases
and each use case represents a particular collaboration
(i.e. scenario) between the actors and the system. To deter-
mine a given collaboration in detail an interaction diagram
should be defined. The interaction diagram describes the
behaviour of one use case (Booch et al., 1998; OMG,
2000; OMG, 2004). It represents the objects and messages
prepare lecture
give lecture
Teacher prepare exams p
record results
modify results
Professor p Permissions
create theory
p 1
Researcher test theory
document results
p
USER ROLES FUNCTIONS PERMISSIONS
Fig. 3. Example of roles-functions-permissions mapping.
1311
exchanged during the use case processing. There are two
types of standard interaction diagram: sequence diagram
and collaboration diagram. Both of them are defined to
capture how objects collaborate with each other to realize
the use case.
The UML gives the possibility to present the system
using different models. We propose to use the properties
of this language during the design phase of a whole Infor-
mation System or any part of it. This way we have the
opportunity to produce the related RBAC model. The pur-
pose of this part of our study is to show how it is possible
to implement and realize the extended RBAC model with
the use of UML diagrams. To accomplish this, the con-
cepts of UML and RBAC model (Fig. 4) should firstly
be joined (Poniszewska-Maranda et al., 2005). Two types
of UML diagrams have been chosen to provide the
extended RBAC model: use case diagram and sequence
diagram. Relationships between the UML concepts and
the RBAC concepts are presented below (Fig. 4).
5.2.1. Role-actor
The UML supports the concept of use case, on which
the entire developed system is based. This approach is real-
ized via use case diagram from which the concept of an
actor very close to that of the role concept in the RBAC
model is derived. In UML the actor defined as a role or
a set of roles played by a person or by a group of people
interacting with a system, represents a category of users
that share the same functions or the same activities in an
organization. Thus each specific user or a group of users
can be treated as an actor. However, as users can play dif-
ferent roles, it is more correct to view a role as an UML
actor.
5.2.2. Function – use case
A role is a set of functions represented in the UML by
means of the use cases. Each actor co-operates with one
or more use cases representing the essential functions of a
system. Use case can be viewed as a function of the
UML RBAC
1 Actor Role
Use Case *
Diagram 1
p p
p * Use Case Function
p 1
p *
Sequence Diagram or
p Collaboration Diagram
p
1
Objects
p Operations
* *
Objects Operations
Fig. 4. UML concepts and its relationships with the extended RBAC
model.
1312 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
extended RBAC model. For each role, the functions
needed by this role in order to co-operate with the system
can be chosen. This process is similar to that of connecting
actors with their use cases. Thus, in the application realized
using the UML, roles and their related functions can be
easily identified.
5.2.3. Methods and objects
Methods of extended RBAC model are represented in
the UML by the methods executed in different types of dia-
gram (i.e. sequence diagram, collaboration diagram), while
for the objects of RBAC model the UML object concept is
used.
5.2.4. Permissions – sequence diagram
A use case contains a sequence of actions executed by an
actor in a system. For the purpose of this study, sequence
diagrams have been chosen to describe the use cases (the
same results could be obtained with the use of collabora-
tion diagrams). A sequence diagram represents an interac-
tion of objects by means of a sequence of messages sent
between these objects. In each sequence diagram there is
one or more objects representing actors who in this way
participate directly in the process of sending messages
between the objects. Upon reception of a message the exe-
cution of the corresponding method is triggered.
A message sent to an object corresponds to a method
call. Access to the object is controlled with respect to the
right of the method execution possessed by a subject over
an object. For each subject the access model allows specifi-
cation of a list of methods that the subject can execute.
Thus, for each use case it is necessary to specify permissions
for the method execution. These permissions are assigned to
the functions by the function–permission (F–P) relation.
The situation when the interaction diagram involve
more than one actor is solved on the level of use case dia-
gram because this type of diagram shows all the actors
taking part in the realization of the use case (described
by the interaction diagram). If the actors are in relation
with an use case on the use case diagram it seems that they
will appear in the interaction diagrams describing this use
case and in consequence they will have some permissions
existing in these interaction diagrams. The actors are con-
verted into the RBAC roles assigned to the functions
received from the particular use cases. Of course, if for
example two actors exist in the same interaction diagram
is not mean that they both have the same permissions.
In most cases only one actor (the actor who initiates the
interaction) has the majority of the permissions. The sec-
ond actor or the other actors participating in the same
interaction have only part of permissions from it. Such sit-
uations concern only part of the use cases and their inter-
action diagrams. The conversion from UML to RBAC
concepts in such situation is not quite automatic and
sometimes it should be determinated by appropriate con-
straints that define the proper rights and permissions of
the actors.
5.2.5. Constraints
The concept of constraints of the RBAC model is con-
nected directly with that of the constraint concept existing
in the UML.
5.2.6. Relations
The relations that occur between the elements of the
RBAC model can also be found in the use case diagrams
and in the interaction diagrams. A use case diagram
exploits four types of relations between its elements:
– communication relation between an actor and a use
case, being a relation between a role and a function,
i.e. R–F relation,
– generalization relation between actors, representing a
heritage relation between roles (R–R relation),
– two types of relations: extension relation and utilization
relation, both of them occurring between use cases, rep-
resent relations between functions in RBAC model, i.e.
F–F relation.
5.3. Partition of responsibilities – process of role creation
Two types of actors cooperate in the design process of
an information system and its associated security scheme
(Goncalves et al., 2003; Poniszewska-Maranda et al.,
2005): the information system developer who knows the
specifications of IS that need to be realized and, from the
other side, the security administrator who has the knowl-
edge of the general security constraints that should be
respected on the enterprise level. The applied method
answers for the partition of responsibilities between these
two actors and for their cooperation to establish the global
access control (i.e. security schema) using the extended
RBAC model. This distribution is presented using the class
diagram in Fig. 5.
In the evolution process of an information system, a cli-
ent may ask the developer to realize a new application (i.e.
to add a new component to the existing IS). The applica-
tion developer defines the elements of this application
and its constraints corresponding to the client specifica-
tions. Next, the security administrator defines administra-
tion rules and enterprise constraints according to the
global security policy and application rules received from
the developer. The security administrator should also ver-
ify if these new constraints remain in agreement with the
constraints of existing information system in order to guar-
antee the coherence of new information system.
5.3.1. Conception level
The application developer realizes the stage of design.
He defines the application model that contains all the ele-
ments expressing the user needs. From this model the
developer generates the sets of following elements: roles,
functions, permissions and constraints. These sets of ele-
ments should be presented to the security administrator
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
1
User
* *
*
* *
*
Enterprise
*
function
constraint
EXPLOITATION LEVEL
SECURITY ADMINISTRATOR
Fig. 5. Stages of application developer and security administrator.
in a useful and legible form. The tasks of application devel-
oper are as follows:
– allocation of elements: permissions to functions and
functions to roles,
– setting up the constraints associated to this application.
Starting from the UML specification realized by the devel-
oper of an information system component we have shown
in Goncalves and Hemery (2000) and Poniszewska-Maran-
da et al. (2005) how to generate automatically the roles
associated to a component of the information system using
the UML meta-model. Section 5.4 gives the rules to pro-
vide these roles.
5.3.2. Exploitation level
In the second part, i.e. during the exploitation phase of
the information system, the security administrator assigns
the previous roles to the users based on their responsibili-
ties and on global security policy defined for the enterprise.
The security administrator should manage the set of
applications assuring the global coherence of the whole sys-
tem. Using the set of applications received from the devel-
oper he gives the system users different rights to use the
particular applications. However, before assigning the
users to the enterprise functions and the roles to the enter-
prise functions, the security administrator should define
constraints on these assignments with respect to defined
security policies.
The application that the security administrator receives
from the developer contains: a set of roles, a set of func-
tions, a set of permissions and a set of application con-
straints. These sets must be completed with two groups
of elements important from the administrator’s point of
view; namely:
– persons working for the enterprise (users) and
– functions realized in the enterprise (enterprise functions).
An enterprise function is a task or a set of tasks that can be
realized in a system by the same person. If the tasks of an
enterprise function require the cooperation between two or
1313
Session
* * * *
Role * Function * Permission
* *
constraint
CONCEPTION LEVEL
DEVELOPER
more persons this function is realized by these persons tak-
ing into consideration the constraints defined on such func-
tion that specify the additional conditions for its execution.
The security administrator should assign the roles to
users based on the relations between the enterprise func-
tions and the roles (Fig. 5). It is also possible to define
the hierarchy of the enterprise functions. This way one
enterprise function can inherit the rights of another enter-
prise function.
The security administrator should have the list of the
enterprise functions and the list of employees. He assigns
to them the rights to use different applications of the enter-
prise information system or parts of theses applications.
This process is based on the user responsibilities in an
organization.
Therefore, the tasks of security administrator are the
following:
– allocation of elements: of roles to the enterprise func-
tions and of users to the enterprise functions,
– setting up the constraints on three types of relations: user–
enterprise Function, enterpriseFunction–enterpriseFunction
and enterpriseFunction–role.
The relation between a user and an enterprise function sig-
nifies the assignment process of the user to these functions.
There is also the relation between enterprise function and
UML’s role, which expresses the assignment of the roles
to these functions. We can also define the hierarchy of
enterprise functions, therefore one enterprise function can
inherit other enterprise function.
5.4. Role engineering – automatic production of roles based
on extended RBAC model
Access control mechanisms demand that for each user a
set of operations that he will be allowed to execute should
be clearly defined. Consequently, for each user a set of per-
missions should be defined. It needs to specify the permis-
sions for execution of certain methods on each object
accessible for that user. This process is realized with the
use of sequence diagrams, where permissions are assigned
1314 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
to the rights of execution of the methods realized in each
use case.
Based on the connection between the UML and the
extended RBAC model given above, a definition of
the security system access control (of the RBAC type) at
the developer level is proposed, using the UML as a tool
(Poniszewska-Maranda et al., 2005). The UML meta-
model is examined to define the roles of the corresponding
RBAC model, the functions that are used by these roles to
co-operate with the information system and the permis-
sions needed to realize these functions. Owing to the use
case diagrams a list of actors co-operating with the infor-
mation system is obtained. An analysis of these diagrams
allows automatic specification of relations of the following
types: R–R (role–role) relation (with the use of generaliza-
tion relation between the actors), R–F (role–function) rela-
tion (with the use of the association relation between the
actors and the use cases) and F–F (function–function) rela-
tion (generalization relation between the use cases).
The description of a use case using the interaction dia-
grams (e.g. sequence diagrams) presents activities needed
to realize a particular function of a system. Each activity
corresponds to the execution of a method on an object. It
is possible to add the permission execute to each method
attached to a message sending in a sequence diagram and
next make a union with the set of permissions. Therefore
the F–P (function–permission) relations can also automat-
ically be produced and managed.
5.4.1. Creation of roles
A user of an information system is assigned to a user
profile which is defined by the set of roles played by him.
A user profile is defined by a pair (u, listRoles(u)): u is a
user, listRoles(u) is a set of roles assigned to this user.
The production process of a set of roles in an informa-
tion system with the use of UML diagrams contains two
stages (Poniszewska-Maranda et al., 2005):
– assignment of a set of privileges (i.e. permissions) to a
use case in order to define a function
– assignment of a set of use cases (i.e. functions) to an
actor in order to define a role.
5.4.2. Definition of permissions assigned to a function
A use case, which is a description of activities and needs
of an actor, allows specification of the actor’s interactions
and co-operations. Interactions between the objects are
represented by a sequence of actions that allow the defini-
tion of a set of privileges. Therefore, in order to identify the
permissions assigned to a function it is necessary to start
from the corresponding sequence diagram.
Thus, for each use case one should define a set of per-
missions needed to activate the represented function. The
interaction is defined as a set of messages and each message
is realized by an action that can change the state of the sys-
tem. For each message of the sequence diagram one has to
assign a permission that gives the right to its execution.
Each message msgðo1 ; o2 ; mÞ in the interaction sent by
object o1 to object o2 to execute method m on object o2
should be assigned to a suitable permission. This permis-
sion corresponds to the execution of method m on object
o2 . On the addition of constraints (Section 6), the definition
of the message is as follows: msgðo1 ; o2 ; m; cstÞ, where cst
represents a set of constraints. Consequently, the set of per-
missions for interaction i is defined as follows:
P ðiÞ ¼ fpjuðmsgðo1 ; o2 ; m; cstÞÞ ¼ pðm; o2 Þ ^ cstðpÞ ¼ trueg
where u is a function that assigns a permission to message
msg and o1 is an actor or class instance that can execute
method m on object o2 .
An interaction diagram, in particular a sequence dia-
gram, is defined by the set of interactions. Thus, the set
of permissions assigned to diagram d and described by
the set of interactions D is
[
P ðdÞ ¼ P ðiÞ
i2D
The use case l described by set M of interaction diagrams
d i has the following set of permissions assigned to it:
[
P ðlÞ ¼ P ðd i Þ
d i 2M
The set P ðlÞ represents the set of permissions assigned to
the function specified by the use case l.
5.4.3. Definition of functions assigned to a role
The use case diagram allows visualization of the set of
functions of a system by examining the needs of each actor.
Thus, the use case diagram representing relations between
the actors and the use cases and specifying the set of func-
tions that should be assigned to the role, becomes the start-
ing point.
The use case diagram ucd i contains the use cases (i.e.
functions) joined with some actors (i.e. roles). The set of
functions assigned to role r, described by one use case dia-
gram, is defined by the functions that are in a direct or indi-
rect relation with this role (i.e. by the heritage relation
between the functions) on this diagram:
F ðrucd i Þ ¼ ff j f ¼ uc; uc 2 ucd i ^ ðrucd i ; f Þ 2 R–Fg [ ff 0
j f 0 ¼ uc; uc 2 ucd i ^ ððf ; f 0 Þ 2 F–F ^ ðrucd i ; f Þ
2 R–FÞg
The set of functions of the role is defined by the union of
use cases assigned to this role in all use case diagrams Duci
[
F ðrÞ ¼ F ðrucd i Þ
ucd i 2Duc
In order to create a set of roles assigned to a user profile,
users should be assigned to roles. The security administra-
tor is responsible for this stage.
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
Student
Teacher
<<extends>>
visualization <<include>>
edition
<<include>>
presentation
of results
user
<<include>>
validation
configuration
Dean
Fig. 6. Example of use case diagram.
5.4.4. Example of role production
An application example,”Management of grades” to
manage the results of students in the university information
system is presented in Fig. 6 using the use case diagram.
This diagram contains the actors (Teacher, Student, etc.)
representing the roles and the use cases (visualization, edi-
tion, etc.) representing the functions of the extended RBAC
model.
Therefore, it is possible to obtain from this use case dia-
gram the list of roles:
listRoles(ucd):= Dean, Teacher, Secretary, Student
and the list of functions:
listFunctions (ucd):= visualization, edition, presentation
of results, configuration, user validation
Next, each use case can be presented by means of one or
more interaction diagrams (for example the sequence dia-
gram in Fig. 7) to find the permissions of the RBAC model
associated to the functions represented by this use case.
The example of a sequence diagram presented in Fig. 7
represents the behaviour of the use case”Visualization of
Grades”. It contains the following elements: an actor – a
role (Student), seven objects (one of class WShowGradeStu-
dent, one of class WShowListStudent, one of class listStu-
dent, one of class listLectures, one of class listExams, one
of class Exam and one of class Grade) and the messages
sent from the actor or objects to another objects. It is pos-
sible to obtain from this diagram the set of permissions for
the function”Visualization of Grades” and attach them to
role”Student”:
role:= Student
function:= Visualization of Grades
listMethods(uc):= active( ), content( ), chose( ), valide-
Student( ), getLecture
1315
(Student), getExam(Lecture, Student), getGrade (Stu-
dent, Lecture, Exam), getValue( ), close( )
Secretary listObjects(uc) := :WShowGradeStudent, :WShowList-
Student, :listStudent, :listLectures, :listExams, :Exam,
:Grade
listPermissions(uc) := (active( ), :WShowGradeStu-
dent), (active( ), :WShowListStudent), (content( ), :list-
Student), (getLecture(Student), :listLecture), (getExam-
<<include>>
Lecture, Student), :listExam),
(getGrade(Student, Lecture, Exam), :Exam),...
The next part of this paper presents more particularly
the maintenance process of global coherence based on the
security constraints. Starting from the global coherent
security scheme, the insertion of a new application should
respect the global coherence of a new security scheme being
the consequence of the fusion of two previous schemes.
6. Constraints and coherence
The process of security administration in an information
system is a complex task. Many security constraints should
be expressed in order to define the security policy in a
proper way.
A security constraint is an information assigned to the
system elements that specifies the conditions to be satis-
fied so that the security rules and global coherence be
guaranteed.
The security constraints can be classified into two
groups. On one side, it is possible to distinguish the con-
straints expressed in the application context (i.e. applica-
tion constraints). They are verified at the design level by
the application developer. For example, taking the infor-
mation system of a university and, particularly, one of its
applications – management of student grades – a student
can access this application only on the level of his own
grades. On the other hand, we can distinguish the global
constraints or, in other words, organization constraints
that determine the global security policy of an information
system. They are proposed at the organization level by the
global security administrator (Chen and Sandhu, 1995;
Sandhu, 1990; Sandhu, 1996). For example, only the tea-
cher responsible for a group of students can access their
school dossiers.
The security constraints specified for an application give
the possibility to manage its complexity. The application
developer can easily define the security constraints that
should be associated with this application. On the other
hand, the security administrator who knows well the global
security policy can set up the constraints at the global level.
The main difficulty is to assure the global coherence of all
elements (applicative and organizational) during the addi-
tion of a new application with new roles and new permis-
sions to the existing information system.
The differences between the two types of actors in our
approach led to the choice of two languages to express
the security constraints:
1316 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
:WShowGradeStudent
:Student
active()
active()
chose()
valide(Student)
– OCL (Object Constraint Language) (Wermer and Klep-
pe, 1999; OMG, 2000, 2004) that is associated with the
UML to express the constraints formulated in the model
during the phase of application design. The application
developer uses this language to describe the security con-
straints specified for the application. OCL is an expres-
sion language which gives the possibility to define the
constraints in object-oriented models. OCL expression
can be used in each UML diagram to specify a condi-
tion, a specific object or a set of objects. Invariants
and preconditions in class diagrams and sequence dia-
grams have been chosen as effective tools for presenta-
tion of security constraints.
– RCL 2000 (Role-based Constraint Language) (Ahn and
Sandhu, 1999; Ahn and Sandhu, 2000; Ahn, 2000) cre-
ated for specification of constraints in RBAC model.
The user of this language can be the security administra-
tor who should define the administration constraints
based on the roles.
6.1. Constraints classification
Our classification of constraints reflects the cycle of appli-
cation life: analysis-development and exploitation-mainte-
nance. In the analysis-development phase the application
developer composes the utilization constraints that guaran-
tee the confidentiality and integrity of the data manipulated
by this application. In the exploitation-maintenance phase
the application is inserted into the existing information sys-
tem. This insertion should respect the global coherence of
the system using the global security constraints.
Therefore, the first classification level of constraints is
proposed as follows:
:WShowListStudent :ListStudent :ListLecture :ListExam :Exam :Grade
content()
getLecture(Student)
getExam(Student, Lecture)
getGrade(Student, Lecture, Exam)
getValue() {Student can visualise only his own grades}
close()
Fig. 7. Example of sequence diagram.
– constraints from the developer’s point of view – con-
straints at the application level, specified to create a
complex application,
– constraints from the administrator’s point of view –
organization constraints defined at the global security
level of an enterprise.
The second level of classification represents the con-
straints associated with an extended RBAC model:
– constraints imposed on a permission: limit the set of
objects accessible for a permission,
– separation of duty (SOD) constraints: represent the con-
cept of mutually exclusive roles and mutually exclusive
permissions (Sandhu, 1990; Sandhu, 1996; Ahn and
Sandhu, 2000; Ahn, 2000),
– prerequisite constraints: based on the concept of prere-
quisite roles or prerequisite permissions,
– cardinality constraints: numerical limitation on classes
in role-based system or numerical limitation on applica-
tion elements,
– session constraints and role hierarchy constraints in
RBAC model,
– administration constraints: constraints associated with
ARBAC model (Sandhu et al., 1997).
The last level of the classification of constraints
comprises:
– static constraints that exist before different types of data
access in a system are executed, e.g. the constraints on
the value domain taken by the data,
– dynamic constraints that appear during the activated
session and are responsible for the necessity to possess
certain types of access to the data in a system.
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326 1317

Based on these three types of constraints and on the
responsibilities of both the application developer and the
security administrator presented in the previous section, a
global classification of the security constraints has been
built as shown in Fig. 8. This classification does not take
into account the constraints connected with temporal
aspects or spatial aspects that are necessary in the workflow
process. The access control models richer than RBAC
model are developed in this direction (TRBAC model of
Bertino et al. (1997, 2001); Casati et al. (2001), ORBAC
model (Cuppens and Miege, 2003)) with the possibility to
define the security rules connected to the dynamic context,
i.e. evolutionary according to time, history or space. These
models allow setting up the security scheme in collabora-
tive environment as found in the workflow process.
Constraints from developer’s point of view The types of
constraints on conception level are as follows:
1. Constraints on a permission:
static – constraint reduces a set of objects accessible
by a method independent of the user who executes
this method, e.g. permission of ‘‘write” the docu-
ments with name *.doc can be presented using OCL:
context Permission inv :
self.method ? includes(‘write’) and
Set(Objects) ? select(objjobj.oclIsTypeOf(File) and
obj:getNameð Þ ¼ 0  :doc0 Þ
dynamic – constraint reduces a set of objects accessi-
ble during a session (in course of execution which
needs the particular access mode in a system), e.g.
permission of ‘‘write” the documents for a user who
is the owner of these documents:
context Permission inv :
SetðObjectsÞ ! selectðobj j obj:oclIsTypeOf ðFileÞ
and obj:owner ¼ userðsi ÞÞ
where userðsi Þ returns a set of users (i.e. one user) of
session si .
2. Prerequisite constraints – based on the prerequisite con-
cept: a permission p can be assigned to a function only if
this function has a permission q, e.g. permission of
‘‘read” some file asks the permission of ‘‘read” the direc-
tory in which this file is situated:
context Permission inv :
self :method !
0
includesð read file0 Þ implies self :method ! includes
0
ð read directory of this file0 Þ
3. Cardinality constraints – numeric limitation on applica-
tion elements, e.g. permission of ‘‘read” the file with
confidential information about the system users can be
given only to one specific role:
context Permission inv :
self :method ! includesð0 read 0 Þ and self :object !
0
includesð InfoConfidential0 Þ
implies self :function:role ! size ¼ 1
Constraints from administrator’s point of view. The most
important constraints on administrator level can be classi-
fied as follows:
1. Separation of duty (SOD) constraints – represent con-
cept of mutually exclusive roles and mutually exclusive
permissions. Separation of duty reduces the possibility
for fraud or significant errors which can cause damage
to an organization by partitioning of tasks and associ-
ated privileges required to complete a task or set of
related tasks.Different types of SOD constraints can be
defined in function of constraint concepts: constraints
on conflict roles (CR), constraints on conflict users
(CU) and constraints on conflict permissions (CP).
SOD constraints can be divided into two groups:static
SOD – more simple, contains the constraints defined

CONSTRAINTS

APPLICATION CONSTRAINTS Developer point od view

constraints on a permission Static, Dynamic

prerequis constraints Static, Dynamic

cardinality constraints Static, Dynamic

ENTERPRISE CONSTRAINTS Security administrator point of view

SOD constraints Static, Dynamic

prerequis constraints Static, Dynamic

cardinality constraints Static, Dynamic

session constraints Dynamic

role hierarchy constraints Static

administration constraints Static, Dynamic

Fig. 8. Classification of constraints.

1318 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
staticly, before the realization of different activities by a
user in a system, e.g. no user can be assigned to two con-
flicting roles (conflicting roles can not have common
users)dynamic SOD – constraints respecting the roles
activated by a user in a session; based on the actions that
can not be realized simultaneously, e.g. there are no
users with two conflicting roles enabled (conflicting roles
may have common users but users can not activate roles
which are conflicting with each other).
2. Prerequisite constraints – based on concept of prerequi-
site role; e.g. a user can be assigned to role r1 only if he
is already assigned to role r2, (a user can be assigned to
role Teacher only if he was already assigned to role
Employee).
3. Cardinality constraints – numeric limitation on classes
in role-based system; e.g. the number of users authorized
to be assigned to a role is limited (in our application
example there is only one person who can be assigned
to role Dean) or the number of sessions activated by a
user in the same time is limited (e.g. a user can open only
three sessions at the same time).
4. Constraints on session concept – e.g. a user can be the
member of two roles r1; r2 but he can not activate them
simultaneously in the same session.
5. Constraints on role hierarchy – e.g. a permission
assigned to role child can not be assigned to role parent.
6.2. Confrontation of two viewpoints and detection of
incoherencies
The responsibilities of the application developer are dif-
ferent from those of the security administrator. The devel-
oper is expected to meet the needs of all future users of the
information system. Moreover, he must ensure that the set
of roles, the set of functions and the set of permissions in
MANAGEMENT OF GRADES
List of Roles
Teacher
Student
Dean
Secretary
LPermissions
MANAGEMENT OF TEACHERS
List of Roles LFunctions
Director
ResponsibleTe
TeacherTe
SecretaryTe
LPermissions
...
Fig. 9. System applications and the new application.
the system are in agreement with the application con-
straints. The security administrator is responsible for the
global coherence of constraints as well as the coherence
in the assignment of users to roles. He works on the ele-
ments received from the application developer in agree-
ment with the security policy.
The confrontation of the two points of view relies on the
verification whether the developer’s job does not contain
incoherencies with regard to the work of the security
administrator. The confrontation of two points of view
makes it possible to find out incompatibilities that can be
caused by:
– addition of a new enterprise function to the system by
the security administrator,
– addition of a new application that uses elements (i.e.
data) of another application existing in the system,
– addition of a new application with new roles, functions
or/and permissions whose elements will be included in
the role hierarchy of the system,
– addition of new elements, e.g. roles or functions, and
new relations between these elements and the elements
already existing in the system,
– removal of elements from the system, e.g. an applica-
tion, enterprise functions, roles, etc. by the security
administrator.
These problems have to be resolved either at the design
and/or the security administration level. The confrontation
of the two points of view can reveal possible incoherencies
between these two levels and then enable their elimination.
For example, an application”Management of students”
that already exists in the university information system
(Fig. 9), contains information about the students (name,
surname, address, birth date, study year, chosen courses,
etc.). A new application‘‘Management of grades” that
LFunctions
...
...
MANAGEMENT OF STUDENTS
List of Roles LFunctions
Director
...
Student
TeacherSt
SecretarySt
LPermissions
...
...
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
manages the grades of students, added to the system, uses
some data of the application‘‘Management of students”,
for example: name, surname of a student. In this situation,
the security administrator should eliminate possible inco-
herencies, by determining the data (i.e. objects) of the first
application that can be used by the second application, i.e.
by defining the constraints specifying the set of objects of
the first application accessible by the second one.
The global coherence should guarantee that the concepts
shared between different applications respect the global
security scheme. Such situation generally provokes modifi-
cations in the role hierarchy and/or introduction of the new
enterprise functions.
6.3. Integration chain of constraints in coherent system
The modifications in the information system can be
caused by different situations: addition/removal of an
enterprise function, addition/removal of an application
that needs the modifications in an attached role hierarchy
or permission hierarchy. This part of the paper presents
the stages that guarantee the integrity of security system
during the application addition (Poniszewska, 2003).
The objective of our studies is principally the determina-
tion of roles to help the security administrator in creating
and developing his RBAC model. We suppose that at time
t there exists a consistent RBAC system in the sense defined
by Gavrila and Barkley (1998) and the security administra-
tor has an administration tool (addition/removal of role,
addition/removal of permission), which preserves the con-
sistence of the initial RBAC model. Therefore, our studies
are not to provide a role management tool but to support
the process of role definition for information system and
the solving of some preliminary incoherencies.
CLIENT DEVELOPER
Project Specification
CONCEPTION
Specification
in UML and OCL
Parser
Application Model +
constraints in RCL 2000
constraints
REALIZATION
verification
certified
RBAC model
Fig. 10. Validation chain of modification for global security scheme.
1319
6.3.1. Verification of coherence during the addition of a new
application
The purpose of the verification of coherence is to guar-
antee that addition of a new application to an information
system will not cause incoherencies and this verification
should be executed before its integration with the existing
security system.
It might be interesting to see how the addition of a new
application to an information system can be automated
and how the administrator can be assisted in detecting
the incoherencies or/and determining new relations
between the elements already existing in a system (Goncal-
ves et al., 2003).
Fig. 10 presents the flow diagram of verification of the two
points of view under consideration. The first part allows the
generation of the model specification. Application developer
uses the UML to define the new component containing all
elements that express the needs of the users. He also deter-
mines the application constraints using the OCL. The appli-
cation developer establishes the relations between different
elements and generates the UML Model that should be then
translated for the security administrator.
Next the parser analyses the UML model of the applica-
tion from the design viewpoint and preserves the concepts
that can be used to make the coherence verification. The
model representation is given according to the UML
meta-model. Using rules defined in Section 5.4, the parser
translates the Model from the UML (also from the OCL)
into the RBAC concepts (and also into the RCL 2000) giv-
ing the lists of elements that contain roles, functions, per-
missions (objects and methods) and constraints expressed
in the OCL.
On the other hand, the security administrator, who has a
list of users and a list of enterprise functions, receives the
ADMINISTRATOR STAFF MENAGER
Security Policies
Model of existing system +
constraints in RCL 2000
constraints
correction
these stages are repeated till
the validation returns suitable results
1320 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
existing system model and implements it by using the
RBAC concepts and the constraints defined in the RCL
2000. He performs his work (definition of constraints and
assignment of elements) on the RBAC level.
The second part is the stage of verification and correc-
tion of the elements and constraints defined by the devel-
oper and by the security administrator. It is necessary to
compare these two groups of constraints and eventually
apply the changes if they are not coherent.
It is also necessary to iterate the previous stages up to
the final validation made by the security administrator.
At this moment, the new application can be really inte-
grated in the existing global system.
6.3.2. Definition of coherence
The information system used in an enterprise should be
coherent – all the elements defined in the system, their rela-
tions and their constraints should be coherent. In the fol-
lowing part, first a definition of the system coherence is
given, then according to that definition, the integration of
a new application in existing security system can be valid
or not.
As it is marked above, the possible incoherencies can be
caused for example by the addition of a new application to
a system. Therefore, the purpose of Model validation is to
guarantee that the addition of a new application to an
information system will not produce incoherencies. It is
necessary to verify whether the set of elements (users, roles,
functions, etc.) of a new application has common elements
with the set of the system elements.
Let E be a set of system elements and contains the fol-
lowing subsets: users, sessions, roles, functions, permis-
sions, methods and objects
E ¼ fU ; S; R; F ; P ; M; Og; Ei 2 E and eij
2 Ei  an element j of set Ei
The constraint for an element eij 2 Ei in the information
system limit the set of elements accessible directly or indi-
rectly to this element on the system level. Let: Es ðeij Þi be
a set of the elements related to element eij by the constraint
associations in the system:
* *
1..*
Users Roles
1..*
1 1..*
* 1
Session
*
Fig. 11. Coherence of extended RBAC model.
ES k ðeij Þ 2 ES ðeij Þ; ES k ðeij Þ ::¼ fU S ðeij ÞjS S ðeij ÞjRS ðeij Þj
F S ðeij ÞjP S ðeij ÞjM S ðeij ÞjOS ðeij Þg
The following definition of coherence is proposed:
Definition. The extended RBAC model is coherent if and
only if each element eij 2 Ei (user, role, function, permis-
sion, method or object) satisfies the following condition:
for each element eij 2 Ei the set of elements in relation with
eij should be different than the empty set, i.e.
8eij 2 Ei ; 8kðES k ðeij Þ 2 ES ðeij Þ ^ ES k ðeij Þ 6¼ ;Þ ð1Þ
in particular taking into consideration the elements from
each set of extended RBAC model
8uj 2 U ; ðESk ðuj Þ ::¼ RS ðuj Þ ^ 8k ESk ðuj Þ 6¼ ;Þ
8rj 2 R; ðESk ðrj Þ ::¼ U S ðrj ÞjF S ðrj Þ ^ 8k ESk ðrj Þ 6¼ ;Þ
8fj 2 F ; ðESk ðfj Þ ::¼ RS ðfj ÞjP S ðfj Þ ^ 8k ESk ðfj Þ 6¼ ;Þ
8pj 2 P ; ðESk ðpj Þ ::¼ F S ðpj ÞjM S ðpj ÞjOS ðpj Þ ^ 8k ESk ðpj Þ 6¼ ;Þ
8mj 2 M; ðESk ðmj Þ ::¼ P S ðmj Þ ^ ESk ðmj Þ 6¼ ;Þ
8oj 2 O; ðESk ðoj Þ ::¼ P S ðoj Þ ^ ESk ðoj Þ 6¼ ;Þ
To be in agreement with the above definition of coherence,
the extended RBAC model from Fig. 2 is now modified by
the cardinality of association relations between the model
elements (i.e. relations U–R, R–F, F–P) to 1    n (Fig. 11).
6.3.3. Justification
The set of roles RS ðuj Þ accessible to a user uj cannot be
empty. In consequence, a user who is not attached to any
role cannot work in the system.
The set of users U S ðrj Þ and the set of functions F S ðrj Þ
accessible to a role rj in the system cannot be empty. A role
should have at least one attached function to have the pos-
sibility to interact with the system. It also should be
attached to at least one user to have the possibility to be
activated.
The set of roles RS ðfj Þ and the set of permissions P S ðfj Þ
accessible to a function fj in the system cannot be empty. A
function should be assigned to at least one role to be used
in the system. The function should have at least one
assigned permission to have the possibility to realize its
actions.
* *
1..* 1..*
Functions Permissions
1..* 1..*
1..* 1..*
1 1..*
Method Object
* *
1
Operation Class
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
The set of functions F S ðpj Þ, the set of methods M S ðpj Þ
and the set of objects OS ðpj Þ accessible to permission pj
in the system cannot be empty. Permission should be
assigned to at least one function to be used in the system.
The permission should have one assigned method and at
least one assigned object.
The set of permissions P S ðmj Þ accessible to a method mj
cannot be empty because each method should be assigned
to at least one permission to be used in the system.
The set of permissions P S ðoj Þ accessible to an object oj in
the system cannot be empty because each object should be
assigned to at least one permission to access their
information.
The concepts of role inheritance and function inheri-
tance (i.e. reflexive associations) are not taken into consid-
eration. There are roles that do not inherit other roles,
therefore the set of roles RS ðeij Þ for eij 2 R can be empty.
Analogously, there are functions in the set of functions that
do not inherit other functions, therefore the set of functions
F S ðeij Þ for eij 2 R can be empty. In consequence, the verifi-
cation of role inheritance and function inheritance is not
necessary during the verification of the model coherence.
Moreover, the session concept is not considered either,
because it represents the dynamic aspect of the model. A
session becomes opened in the system by a user who is in
contact with it. Therefore, the analysis cannot be made
for U–S or S–R relations.
The ‘‘a priori” coherence allows to guarantee that the
elements of a new application will be significant, i.e. they
will be in proper relations with other elements of the
extended RBAC model.
6.3.4. Verification of security system coherence
To provide that the system remains coherent after new
elements have been added, the definition of coherence
should continue to be satisfied. The case that is going to
be considered is the addition of a new coherent application
ESk ðecij Þ 2 ES ðecij Þ and
ESk ðecij Þ ::¼ U S ðecij ÞjRS ðecij ÞjF S ðecij ÞjP S ðecij ÞjM S ðecij ÞjOS ðecij Þ
EAk ðecij Þ 2 EA ðecij Þ and
EAk ðecij Þ ::¼ U A ðecij ÞjRA ðecij ÞjF A ðecij ÞjP A ðecij ÞjM A ðecij ÞjOA ðecij Þ
as involves addition of new elements, new relations and
new constraints, which may give rise to incoherencies. In
order to find possible incoherencies it is necessary to verify
whether the set of elements (roles, functions, etc.) of the
new application has any common elements with the set of
existing elements. These common elements, their relations
with other elements and their constraints can lead to inco-
herencies. Therefore, the conditions of coherence should be
verified for each common element.
1321
Let EA be a set of elements of the new application that
contains the subsets: users (U A ), sessions (S A ), roles (RA ),
functions (F A ), permissions (P A ), methods (M A ) and objects
(OA ) of the new application
EA ¼ fU A ; RA ; F A ; P A ; M A ; OA g and EAi 2 EA
It must be checked whether E0 ¼ E \ EA contains any ele-
ments or not, that is to say it is necessary to verify whether
the new application has any elements common with the ele-
ments already existing in the system. The verification of
coherence should be executed for each subset in the follow-
ing way:
U 0 ¼ U \ U A; R0 ¼ R \ RA ; F 0 ¼ F \ F A;
P 0 ¼ P \ P A; M0 ¼ M \ MA and O0 ¼ O \ OA
Let: E0i 2 E0 and E0i ::¼ fU 0 jS 0 jR0 jF 0 jP 0 jM 0 jO0 g; ecij 2 E0i be
an element of set E0i . Therefore, the calculation of set inter-
section E0 can yield one of the following two results:
– E0 ¼ ;, i.e. E \ EA ¼ ; – there are no common elements
in the set of system elements and in the set of elements of
the new application; consequently, there are no incoher-
ences between the new application and the existing sys-
tem (i.e. between the design and administration levels),
– E0 6¼ ;, i.e. E \ EA 6¼ ; – common elements exist, and,
consequently, they should be studied to identify and
eliminate the possible incoherences.
The constraints defined for a common element ecij 2 E0i
determine a set of elements accessible to it on both the
application level and the global system level. Let: ES ðecij Þ
be a set of elements related to a common element ecij by
constrained associations in the existing system and
EA ðecij Þ be a set of elements being in relation with a com-
mon element ecij by constrained associations in the new
application.
The coherence is verified if Eq. (1) is verified, i.e. if
ES ðecij Þ \ EA ðecij Þ 6¼ ;.
6.3.5. Verification algorithm of system coherence
If a new application is added to the existing system, it
can have common elements with this system. It must be
verified that the constraints defined on these common ele-
ments do not provoke incoherencies. To eliminate these
incoherencies, the following stages of verification algorithm
1322 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326

rj
c9
r’
where Cðecij Þ is the set of constraints of an element ecij ,
c1 c8
C S ðecij Þ is the set of constraints of an element ecij that ex-
ists in the system and C A ðecij Þ is the set of constraints of
f1 f2 f3
that element defined in the new application.
c2
c7 The process of identification of constraints for common
p1 p2 p3 p4 p5 elements is realized by the passage of graph of constraints
c4 c6 defined for these elements (an example given in Fig. 12).
c3 c5
o1 o2 m2 o3 o4 m4
In particular, the set of constraints for common role
rj 2 R0 is defined by
Example of passage of graph of constraints to identify
the set of constraints for common role r
8rj 2 R0 ; Cðrj Þ ¼ C S ðrj Þ [ C A ðrj Þ
symbols: r, f, p, m, o signify: roles, functions, permissions, methods and objects
the lines signify the constraints defined for the elements
c1, c2, c3, c4, ... the constraints of the passage
and, analogously, for the elements of the other types

Fig. 12. Example of graph of constraints defined for the elements of the 8fj 2 F 0 ; Cðfj Þ ¼ C S ðfj Þ [ C A ðfj Þ
model.
8pj 2 P 0 ; Cðpj Þ ¼ C S ðpj Þ [ C A ðpj Þ
0
8mj 2 M ; Cðmj Þ ¼ C S ðmj Þ [ C A ðmj Þ
rj
a11
r’
8oj 2 O0 ; Cðoj Þ ¼ C S ðoj Þ [ C A ðoj Þ
a1 8uj 2 U 0 ; Cðuj Þ ¼ C S ðuj Þ [ C A ðuj Þ
a8
f1 f2 f3
Verify the global coherence of the common elements (3):
a2
a5
a9 verify whether these constraints do not provoke incoher-
p1 p2 p3 p4 p5 ences, i.e. verify if the common elements with their con-
a3 a6 a10 straints satisfy the definition of coherence:
a4 a7
o1m1 o2 m2 o3 m3 o4 m4 o5 m5 o6 m6 o7 m7 8ecij 2 E0i ^ 8k; ðESk ðecij Þ 2 ES ðecij Þ ^ ESk ðecij Þ 6¼ ;Þ
Example of passage of graph of relations to identify
thr relations between the common role rj and the other elements
If the common elements are coherent, it is not necessary to
set up changes in the new application; otherwise the con-
symbols: r, f, p, m, o signify: roles, functions, permissions, methods and objects
the lignes signify the relations between the elements straints provoking incoherences should be identified for
a1, a2, a3, a4, ... the relations of the passage each common element.
Fig. 13. Example of graph of relations defined for the elements of the Identify the constraints that provoke the incoherences (4)
model. – it is necessary to find the constraints of the common ele-
ment ecij 2 E0i , which are responsible for the incoherences
on this element. It should be determined which sets of con-
are proposed (Goncalves et al., 2003; Poniszewska-Maran- straints C S ðecij Þ and/or C A ðecij Þ do not satisfy the definition
da, 2006): of coherence:

1. find all common elements of each type of concept,

2. identify the constraints for each of common elements,
3. verify the global coherence of the common elements, Table 1
Verification of system coherence after the addition of a new application
4. identify the constraints that provoke incoherencies,
5. propose and realize the necessary modifications in the VerificationCoherence (E, EA)
Begin
definitions of the constraints that have provoked the
for each ðEi 2 E and EAi 2 EA Þ do
incoherencies. E0i ¼ Ei \ EAi
if E0i 6¼ ; then
Find all common elements of each type (1) means to find for each ecij 2 E0i do
common users (U0 ), common roles (R0 ), common functions C S ðecij Þ ¼ identifyConstraintsðecij Þ
C A ðecij Þ ¼ identifyConstraintsðecij Þ
(F0 ), common permissions (P0 ), common methods (M0 ) or/
coherence ¼ verifyCoherenceðecij ; C S ðecij Þ; C A ðecij ÞÞ
and common objects (O0 ) in the new application and the if (! coherence) then
actual system. CIðecij Þ ¼ findConstraintsIncoherentðecij ; C S ðecij Þ; C A ðecij ÞÞ
Identify the constraints for each common element (2) is showðCIðecij ÞÞ
carried out as follows: for an element ecij 2 E0i the set of return coherence
endIf
constraints contains the set of constraints already defined
done
in the system and the set of constraints defined in the endIf
new application: done
return true
8ecij 2 E0i ; Cðecij Þ ¼ C S ðecij Þ [ C A ðecij Þ End
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326 1323

Table 2
Verification of the global coherence of the common elements
verifyCoherence (elementij, CS(elementij), CA(elementij))
Begin
for each Ei 2 E do
for each elij 2 Ei do
setMarkðelij ; falseÞ
done
done
ES ðelementij Þ ¼ passageGraphRelationsðelementij ; C S ðelementij Þ; C A ðelementij ÞÞ
for each ESk ðelementij Þ 2 ES ðelementij Þ done
if ðESk ðelementij Þ ¼¼ ;Þ then
return false
endIf
done
return true
End

Table 3 Diagrams describing the application

Identification of constraints that provoke the incoherences of common 1. use case diagrams
Application in UML 2. interaction diagrams
element 3. class diagrams
4. ...
findConstraintsIncoherent (elementij, CS(elementij), CA(elementij))
Begin Generator of Code
for ðeach cS 2 C S ðelementij Þ ^ each cA 2 C A ðelementij ÞÞ do
EAccessS ðelementij Þ ¼ passageGraphRelationsðelementij ; cS ; cA Þ
for each EAccessSk ðelementij Þ 2 EAccessS ðelementij Þ do XMI file
Generated by CASE tool
based on UML application
if ðEAccessSk ðelementij Þ ¼ ;Þ then
CI S ðelementij Þ ¼ CI S ðelementij Þ [ cS
CI A ðelementij Þ ¼ CI A ðelementij Þ [ cA XMI/XML Parser
endIf
done
Based on DTD file that describes
CIðelementij Þ ¼ CI S ðelementij Þ [ CI A ðelementij Þ the syntax for extended RBAC model
XML file
return CIðelementij Þ Contains the list of application elements
e.g. the list of roles
End
Fig. 15. Role engineering process using the UML-XML tool.

Access Control UMLXMLJava

System Platform

Administration Role Engineering Conception

System System System
Session Packet
Regular
User

Using of Security Application

Establishment Administrator
Applications Developer
of Session
(Services)
Specification
Structure
of Constraints
of Role
Closing
Management Hierarchy
Of Sessions
of Users Organisation of
Roles/Functions/Permissions
Specification
Assurance of Constraints
of system
coherence

Modifications/
Addiotions in the system

Fig. 14. UML-XML-Java platform.

1324 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
Administration
XMI File
Tool
Application
Developer
XML File
Security
Administrator
Fig. 16. Tool of security administrator.
8ecij 2 E0i for which the incoherences are identified, find
the sets of constraints that are responsible for these incoher-
ences, i.e. the sets C S ðecij Þ and/or C A ðecij Þ.
The process of verification of global coherence of the
common elements and the process of identification of con-
straints that provoke the incoherences are supported by the
passage of graph of relations defined between these ele-
ments (an example given in Fig. 13).
Propose and realize the necessary modifications in the def-
initions of the constraints that provoke the incoherences (5):
they must relax the constraints, preferably at the applica-
tion level to have the minimal impact on the existing
system.
The algorithm 1 shows four first stages of the verifica-
tion of system coherence for the addition of a new applica-
tion. The algorithms 2 and 3 describe the main functions of
the this algorithm.
The last stage is realized manually by the security
administrator and/or application developer. These modifi-
cations can be carried out at the security administration
level according to the constraints defined in the system
and in the considered application. If this is not possible,
the application developer should also perform the modifi-
cations at the design level of the new application.
The different stages of this algorithm are described in
Poniszewska (2003).
To implement the concepts presented above an UML-
XML-Java platform has been realized (Fig. 14) (Goncalves
and Hemery, 2001). Its purpose is to allow the cooperation
between the application developer and the security admin-
istrator to realize and integrate the access control concepts.
One of the components of this platform allows the realiza-
tion of role engineering process based on the extended
RBAC model (Fig. 15). Another one, the security adminis-
trator tool, allows the management of the information sys-
tem security at access control level by the creation of user
profiles of this system (Fig. 16).
The final result of this platform is a validation of appli-
cation developer activities and security administrator activ-
Definition
of Constraints
Structure
of Role
Hierarchies
Structure
of Constraint
Graph
Structure
of Relation
Graph
Management of
User Profiles
Modifications/
Additions in the System
Assurance
of System
Coherence
ities that assure the global coherence at access control level
in an information system.
7. Conclusion
The development and complexity of functions that an
information system is expected to perform not only
demand deep professional knowledge from an information
system designer but also make the system designing an
activity of great strategic importance for an enterprise. This
engineering activity needs appropriate methods, techniques
and tools to meet high requirements imposed on informa-
tion systems nowadays.
We proposed the cooperative approach of security
scheme construction of RBAC type together with the
development of a new component of the information
system.
The paper describes the process of role engineering in
the information system security using extended RBAC
model. The presented process is based on implementation
of the extension of classic RBAC model using the UML.
The UML, a standard language of object analysis and
design nowadays, has been chosen in view of the fact that
it enables complex presentation of the information system
and of important aspects of the information system secu-
rity in particular. On the other hand, the access control
based on roles allows simple management of information
system for security administrator. The elaborated RBAC
extension gives the possibility to manage the system and
to make the process of the role creation simpler, particu-
larly in the design phase.
Next, we integrated the constraint notion to specify, on
one side, the application constraints assigned to using the
information system component and, on the other side,
the global constraints of an organization. The paper dis-
cusses the security constraints of a security schema in an
information system of an enterprise based on the extended
RBAC model. The proposed classification of security
constraints is carried out on three levels depending on
 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
different aspects of creating the security in the information
system.
The discussed approach requires collaboration of the
system developer and the global security administrator
since both of them define security elements and constraints
for the system, though each one on a different level. The
issues of their activities have to be confronted and verified.
The confrontation of the two viewpoints consists of the
verification that the developer’s work does not cause inco-
herences in the global security of the information system
through identification of the problems that may have
appeared between these two levels.
The algorithm is proposed to maintain the minimal
coherence of RBAC scheme during the addition of a new
application. Starting from the global schema of coherent
security, any insertion of a new application should respect
the global coherence of new security schema. The informa-
tion system used in an enterprise should be coherent, which
means all the elements defined in the system, their relations
and their constraints should be coherent. After the defini-
tion of the system coherence is given the integration of a
new application in the existing security system can be per-
formed taking into consideration the coherence of the
entire system. The paper proposes the algorithm for the
verification of system coherence after addition of a new
application. This algorithm helps to introduce desired
modifications into the information system, e.g. addition
of a new application with preserving the coherence of infor-
mation system security.
Our next research is concentrated on the notion of
strong coherence expressing each addition of a new RBAC
element by means of the set of constraints. Such work was
realized by Schaad and Moffett (2002) with the formal lan-
guage Alloy that allows the analysis of conflicts in ARBAC
system. We think that with the CSP tool it will be possible,
in a similar way, to quickly detect the incoherencies during
the integration of a new component in the existing RBAC
scheme.
References
Ahad, R. et al., 1992. Supporting access control in an object-oriented
database language. In: Proceedings of the 3rd International Confer-
ence Extending Database Technology.
Ahn, G.-J., 1999. The RCL 2000 language for specifying role-based
authorization constraints. PhD thesis, George Mason University,
USA.
Ahn, G.-J., Sandhu, R.S., 1999. The RSL99 language for role-based
separation of duty constraints. ACM Transactions on RBAC.
Ahn, G.-J., Sandhu, R.S., 2000. Role-based authorization constraints
specification. ACM Transactions on Information and Systems
Security.
ANSI INCITS 359-2004, American national standard for information
technology, role based access control, http://csrc.nist.gov/rbac,
2004.
Bell, D.E., La Padula, L.J., 1975. Secure computer system: unified
exposition and multi interpretation. Technical Report MTIS
ADA023588, MITRE Corporation.
Bertino, E., Ferrari, E., Atluri, V. November 1997. A flexible model for
the specification and enforcement of authorization constraints in
1325
workflow management system. In: Proceedings of the 2nd ACM
Workshop on Role-Based Access Control.
Bertino, E., Bonatti, P.A., Ferrari, E., August 2001. TRBAC: a temporal
role-based access control model, A3.
Bhamidipati, V., Sandhu, R.S., 1997. The ARBAC97 model for role-based
administration of roles. In: Proceedings of the 2nd ACM Workshop on
Role-Based Access.
Booch, G., Rumbaugh, J., Jacobson, I., 1998. The Unified Modelling
Language User Guide. Addison Wesley.
Casati, F., Castano, S., Fugini, M., 2001. Managing workflow authori-
zation constraints through active technology. HP Labs Technical
Reports HPL-2000-156 20001206 External.
Castaro, S., Fugini, S., Martella, G., Samarati, P., 1994. Database
Security. Addison-Wesley.
Chappelet, J.-L., Snella, J.-J., 1997. Language for organization, Ossad
approach (Un langage pour l’organisation, L’approche Ossad), Presses
Polytechniques et Universitaires Romandes.
Chen, F., Sandhu, R.S., 1995. Constraints for role-based access control.
In: Proceedings of the 1st ACM Workshop on Role-Based Access
Control.
Coulourisand, G., Dollimore, J., Roberts, M., 1998. Role and task-based
access control in the PerDiS groupware platform. In: Proceedings of
the ACM Workshop on Role-Based Access Control.
Coyne, E.J., 1996. Role engineering. In: Proceedings of the 1st ACM
Workshop on Role-Based Access Control (RBAC96), USA.
Crook, R., Ince, D., Nuseibeh, B., 2002. Towards an analytical role
modelling framework for security requirements. In: Proceedings of the
8th International Workshop on Requirements Engineering: Founda-
tion for Software Quality (REFSQ02), Germany.
Cuppens, F., Miege, A., 2003. Modelling contexts in the Or-BAC model.
In: Proceedings of the 19th Annual Computer Security Applications
Conference, USA.
El Kalam, A., El Baida, R., Balbiani, P., Benferhat, S., Cuppens, F.,
Deswarte, Y., Miege, A., Saurel, C., Trouessin, G., 2003. Organization
based access control. In: Proceedings of the IEEE 4th International
Workshop on Policies for Distributed Systems and Networks (Policy
2003), Italy.
Epstein, P., Sandhu, R.S., 1999. Towards a UML based approach to role
engineering. In: Proceedings of the 4th ACM Workshop on Role-
Based Access Control, USA.
Epstein, P., Sandhu, R.S., 2001. Engineering of role/permission assign-
ments. In: Proceedings of the 17th Annual Computer Security
Applications Conference, USA.
Fernandez, E.B., Hawkins, J.C., 1997. Determining role rights from use
cases. In: Proceedings of the 2nd ACM Workshop on Role-Based
Access Control.
Ferraiolo, D., Kuhn, D.K., 1992. Role based access control. In:
Proceedings of the 15th National Computer Security Conference,
NIST/NSA.
Ferraiolo, D.F., Sandhu, R.S., Gavrila, S., Kuhn, D.R., Chandramouli,
R., 2001. Proposed NIST standard for role-based access control. ACM
Transactions on Information and Systems Security (TISSEC) 4 (3).
Gabay, J., 1998. Merise to OMT and UML, InterEditions.
Gavrila, S.I., Barkley, J.F., 1998. Formal specification for role based
access control user/role and role/role relationship management. In:
Proceedings of the ACM Workshop on Role-Based Access Control.
Georgiadis, Ch.K., Mavridis, I., Pangalos, G., Thomas, R.K., 2001.
Flexible team-based access control using contexts. In: Proceedings of
the 6th ACM Symposium on Access Control Models and Technologies
(SACMAT 2001).
Goncalves, G., Hemery, F., 2000. From use case in UML to management
of roles in information systems. In: Proceedings of the Conference
Inforsid, France.
Goncalves, G., Hemery, F., 2001. UML-XML platform for management
of roles in information system. In: Proceedings of the Conference
Inforsid.
Goncalves, G., Hemery, F., Poniszewska, A., 2003. Verification of
access control coherence in information system during modifica-
1326 G. Goncalves, A. Poniszewska-Maranda / The Journal of Systems and Software 81 (2008) 1306–1326
tions. In: Proceedings of the 12th IEEE International WETICE,
Austria.
Harrison, M.A., Ruzzo, W.L., Ullman, J.D., 1976. Protection in operating
systems. Communication of the ACM 19 (8).
He, Q., Antn, A.I., 2003. A framework for modeling privacy requirements
in role engineering. In: Proceedings of the 9th International Workshop
on Requirements Engineering: Foundation for Software Quality
(REFSQ’03), Austria.
Jajodia, S., Subrahmanian, V.S., Samarati, P., Bertino, E., 1998. An
unified framework for enforcing multiple access control policies. In:
Proceedings of the ACM SIGMOD Conference of Management of
Data.
Kettani, N., Mignet, D., Par, P., Rosenthal-Sabroux, C., 1998. From
Merise to UML, Eyrolles.
Lamere, J.M., 1991. Security of Information Systems: How to Organize
the Security and Quality of Information Systems in Enterprise. Dunod.
Le Moigne, J.L., 1994. The Theory of General System: Conception
Theory, PUF, Paris.
Melese, J., 1972. Component Analysis of systems, Editions Hommes et
Techniques.
Neumann, G., Strembeck, M., 2002. A scenario-driven role engineering
process for functional RBAC roles. In: Proceedings of the 7th ACM
Symposium on Access Control Models and Technologies
(SACMAT02).
Object Management Group, OMG Unified Modeling Language Specifi-
cation, 2000.
Object Management Group, OMG Unified Modeling Language Specifi-
cation, 2004.
Park, J., Sandhu, R.S., 2004. The UCONABC usage control model. ACM
Transactions on Information and System Security 1 (1).
Peltier, T., 2001. Information security policies. Procedures and Standards:
Guidelines for Effective Information Security Management. Auerbach
Publications.
Peltier, T.R., Peltier, J., Blackley, J.A., 2004. Information Security
Fundamentals. Auerbach Publications.
Poniszewska, A., 2003. UML specification of access control in informa-
tion systems: cooperative approach of role conception in RBAC
model. PhD thesis, Artois University, France, May.
Poniszewska-Maranda, A., 2006. Access control coherence of information
systems based on security constraints. In: Proceeding of the SafeComp
2006: 25th International Conference on Computer Safety, Security and
Reliability. LNCS, Springer-Verlag.
Poniszewska-Maranda, A., Goncalves, G., Hemery, F., 2005. Represen-
tation of extended RBAC model using UML language. In: Proceedings
of the SOFSEM 2005: Theory and Practice of Computer Science,
LNCS, Springer-Verlag.
Poniszewska-Maranda, A. 2005. Role engineering of information system
using extended RBAC model. In: Proceedings of the 14th IEEE
International WETICE, Sweden.
Rockle, H., Schimpf, G., Weidinger, R., 2000. Process-oriented approach
for role-finding to implement role-based security administration in a
large industrial organization. In: Proceedings of the 5th ACM
Workshop on Role-Based Access Control, Berlin, Germany.
Ross, D., 1977. Structured analysis (SA): a language for communicating
ideas. IEEE Trans Soft Engineering, 16–34.
Sandhu, R. S., 1990. Separation of duties in computerized information
systems. In: Proceedings of the IFIP WG 11.3 Workshop on Database
Security, Halifax.
Sandhu, R.S., 1994. Handbook of Information Security Management.
Auerbach Publications.
Sandhu, R.S., 1996. Role hierarchies and constraints for lattice-based
access control. In: Proceedings of the 4th European Symposium of
Research in Computer Security, Italy.
Sandhu, R.S., Jajodia, S., 1993. Handbook of Information Security
Management. Auerbach Publications.
Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E., 1996. Role-
based access control models. IEEE Computer 29 (2).
Sandhu, R.S., Bhamidipati, V., Munawer, Q., 1997. The ARBAC97 model
for role-based administration of roles. ACM Transactions on Infor-
mation and Systems Security.
Schaad, A., Moffett, J.D., 2002. A lightweight approach to specification
and analysis of role based access control extensions. In: Proceedings of
the ACM SACMAT.
Schimpf, G., 2000. Role-engineering critical success factors for enterprise
security administration. In: Proceedings of the 16th Annual Computer
Security Applications Conference (ACSAC00).
Thomas, R.K., 1997. Team-based access control (TMAC): a primitive for
applying role-based access controls in collaborative environments. In:
Proceedings of the 2nd ACM Workshop on Role-based Access
Control, USA.
Thomsen, D., O’Brien, D., Bogle, J., 1998. Role based access control
framework for network enterprises. In: Proceedings of the 14th Annual
Computer Security Application Conference.
Tipton, H.F., Krause, M., 2006. Information Security. Management
Handbook. Auerbach Publications.
Tudor, J.K., 2006. Information Security Architecture: An Integrated
Approach to Security in the Organization. Auerbach Publications.
Wermer, J., Kleppe, A., 1999. OCL: the constraint language of the UML.
Journal of Object-Oriented Programming.
Gilles Goncalves is a full professor at the University of Artois since 1994.
He studied Computer Science at the University of Lille1 and obtained his
Ph.D. in 1985. During fourteen years, he was lecturer and his works
concerned parallel and distributed computing.
His current research interests include information systems, security
management, simulation modelling and discrete optimisation. He manages
a research team named LGI2A whose main topics are organization and
management of logistic processes.
Aneta Poniszewska-Maranda studied computer science at the Technical
University of Lodz where she obtained her M.Sc. in 1998. She obtained
her Ph.D. in 2003 in the field of computer science from the University of
Artois in France and from the Silesian University of Gliwice in Poland.
She works at the Technical University of Lodz since 1998 and as a
assistant professor since 2004. During last years she give lectures in soft-
ware engineering, data bases and security of systems.
Her current research interests include software engineering, security of
information systems, analyze and design of information systems, artificial
intelligence and multi-agent systems.