Access Control Rept22

Security Constraints in Access Control of Information System
Using UML Language
1. Introduction
An expansion in corporate profiles, as a result of mergers and strategic alliances,
tends to dilute geographical boundaries in contemporary businesses. Organizations today
have assumed a global presence and are no longer restricted within their narrow confines.
Consequently, Internet with its ubiquitous presence in intra and inter-organizational
communication has emerged as a vital component in modern business paradigm.
Business houses, in recent years indicate an increasing affinity towards it to effectively:
• Acquire new customers
• Acquire new partners
• Use partner’s infrastructure
• Combine Intranet and Extranet
The increase in user list has led to a corresponding increase in the demand for resources.
These users can be Internal, External, Contractors or even Business Partners. Moreover,
the access for each of these users to the resources may vary. Organizations are
increasingly under pressure to accommodate their ever expanding user list. Introducing
an array of different and complex set of applications, operating systems and databases
however has led to further complicating matters.
Typically, each application system has its specific user administration control and is
managed by respective system administrator. Administrative effort and cost is
considerably increased. This is because owing to the change in need of business, more
new applications are added. As each application system can behave differently than
others, there is a lack of common user privilege policy.
When a new employee joins the organization, the user may be created into HR Database,
E-mail System, Payroll System, ERP System and so on. (See bellow Figure)
Dept. of Computer Science and Engg BEC, Bagalkot 1

Using UML Language
Figure 1
Different administrators maintain the users lists, giving rise to duplicate, and at times,
inconsistent user entries. If user records in one system are updated, there is no way to
communicate this to the other system.
Moreover, organizations extend the application resources to Intranet and Extranet (or
Internet) users. This has led to controlling user access to information and other resources
becoming even more important and complex. For such organizations, there is an
immediate need to develop and enforce access policies that protect sensitive and
confidential information.
This leads to the need of E-Security infrastructure within the organization. Typically, a
security solution should be able to address,
• User Authentication which verifies users claim of identity
• User Access control, which determines what applications, services and resources
are available to an authenticated user
• Policy based User Authorization, which allows organizations to enforce the policy
for each user to see the type of contents and the privileges of the user to access the
resources.
Role Based Access Control (RBAC) is method of assigning access to resources within
organization, based on the individual’s need for the data information.

Using UML Language
1.1 Role-Based Access Control (RBAC) :

The role-based access control (RBAC) defined in the 9-ties of the 20th century,
allows the administrator to assign users to roles rather then users directly to permissions.
This model requires identification of roles in a system. The role can represent
competency to do a specific task, and it can embody the authority and the responsibility.
The concept of role facilitates the access control management performed by the security
administrator since users and permissions can be assigned to role.
Figure 2
The role may represent the job functionality or organizational hierarchy. Each role
shall then be given permissions. For example, a role called “Payroll Clerk” may have all

Using UML Language
the access privilege and permissions associated to fulfill the job function “Clerk” within
“Payroll Department”.
Due to the nature of varied responsibility of performing job functions, one user
may be associated with one or more number of roles.
A typical organization may be having the roles defined by Department
• Position
• Authority
• Location or
• Special Assignments or Functions
The privileges associated with the role may be dynamic or context based in nature. For
example, “Payroll Clerk” role may have privilege for certain time period or for certain
location.

Using UML Language
1.2 Extended RBAC model :

The complexity of actual organizations (i.e. matrix organizational structure) has
provoked our proposition to extend the standard RBAC model that allows more fine
decomposition of responsibilities in an enterprise. For this reason, we introduced the
notion of a function. The person employed in an enterprise can have many
responsibilities in it. Each role defined in the RBAC model realizes a specific task in the
enterprise process. A role contains many functions that the user can take. For each role it
is possible to choose the system functions that are necessary for it. Thus a role can be
presented as a set of functions that this role can take and realize. Each function can have
one or more permissions, and consequently a function can be defined as a set or a
sequence of permissions. If an access to an object is required, then the necessary
permissions can be assigned to the function to complete the desired job. All the tasks and
required permissions are identified and they can give the possibility to perform all the
responsibilities of the role.
Figure 3. Example of the role-function permission mapping

Process of security administration in an information system is a complex task.
Many security constraints should be expressed in order to define in the proper way the
security policy. The security constraints can be classified into two groups. The first group

Using UML Language
represents the constraints classified by an application and the second group the
constraints required by global security policy. The security constraints specified for an
application give the possibility to manage its complexity. The application developer can
define the security constraints that should by associated to this application. On the other
hand, the security administrator who knows well the global security policy can set up the
constraints on the global level. The main difficulty is to assure the global coherence of all
elements (applicative and organizational) during the adding of the new application with
new elements, i.e. roles, functions, permissions into existing information system.
The object-oriented conception described in the Unified Modeling Language
(UML) is used to specify different components of an information system. Owing to its
high level diagrams, UML allows to specify clearly the information system needs and
makes easy the dialogue between different actors (user, developer, administrator) that
interact in its conception.
The objective is to present and implement the security constraints of security
schema in information system based on RBAC model. The security constraints can be
described using the standard tool, like OCL (Object Constraint Language) - the part of
the UML language. The first part presents the partition of responsibilities in creation of
information systems and the classification of security constraints defined in an
information system based on extended RBAC model. The second part describes the
representation of different types of security constraints using the OCL language and the
third deals with the implementation of described security constraints on the level of role
engineering of entire and complex information system security.

Using UML Language
2. Security constraints in access control

The definition of two principle levels in the security realization process of an
information system (IS) is proposed: the developer level and the security administrator
level. The application developers know well an application and they
can describe security rules of that application. On the other hand, only the global
administrator who knows the security policy of an organization can describe well the
global security of a system. Each level should formulate a set of security constraints.
2.1 Partition of responsibilities in creation of information system:

Two types of actors will cooperate in conception process of information system
and its associated security schema: from the one side, the information system developer
who knows the specifications of information system needed to realize and, from the other
side, the security administrator who knows the general security constraints that should be
respected on the enterprise level. Figure 4 presents the partition of responsibilities
between these two actors and their cooperation to establish the global access control (i.e.
security schema) using the extended RBAC model.
Figure 4. Stages of application developer and security administrator

Using UML Language
In evaluation process of an IS, the application developer defines the elements of
needed application: roles, functions, permissions and constraints. In the second time, i.e.
during the exploitation phase of IS, the security administrator will assign the previous
roles to the users basing on their responsibilities and on global security policy defined for
the enterprise. The security administrator should manage the set of applications assuring
the global coherence of a system. However security administrator should define the
constraints on these assignments with respect to defined security policy.
2.2 Classification of security constraints:
Security constraint is an information assigned to system elements that specifies
the conditions to satisfy in order to guarantee the security rules and the global coherence.
Our classification of constraints reflects the cycle of application life: analyze-
development and exploitation maintenance. In the analyze-development phase, the
application developer composes the utilization constraints that guarantee the
confidentiality and integrity of data manipulated by this application. In the exploitation-
maintenance phase, the application is inserted in an existing information system. This
insertion should respect the global coherence of the system using the global security
constraints. Therefore, the first level of constraint classification is proposed as follows:
• constraints from the developer’s point of view – constraints 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 constraints associated to extended RBAC
model:
• constraints on a permission - limit the set of objects accessible for a permission
• separation of duty (SOD) constraints - represent the concept of mutually
exclusive roles and mutually exclusive permissions
• prerequisite constraints - based on the concept of prerequisite roles or
prerequisite permissions: e.g. a user can be assigned to role Teacher only if he
has been assigned to role Employee

Using UML Language
• cardinality constraints - numerical limitation on classes in role-based system or
numerical limitation on application elements; e.g. the number of users authorized
to be assigned to a role is limited
• session constraints and role hierarchy constraints in RBAC model,
• administration constraints - the constraints are associated to the ARBAC model.
The last level of constraint classification differences the constraints as follows:
• static constraints that exist before different types of data access in a system is
executed, e.g. the constraints on the value domain taken by the data,
• dynamic constraints that appear during the session and are responsible for the
necessity to possess certain types of access to the data in a system.
Basing on these three types of constraint classification and on the responsibilities of
application developer and security administrator, presented in the previous section, the
constraints of a global classification of an information system security has been built as
shown in Figure 5. This classification is absented by the constraints connected with the
temporal aspects or the spatial aspects that are necessary in the work-flow process.

Using UML Language
Figure 5. Classification of Constraints

Using UML Language
3. Representation of security constraints

The UML language is a standard modeling language in the area of the software
engineering and a support for object-oriented approaches. It contains a suite of diagrams
for requirements, analysis design and implementation phases of the development of
systems. Out of UML diagrams representing different viewpoints of the modeling, three
types, i.e. use case diagram, class diagram and sequence diagram, are in the focus of
attention of our study.
In the course of the study, we implemented and realized the extended RBAC
model with the use of UML. To aim this, the conceptions of the UML language and
extended RBAC model first were joined. The presentation of the connections between the
UML and RBAC concepts is given in: RBAC role is joined with UML actor, RBAC
function joined with UML use case, RBAC methods and objects with UML methods and
objects, RBAC permissions can be found in the interaction diagrams, RBAC constraints
are joined with the constraint concept existing in UML and relations of different types
that occur between the elements of RBAC model can be found in the use case diagrams
and in the interaction diagrams.
Figure 6. UML concepts and their relationships with the RBAC model

Using UML Language
3.1 Security constraints using the OCL language:

The OCL language (Object Constraint Language) is proposed to express the
developer and administrator constraints. OCL is an expression language which gives the
possibility to define the constraints in object-oriented models. It has been chosen to
represent the constraints in RBAC model because it was created to allow constraints
definition in different UML diagrams.
OCL language can be used for the following specifications and descriptions:
specify the invariants on classes in class model, specify invariants for the stereotypes
describe the pre- and post-conditions on the operations, describe the guard conditions. It
is possible to define three types of constraints using the OCL: pre-condition a predicate
that should be verified before the execution of an operation; post-condition a predicate
that should be verified after the execution of an operation; invariant defines a condition
that should be always verified for each class instance, type or interface.
The OCL expression can be used: in class diagram for class attributes and
operation; in interaction diagram (i.e. sequence diagram or collaboration diagram) a
message can have the attached condition that specifies in which situation this message is
sent; in interaction diagram a messages can have the parameters and the values of these
parameters can be specified using the OCL expressions.
The security constraints can be specified in different UML diagrams. The choice
of a diagram and its presentation form are important for the clearness and legibility of the
model. We have chosen to present the constraints in class diagram and in sequence
diagram. The constraints in a class diagram are often presented as the invariants:
context Class inv :
Condition
where Condition is a boolean expression that should be verified for all elements
of the class Class.
The constraints in a sequence diagram can be expressed as pre- or post-
conditions:
context Class :: Method
pre : object | objectCondition or

Using UML Language
context Class :: Method : typeReturned
post : result = object | objectCondition
The following are some examples of constraints expressed in OCL:

Client
Age > = 18 With this invariant we specify that the field “Age” in all the instances
of the class “Client” must be greater than 18.
Doctor
Self.patient -+ size < 20
Suppose that we have a class model where amongst others the classes “Doctor”
and “Patient” appear and that a one-to-many relationship exists between the
two.In this case, the invariant would indicate that no doctor can be associated with
more than 20 patients.

Using UML Language
3.2 Constraints from developer’s point of view :

The application developer who creates an application using the UML realizes the
conception level. He creates UML Model that contains all the elements of that application
and generates from this Model a list of following elements: roles, functions, permissions
and constraints (application constraints). The constraints can be imposed on each Model
element, e.g.: constraints on role hierarchy, constraints on relation role-function,
constraints on relation function-permission, constraints on a permission (reduction of set
of objects). The first three groups of constraints are not necessary on conception level
because developer realizes application to answer the”project specification” containing
only the needs translated by the realization of enterprise functions. Therefore, the types of
constraints on conception level are as follows:
i. 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 documents with
name *.doc can be presented using OCL:
context Permission inv :
self.method → includes ( ‘write’ ) and
Set (Objects) → select(obj | obj.oclIsT ypeOf
(File) and obj.getName() =’ ∗.doc’ )
dynamic - constraint reduces a set of objects accessible in course of 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:
Set (Objects) → select(obj | obj.oclIsT ypeOf
(File) and obj.owner = user (si))
where user (si) returns a set of users (i.e. one user) of the session si
ii. prerequisite constraints - based on the prerequisite concept: a permission p can be
assigned to a function only if this function has a permission q, e.g. permission of

Using UML Language
“read” some file asks the permission of “read” the directory in which this file is
situated:
self.method → includes (‘readF ile’) implies
self.method → includes (‘readDirectoryOfFile’)
iii. cardinality constraints numeric limitation on application elements, e.g. a

permission of “read” the file with confidential information about system’s users
can be given only to one specific role:
self.method → includes (‘read’) and self.object
→ includes (‘InfoConfidential') implies
self.function.role → size = 1

Using UML Language
3.3 Constraints from administrator’s point of view :

The security administrator receives from the developer the application containing:
a set of actors (roles) and a set of use cases (from which it is possible to obtain:
permissions, objects and methods). He also disposes of two groups of elements: the
persons who work in enterprise and the functions realized in that enterprise (he has
following elements: users, enterprise functions, constraints) - Figure 4. The security
administrator should assure the global coherence of an information system in agreement
with the security rules. The constraints on the administrator level should validate these
rules. The most important constraints on the administrator level can be classified as
follows:
i. separation of duty (SOD) constraints - represent concept 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 associated 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 statically, before
the realization of different activities by a user in a system, e.g. no user can be
assigned to two conflicting roles (conflicting roles can not have the common
users)
context User inv :
self.role → intersection (Set (CR)) → size <= 1
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 the users can not activate roles which are conflicting
with each other)
context User inv :

Using UML Language
self.session.role → intersection (Set (CR)) → size <= 1
ii. prerequisite constraints - based on concept of prerequisite role; a user can be
assigned to role r1 only if he is already assigned to role r2, e.g. a user can be
assigned to the role Teacher only if he was already assigned to the role
Employee context User inv :
self.role → includes (‘ Teacher ‘) implies
self.role → includes (‘ Employee ‘)
iii. ardinality constraints - numeric limitation on classes in role-based system; e.g.
the number of users authorized to be assigned to a role is limited, for example
there is only one person who can be assigned to the role Dean
context User inv :
self.role → includes (‘ Dean ‘ )
implies self.role.user → size = 1
iv. 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
context Session inv :
self.user.role → includes (r1, r2) implies
(self.role → includes (r1)) → intersection
(self.role → includes (r2)) → isEmpty
v. constraints on role hierarchy - e.g. a permission assigned to role child can not
be assigned to role parent
self.role → includes (‘childRole’)
implies self.role → not includes (‘parentRole’)

Using UML Language
4. Implementation of security constraints based on the RBAC

model
The implementation of extended RBAC model presented in describes the process
of role creation (i.e. role engineering) via defining appropriate permissions. The entire
procedure is performed in two stages: first permissions assigned to a function are defined
and then definitions of functions assigned to a particular role are provided. The definition
of set of roles in an IS is realized with the use of UML diagrams (i.e. use case diagrams
and sequence diagrams) and its results can be presented in the form of XML lists (i.e.
files) containing the sets of all system elements (i.e. roles, functions, etc.). These lists are
generated for the security administrator but they can be also legible for the
system/application developer. However the approach given in is absented by the concepts
of security constraints.
Therefore, the implementation of security constraints based on the RBAC model
relies on generating of XML files containing the sets of security constraints given in the
special format legible for the security administrator and also for the system developer.
The security constraints can be presented in three ways: as the invariants, as the pre-
conditions or as the post-conditions but, as it was shown in the sections 3.2 and 3.3, the
most often they are presented in the form of invariants. As it was shown in section 3.1,
the general form of the invariant is as follows:
context Class inv :
Condition
The Class is an element that can have one of the following types:
Class ::= actor | use case | method | object
The form of the expression Condition can accept different shapes. The most popular three
shapes will be described below.
First of all, the invariant condition can be presented by:
Condition ::= objectCondition
The objectCondition is described by a boolean expression - it can contain one or
more expressions separated by a logic operator:

Using UML Language
objetCondition ::=
expression (logicOperator expression)∗
logicOperator ::=’ and’ |’ or’ | ‘ implies’
An expression contains one or more sub expressions separated by a relational
operator:
expression ::=
subExpression (relationOperator subExpression)∗
relationOperator ::= ’ >’ | ‘ ≥ ‘ |’<’ |’ ≤’ |’ = ‘ | ‘<>
An subExpression is composed of one or more elementary expressions separated
by an arithmetical operator:
subExpression ::= elemExpressionOCL
(arithmOperator elemExpressionOCL)∗
arithmOperator ::=’ +’ |’ −’ |’ ∗’ |’ /’
An elemExpressionOCL is composed of one or more elements and eventually of
operations defined in OCL:
elemExpressionOCL ::=
element ((‘.’ |’→’) element | operationOCL)∗
with: element ::= object | method | class
An operationOCL is one of the operations defined in OCL language, e.g. oclIsTypeOf(),
size().
Therefore, basing on the definitions given above, the elements of this form of the
invariant constraint, that can be obtained in the XML list, are: class, actor, use case,
method and object.
The second form of the invariant condition is decomposed in two parts:
Condition ::= Condition1 implies Condition2
The conditions Condition1 and Condition2 can have the following shape:
Condition1, Condition2 ::= instances
(Class (element1∗)) → includes (Set (element2∗))
where, element1, element2 ::= use case | method | object

Using UML Language
hese conditions verify if a set of Class instances contains the precise elements of type use
case, method or object. Therefore, the elements of this form of the invariant constraint,
that can be obtained in the XML list, are: actor, use case, method and object.
The third form of the invariant condition accepts the following shape:
Condition ::= elemCondition implies numCondition
The conditions elemCondition and numCondition represent the boolean expressions. The
presentation of these expressions is the same as for the condition objectCondition
described above for the first shape of invariant condition:
elemCondition = condition and
numCondition = condition
condition ::=
expression (logicOperator expression)∗
The differences appear for the elemExpression:
elemExpression ::= (element (‘. ‘ |’→ ‘) element | operationOCL)∗) | number
element ::= actor | use case | class | method | object
number€ {1, 2, ...,N}
The elements of this form of the invariant constraint, that can be obtained in the XML
list, are: class, actor, use case, method, object and numerical expression.
All the integrant elements of the security constraints (e.g. invariant constraints)
obtained in the form of XML lists can be represented by the elements of the extended
RBAC model using the relationships between the UML concepts and RBAC model
concepts, presented above in the section 3 and widely in.

Using UML Language
5 Conclusions
Many security constraints should be determined and expressed in order to define
in the proper way the security policy. Constraints are the important aspect of access
control and strong mechanism to assure organization policy on high level. In this paper
the security constraints were classified into two groups. The first group are constraints
defined for system application by application developer and the second group are
constraints required for global security policy and defined by security administrator.
The presented paper proposed to define and express these types of access control
constraints using the object-oriented modeling language, UML language, and in
particular its part as the OCL language. The presented examples of constraints have
shown the proper way of using the OCL language for both types of security constraints
based on RBAC model - constraints of application developer and constraints of security
administrator. It is also possible to implement the security constraints using the OCL
language to obtain the entire role engineering process in the definition of access control
in information systems.

Using UML Language
References
• G. Goncalves, F. Hemery, and A. Poniszewska. Verification of access control
coherence in information system during modifications. Proc. of the 12th IEEE
International WETICE, Austria, 2007.
• A. Poniszewska-Maranda. Role engineering of information system using
extended rbac model. Proc. of 14th IEEE International WETICE, Sweden, 2005.
• R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman. Role-based access
control models. IEEE Computer,2006.
• J. B.Warmer and A. G. Kleppe. The object constraint language.Precise modeling
with UML. Addison - Wesley,2006.

Access Control Rept22

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Access Control Rept22

Caricato da

Copyright:

Formati disponibili

Security Constraints in Access Control of Information System

Using UML Language

Dept. of Computer Science and Engg BEC, Bagalkot 1

Dept. of Computer Science and Engg BEC, Bagalkot 2

1.1 Role-Based Access Control (RBAC) :

Dept. of Computer Science and Engg BEC, Bagalkot 3

Dept. of Computer Science and Engg BEC, Bagalkot 4

1.2 Extended RBAC model :

Figure 3. Example of the role-function permission mapping

Dept. of Computer Science and Engg BEC, Bagalkot 5

Dept. of Computer Science and Engg BEC, Bagalkot 6

2. Security constraints in access control

2.1 Partition of responsibilities in creation of information system:

Figure 4. Stages of application developer and security administrator

Dept. of Computer Science and Engg BEC, Bagalkot 7

Dept. of Computer Science and Engg BEC, Bagalkot 8

Dept. of Computer Science and Engg BEC, Bagalkot 9

Figure 5. Classification of Constraints

Dept. of Computer Science and Engg BEC, Bagalkot 10

3. Representation of security constraints

Dept. of Computer Science and Engg BEC, Bagalkot 11

3.1 Security constraints using the OCL language:

Dept. of Computer Science and Engg BEC, Bagalkot 12

The following are some examples of constraints expressed in OCL:

Dept. of Computer Science and Engg BEC, Bagalkot 13

3.2 Constraints from developer’s point of view :

Dept. of Computer Science and Engg BEC, Bagalkot 14

iii. cardinality constraints numeric limitation on application elements, e.g. a

Dept. of Computer Science and Engg BEC, Bagalkot 15

3.3 Constraints from administrator’s point of view :

Dept. of Computer Science and Engg BEC, Bagalkot 16

Dept. of Computer Science and Engg BEC, Bagalkot 17

4. Implementation of security constraints based on the RBAC

Dept. of Computer Science and Engg BEC, Bagalkot 18

Dept. of Computer Science and Engg BEC, Bagalkot 19

Dept. of Computer Science and Engg BEC, Bagalkot 20

Dept. of Computer Science and Engg BEC, Bagalkot 21

Dept. of Computer Science and Engg BEC, Bagalkot 22

Potrebbero piacerti anche