Using Timed Colored Petri Nets and CPN-tool to Model and Verify TRBAC Security Policies

Role Based Access Control (RBAC) is one of the most used models in designing and implementation of security policies in large networking systems. The classical model doesn’t consider temporal aspects which are so important in such policies. Temporal RBAC (TRBAC) is proposed to deal with these aspects. Although the elegance of these models, design a security policy remains a challenge. One is obliged to prove the consistency and the correctness of the policy. Using formal verification allows proving that the designed policy is consistent. In this paper, we present a formal modelling/analysis approach for TRBAC policies. We use Timed Colored Petri Nets to model the TRBAC policy, and then CPN-tool is used to analyze the generated models. The analysis allows proving many important properties about the TRBAC security policy.


INTRODUCTION
The complexity 1 of security administration remains an important challenge in large networks management.Role based access control (RBAC) [3], is one of the predominant models for advanced access control because of its ability to reduce the complexity.In [4], a unified model for RBAC was published as the NIST RBAC model and was adopted as an ANSI/INCITS standard.This standardization motivates most information technology vendors to incorporate RBAC into their product lines.The RBAC model defines four basic components: Users, Roles, Permissions, and Sessions.A user is a human or a process within a system.A role is a collection of permissions associated with a certain job function.Permission is an access mode that can be exercised on a particular object in the system.A session relates a user to possibly many roles.The use of RBAC is finding applications in areas ranging from health care to defense, in addition to 1 This work was supported by the MULTIPOL European project (ITEA2).MULTIPOL aims to create a modular, innovative and consistent security suite.The goal is to have strong security features to manage independently administrated domains the mainstream commerce systems for which it was designed.In [13], RBAC model is used to implement a secure access policy in Electronic health information systems.This system is designed to offer better health care services for patients and to help doctors and other health care workers to treat and diagnose diseases.RBAC access policies ensure high information security and stringent access control for patient's health data.This is necessary to protect the patient's privacy and prevent a harmful or illegal use of data.In [11], RBAC is applied in an office automation system used in several colleges.The authors proved that web applications based on the RBAC model has excellent safety and stability.In [12], authors applied RBAC model to secure Web-based workflow systems.In this work, RBAC is used to control access (without hindering the process).In this last work, RBAC facilitates the access control management.Although the advantages of RBAC model, it does not explicitly model different states of a role.So, the RBAC does not capture various events that are typical of an RBAC system.To cover this limit, some variants of basic RBAC have been developed.The most important is Temporal RBAC (or TRBAC) [5] to handle temporal contexts.This one is then extended to General Temporal RBAC (or GTRBAC) [6].TRBAC model [5] allows: (i) temporal constraints on the events of activation and deactivation of roles, (ii) periodic role enabling and disabling and (iii) temporal dependencies among such actions.The GTRBAC [6] defines more specific temporal constraints such as temporal constraints on user-role and role-permission assignments/de-assignments, role activation-time constraints, etc.These temporal constraints are necessary in capturing the dynamic behavior of systems that use RBAC.Ensuring the consistence and the correctness of access control policies is a challenging problem.Along with the development of access control models, it is necessary to perform security analysis.Formal verification techniques have been used to analyze such policies.Petri nets are well suitable to describe discrete processes and to analyze the system concurrency and synchronism.Petri net has a graphical representation and a well-defined rigorous semantics.These characteristics allow Petri nets to be a good formalism to specify and analyze the access control policies.In the literature, we find some works which applied Petri nets to model RABCA policies.In [14-18], Petri nets are used to specify access control policies in workflow systems.In [19], security attributes in mandatory access control are analyzed using reachability of Petri net.In [20], the authors use coverability graph to analyze policies.In [21], a formal security model based on Colored Petri Net is proposed and used to show the analysis and construction methods to information flow security.With respect to [22], the above techniques don't give the consistency verification of policies.Some more important works have used Colored Petri Nets [11,12,13,14,22] where the coverability tree (or graph) is used to analyze some properties and the consistency of the RBAC policies.We will present a more detailed discussion about these last works in section two.This paper, will present a formal approach to model and verify TRBAC policies using Timed Colored Petri Nets (CPN) and .In this approach, we define the events that can occur in the system and their preconditions and postconditions.
These preconditions and postconditions specify the TRBAC constraints that should be satisfied.The rest of the paper is organized as follows: section two presents some details about the RBAC and TRBAC model, what constraints to be analyzed formally, and discuss some related works.Section three presents the Timed Colored Petri Nets formalism and its dynamic behaviour.Section four presents the modelling process and the specifications of TRBAC into CPN.Section five presents the verification phase using CPN-tool.Finally, section six concludes this paper.

THE USE OF PETRI NETS TO SPECIFY RBAC POLICIES
A policy is a set of rules that define the behavior of a system.The system that uses this policy is expected to satisfy this set of rules in all its states.A state, where one of these rules is not respected, is called an inconsistent state.An inconsistent state is reached if the policy itself contains an inconsistency or because it is incomplete.When RBAC model is used to define a policy, the set of rules are defined through the basic concepts used in the RBAC model: Users, Roles, Permissions and Sessions.The consistency rules in a policy are specified as a set of constraints in the RBAC model.In the basic RBAC, these constraints are classified into three classes: (i) Cardinality constraints, (ii) Separation of duties (SoD) constraints, (iii) Inheritance constraints.In the TRBAC, another class of constraints is considered: Temporal constraints on enabling and disabling roles.In a formal specification of an RBAC policy, we must specify the RBAC constraints to be satisfied in all states of the system.After the specification is done, the formal verification consists on proving that all reachable states during the execution of the system are consistent with respect to the set of predefined constraints.In [7], the authors defined the ConPN (Conflict Petri Nets) formalism based on CPN (Colored Petri Nets).This formalism is used to find all potential conflicts in an inheritance policy in RBAC: (i) role inheritance conflicts (a role inherits permission that it should not have), (ii) separation of duty (SoD) conflicts (a role accessed by two conflicting users at the same time), (iii) cardinality conflicts (number of users doing a role greater than permitted), and (iv) temporal restrictions conflicts (a user accesses a role in a non permitted time).In [8], authors use CPN without guards to conflicts detection in an interoperation of RBAC policies.More than role inheritance conflict (as in [7]), they studied (i) cardinality conflicts (on roles, on users, and on objects), (i) SoD conflicts (conflicting users on some roles, conflicting roles for some users), (iii) resources sharing conflicts (which can cause deadlock in the interoperation).In [9], the authors use CPN with guards and inhibitor arcs.In this work, the four events (assignment, de-assignment, activation, and de-activation) in an RBAC system are modelled as four transitions in the CPN.They considered the same constraints about: cardinalities, SoD, and inheritance as in [11,12].The originality in this last work can be the consideration of two temporal constraints (defined in the GTRBAC): dependency and precedence constraints between the activation, and the assignment of roles.In [10], the authors present a work similar to that presented in [9].They use the same model CPN to model the SA-RBAC (self authenticated RBAC).In this model, permissions are of two kinds (general and sensitive) and users, who are interested to access sensitive permission, are required to have a self authentication.
Although some of the previous works tried to model the temporal constraints and so the GTRBAC model, we remark that temporal aspects and temporal constraints defined in TRBAC were not well studied (periodic event that enable or disable roles, triggers that can also change the status of roles).The originality of the present work is : (i) The use of Timed Colored Petri Nets, and so CPN-tool [23] to analyze the policy, (ii) the specification of more constraints that are addressed in previous works (as temporal constraints on enabling and disabling roles).

TIMED COLOURED PETRI NETS
Informally, A Petri Nets (PN) [2] is a graph composed of two kinds of nodes places and transitions.A set of arcs link places to transitions and transitions to places.The places can be marked with tokens (modeling non typed data).These tokens are called marking of the PN.Transitions can be enabled, and if this is the case they can be fired.Firing a transition update the marking of the places in the net.Colored Petri Nets (CPN) [1] is an extension of Petri Nets.In CPN, each place has a type (a color).So the tokens can be more complex and typed data.The arcs are labeled by expressions that belong to the types of their incoming places.The transition can have some guards.A guard is a boolean expression.In a guard expression, we can use variables that are used in the input arcs or the output arcs of the transition.In this section, we present the formal definition of a CPN, and we show the dynamic behavior of this formalism.Timed CPN extends CPN with a set of stamps of time.These stamps can be associated to tokens or to transitions.A stamp s associated to a token will make this token ready to be used only after that the time of the system will be more than s.When a stamp s is associated to a transition, all the stamps associated to tokens that are generated, when this transition is fired, are incremented with the stamp s.
The following definition that we present in the following paragraphs is inspired from the definition of CPN [1].Our definition of Timed CPN updated the definition of CPN with the concept of stamps, as implemented in the CPN-tool [23].

Formal Definition
Firstly, we present some necessary concepts which will be used in the formal definition of the Timed CPN.Let N denote the set of non-negative integers.

Definition 1.
A Time set Τ is a set of non negative integers.Τ={t∈N}.Definition 2. A timed multi-set tm, over a nonempty set X, is a function tm ∈[X → N*Τ], for each x∈X, tm(x)=(O(x),S(x)), where O(x)∈[X → N], is the number of occurrences of x and S(x)∈[X → Τ] is a stamp (from a Time type that can be the set of positive integers).tm(x) is represented as a formal sum: ∑ x∈X (O(x)`x@+S(x)).By X TMS we denote the set of all timed multi-sets over X.The non-negative integers {O(x)⏐ x∈X} are the coefficients of the multi-set, and the nonnegative integers {S(x)⏐ x∈X} are the stamps of the multi-set.For example, if we take the set {1, 2}.A timed multi-set of this set can be (2`1@+2)++(1`2@+4).This timed multi-set represents the set that contain two occurrences of 1 (and each occurrence has the stamp=2) and one occurrence of 2 (with a stamp=4).{1,2} TMS is the set of all timed multi-sets of the set {1,2}, which is an infinite set.In the following definition, some keywords are used to facilitate the presentation.We use Type(E) to denote the type of the expression E. We use Var(E) to extract the set of variables used in the expression E. Definition 3. A Timed CP-net is a tuple CPN = (Σ, P, T, A, C, G, E, I, τ), where: (i) Σ is a finite set of non-empty types, also called colour sets. (x) τ is a temporal function that associated to each transition a stamp, τ:T Τ. (Τ is a time set).

Dynamic behaviour
The dynamic behaviour of the net is obtained when the transitions are fired.A transition can be fired if it is enabled.A transition requires some preconditions to be enabled.These preconditions depend on the marking of its input places, the expressions labelling its input arcs, and its associated guards.Once the transition is fired some post-conditions will be satisfied.Firing the transition will update the marking of its input and output places.The new marking depends on the expressions labelling the input and output arcs of this transition.To present the preconditions of firing a transition and how the marking is updated, we present firstly some necessary concepts.We use the notation Var(tr) to extract the set of variables used in the guards associated to the transition tr, or used in the expressions labelling input or output arcs of tr.(ii) G(tr)<b>.
Definition 5. if X is the set of tokens in p at time t, the timed-marking of the place p at the time t, denoted M t (p) is defined as the multi-set of tokens x in p with a stamp less than or equal t.M t (p)=∑ x∈X and S(x)≤t (O(x)`x@+S(x)) The initial timed-marking denoted M 0 is the timed-marking of the net at time 0. Definition 6.A transition tr is time-enabled at time t in a marking M iff there is a timed-binding <b,t> which satisfies the following property: ∀p∈P: E(p,tr)<b> ≤M t (p).We write that (tr,<b,t>) is time-enabled at time t.Definition 7. Let X be a timed multi-set, E is an expression defined over X, and t is a stamp, the expression E@+t denotes the expression E in which the stamps of all its operands are incremented with t. for example, if E=(2`1@+2)++(1`2@+4), then E@+2=(2`1@+4)++(1`2@+6). Definition 8.When a transition tr is time-enabled at time t, in a timed-marking M t , it can be fired.Firing tr is an event that can takes a duration Δt.Firing tr changes the marking M t to another marking M t+Δt , such that: ∀p∈P, M t+Δt (p)=(M t (p)-E(p,tr)<b>)+(E(tr,p)<b>@+τ(tr)).

Definition 9.
We say that M t+Δt is directly reachable from M t .This is written: M t [tr› M t+Δt .

MODELLING TRBAC POLICY USING TIMED CPN
When modelling a system with Petri nets, we are obliged to define the set of events.These events change the state of the system when they occur.In our case (an access control policy using TRBAC model), we distinguish six major events.These events are responsible of the modification of the status of roles defined in the system.The events are: Enableness of a role, Disableness of a role, Assignment of a role to a user, Activation of a role by a user, Deactivation of a role, and Deassignment of a role.Each of these six events, require some preconditions (some constraints of the TRBAC model) to be satisfied, and once these preconditions are verified, some postconditions will be satisfied (also some other constraints of the TRBAC model).These events are modelled by transitions.The postconditions are modelled by some input places, some expressions of input arcs, and some associated guards.The preconditions are modelled by some output places and some expressions of output arcs.In the following paragraphs, we will show in details the modelling process.
The following subsection 4.1 presents the modelling of the enableness/disableness events with Timed CPN and subsection 4.2 presents the modelling of the other events (Assignment and Activation of a role by a user) with CPN.

Modelling of Temporal Constraints
In the TRBAC model, the two events enable and disable can be prioritized and temporized.The priority is an integer that is associated to an event, and which is defined with respect to the other events that can occur in the system.The TRBAC version introduces temporal constraints on role enabling and disabling events.These constraints are presented through two concepts: periodic events and roles triggers.
• A periodic events is expressed as: <I, P, pr: E>, where: I is an interval, P: a periodic expression, pr a priority, and E an event (which can enable a role or disable a role).High priority after 2 days of the occurrence of the event: enable nurse_on_day_duty.At runtime, roles can be enabled and disabled through requests.In TRBAC, a runtime request expression has the form< pr: E after Δt>, where pr is a priority, E is an event, and Δt a duration of time.For example the <h: enable nurse_on_day_duty after 2 hours>, is a request to enable the role nurse_on_day_duty after two hours.This request has as priority h.In periodic events, role triggers, and runtime request expressions, the value pr (priority) and Δt can be omitted.If this is the case, pr is sited to the low level priority, and Δt to 0.
In the Timed CPN model we define the following types: • Role_Index: Elements in this type models roles.A role index is an integer (INT in the specification).In the specification a role R 1 is expressed as R(1).• Event: This type is the product of Prio*Role_Index*Time. Tokens in the type Event are stamped tokens which model incoming request events due to periodic events.
• RQEent: This type is the product of INT*Role_Index*Time. Tokens in the type are stamped tokens which model request events in the system.These requests are due to incoming periodic events or are injected directly in the system.In the Figure 1, place EPE, DPE will contain periodic (enabling or disabling) events.The expression ((i,j),per,pr,r) models a set of periodic events that will enable (case of the arc (EPE, arrival_EPE)) or disable (case of the arc (DPE, arrival_DPE)) the role r, with a priority pr.The occurrences of these events are limited in the interval of time [i,j], and they occur after each period equal to per.When the transition arrival_EPE is fired, it puts an event (into the place EE) that will enable some role r after a duration of time per (as the delay associated to the transition is @+per).When the transition arrival_DPE is fired, it puts an event (into the place DE) that will disable some role r after a duration of time per (as the delay associated to the transition is @+per).The two expressions E1, and E2, will re-put the periodic event into the places EPE, and DPE if the interval [i,j] is always valid (i<=j).The two expressions are two conditional statements (in ML Meta-language, used in the CPN-tool).As an example: E1=if(i+per<j)then 1`((i+per,j),per,pr,r); This means that: marking(EPE):= marking(EPE) +((i+per,j),per,pr,r) The transition Arrival_ERQ models incoming enabling request, the transition Arrival_DRQ models incoming disabling request, and the transition Arrival_CRQ models incoming of concurrent events (enabling and disabling).The places AEE, ADE are used to disable transitions Arrival_ERQ, and Arrival_DRQ, and to impose the firing of Arrival _CRQ when there are two tokens at the same time in the places EE and DE.In this case, the transition Arrival_CRQ decides what kind of request must be putted into the place RQ.The decision is made with respect to the priority of each event (the attributes pr1 and pr2).The expression E3 is a conditional statement: The place RQ will contain the set of requests.A request is a time stamped token.This token is a couple composed of a role r and an integer which is "1" for enabling request and "0" for the disabling request.Finally, transitions disable_r and enable_r, will enable or disable some role.Of course, to enable a role, this one must be disabled at the current time (place DR), and to disable a role, this one must be enabled at the current time (place ER).The initial marking of the two places AEE, and ADE must be a token 1 (or 1`1).The marking of the other places depends on the scenario to be studied.In such scenario, we must identify (i) periodic events representing the marking of places EPE, DPE, (ii) request events representing the marking of the place RQ, and finally (iii) the set of enabled roles and disabled roles, representing the marking of places ER, and DR.However, the modeling of triggers is not so easy.Triggers can be modeled as a set of transitions.So each trigger <E 1 , …, E n , C 1 , …, C

Modelling of Non Temporal constraints
In this section we present the modelling of non temporal constraints.These constraints are defined on the events: Assignment of a role to a user, Activation of a role by a user, Deactivation of a role, and de-assignment of a role.As in the previous section, we start by introducing the types used in the specification, and then we present and we explain the model.We define three basic types that will be used in this specification: • User: to model users.Each element in this type is a triple composed of three integer elements: the user index, the static cardinality (the maximum number of roles that can be assigned to this user), the dynamic cardinality (the maximum number of roles that this user can activate simultaneously).For example: (U(1), 2, 3) models the user 1, which static cardinality is 2 and which dynamic cardinality is 3.
• Role: to model roles.Each element in this type is a triple composed of three integer element: the role index (Role_Index used in the section 4.2), the static cardinality (the maximum number of users for which this role can be assigned), and the dynamic cardinality (the maximum number of users that can activate simultaneously this role).For example: (R(1), 4, 5) models the role indexed 1, which static cardinality is 2 and which dynamic cardinality is 3.
A permission is modeled as an index (an integer).For example: P(1) models a permission which index is 1.
Using these three basic types, we define the following complex types: • UserIndexList, RoleIndexList, PermIndexList: three lists type.For example, an element in UserIndexList is a list of indices, and each index is the index of user.These types will be used to define more complex types used in the specification.These complex types are products of the above predefined types.For example, a list of users can be [U(1), U(2), U(3)], which is a list of three users U(1), U(2), and U(3).It is the same case for list of roles and list of permissions.For example: [R(1), R(2)] is a list of two roles, and [P(1),P(2)] is a list of two permissions.• AllowedRoles=UserIndex*RoleIndexList.An element in this type is composed of a user index joined to a list of roles.This specifies the list of roles that a user is allowed to play.For example: in this type, the element (U(1),[R(1),R(2)]) specifies that the user U(1) can play the role R(1) and the role R(2).
• AssignedRoles=UserIndex*RoleIndexList.An element in this type is composed of a user index joined to a list of roles.This specifies the list of roles assigned to this use currently.For example: in this type, the element (U(1),[R(1),R(2)]) models that the roles R(1) and the role R(2) are assigned currently to the user U(1).
• UsersAssigned=RoleIndex*UserIndexList.An element in this type is composed of a role index joined to a list of users.This specifies the list of users for which this role is assigned currently.For example: in this type, the element (R(2),[U(1),U(2)]) models that the role R( 2) is assigned simultaneously to the users U(1) and U(2).
• ActivatedRoles=UserIndex*RoleIndexList.An element in this type is composed of a user index joined to a list of roles.This specifies the list of roles activated currently by this user.For example: in this type, the element (U(1),[R(1),R(2)]) models that the user U(1) has activated the role R(1) and the role R(2).
• UsersActivatedRole=RoleIndex*UserIndexL ist.An element in this type is composed of a role index joined to a list of users.This specifies the list of users activating currently this role.For example: in this type, the element (R(1),[U(1),U(2)]) models that the role R( 1) is activated simultaneously by the two users U(1) and U(2).
• RoleIHierarchy=RoleIndex*RoleIndexList.An element in this type is composed of a role index joined to a list of roles.This specifies the inheritance hierarchy relation between some senior role and the list of its junior roles.For example: in this type, the element (R(1),[R(2),R(3)]) models that the role R(1) is the senior for the two roles R(2) and R(3).
• RoleAHierarchy=RoleIndex*RoleIndexList.An element in this type is composed of a role index joined to a list of roles.This specifies the Activity hierarchy relation between some senior role and the list of its junior roles.
• UsersInStaticConflicts=UserIndex*RoleInd ex*UserIndexList.An element in this type is composed of a user index joined to RoleIndex joined to a list of users.This specifies the static conflict relation between some user and a list of users, about some role.For example: in this type, the element (U(1), R(2),[U(2),U(3)]) models that the user U( 1) is in static conflicts with the two users U(2) and U(3), about R(2).This means that we could not assign R(2) to U(1) if it is assigned currently to the user U(2) or the user U(3).
• UsersInDynamicConflicts=UserIndex*RoleI ndex*UserIndexList.An element in this type is composed of a user index joined to RoleIndex joined to a list of users.This specifies the dynamic conflict relation between some user and a list of users, about some role.For example: in this type, the element (U(1), R(2), [U(2),U(3)]) models that the user U( 1) is in dynamic conflicts with the two users U(2) and U(3).This means that U(1) could not activate R(2) which is activated currently by the user U(2) or the user U(3).
• RolesInStaticConflicts=RoleIndex*RoleInde xList.An element in this type is composed of a role index joined to a list of roles.This specifies the static conflict relation between some role and a list of roles.For example: in this type, the element (R(1),[R(2),R(3)]) models that the role R(1) is in static conflicts with the two roles R(2) and R(3).This means that R(1) could not be assigned to the same user that have R(2) or R(3) as assigned roles currently.
• RolesInDynamicConflicts=RoleIndex*RoleI ndexList.An element in this type is composed of a role index joined to a list of roles.This specifies the dynamic conflict relation between some role and a list of roles.For example: in this type, the element (R(1),[R(2),R(3)]) models that the role R( 1) is in dynamic conflicts with the two roles R(2) and R(3).This means that R(1) could not be activated by the same user that have activated R(2) or R(3) currently.
• UserPerm=UserIndex*PermIndexList.An element in this type is composed of a user index joined to a list of permission.This specifies the list of permission assigned to a user.For example: in this type, the element (U(1),[P(1),P(2)]) models that the user U(1) has the two permissions P(1) and P(2).
An element in this type is composed of a role index joined to a list of permission.This specifies the list of permission assigned with a role.For example: in this type, the element (R(1),[P(1),P(2)]) models that the user R(1) defines the two permissions P(1) and P (2).With this list of complex types, we add the three types (which can be added only to clarify the specification): StatCardUser, DynCardUser, StatCardRole, DynCardRole.These three types are defined as integer types.An element in one of these types is an integer which specifies a static or dynamic cardinality for a user or a role.It is clear that we can use directly the integer type.Based on these defined types, we will present in the following paragraphs the precondition and the post-conditions for each event in an RBAC policy.After the presentation of these preconditions and post-conditions, we show the CPN model for these events.

Constraints on the assignment of a role to a user
To assign a role R i to a user U i the following conditions must be satisfied: • There is a user U i and there is a role R i : this is modeled by the existence of a token (U i ,SCU,DCU) the place P1, and the existence of a token (R i , SCR,DCR) in the place P2.
Where, SCU, SCR, DCU, and DCR are integers that represent the static cardinality and the dynamic cardinality for the user U i and a role R i .
• The user U i is allowed to play the role R i : this is modeled by the existence of a token (U i , RLA) in the place P 3 , where RLA is a list of roles and Ri must be in the list RL.We add the guard [mem RL R i ] to the transition.This guard is true if R i is a member in RLA.
• The role R i is enabled: this is modeled by the fact that there is a token (R i ) in the place ER.
• The role R i is not yet assigned to the user U i : this is modeled by the fact that there is a token (R i , RL) in the place P 4 and R i is not in the list RL.We add the guard [mem RL Ri = false] to the transition.
• There is no static conflict between the user U i and the users for which R i is assigned currently: this is modeled by the fact that there is a token (Ri, UL) in the place P (5), where UL is the list of users for which R i is assigned, and there is a token (U i , R i , ULSC) in the place P 7 , where ULSC is a list of users that have conflicts with U i , and finally the intersection between ULSC and UL is empty.We add a guard [intersect ULSC UL=nil] to the transition.
• There is no static conflict between the role R i and the roles assigned currently to U i : this is modeled by the fact that there is a token (U i , RL) in the place P 4 , where RL is the list of roles assigned to Ui, and there is a token (R i ,RLSC) in the place P 6 , where RLSC is a list of roles that have conflict with R i , and finally the intersection between RLSC and RL is empty.We add a guard [intersect RLSC RL=nil] to the transition.
• The number of assigned roles to U i is less than the static cardinality of the user U i : this is modeled by the fact that there is a token (Ri,SCU,DCU) in P 1 , and there is a token (R i , RL) in the place P 4 , where RL is the list of roles assigned to R i , and finally the number of elements in RL is less then SC.We add the guard [length RL<SCU] to the transition.
• The number of users that have R i in their assigned roles is less then the static cardinality of the role R i : this is modeled by the fact that there is a token (R i ,SCR,DCR) in P 1 , and there is a token (R i , UL) in the place P 4 , where UL is the list of users for which R i is currently assigned, and finally the number of elements in UL is less then SCR.We add the guard [length UL<SCR] to the transition.After the assignment of R i to the user U i , we will have: • The role R i is assigned to the user U i : this is modeled by two effects (i) an expression modeling the arc that updates the marking of the place P4 (where roles assigned to each user are defined).This expression will be (U i ,ins RL R i ), this means that the role R i will be added to the list of role assigned currently to U i .
(ii) an expression modeling the arc that updates the marking of the place P 5 (where users assigned to each role are defined).This expression will be (R i ,ins UL U i ), this means that the user U i will be added to the list of users assigned currently to R i .
• The user U i will be allowed to all the junior roles (with respect to an AHierarchy relation) of R i : This is modeled by the updating of the place P 3 with the expression (U i , union RL RLAH).RL is the old list of roles allowed to U i , and RLAH is the list of R i 's juniors roles.The "union RL RLAH" is the union of the two lists.The list RLAH is obtained from an input expression (R i , RLAH) from the place P 8 .According to the above description, the CPN model of the assignment event will be as shown on the

Constraints on the activation of a role by a user
The activation process of a role R i by a user U i is processed through three steps (modelled by four transitions in the CPN).Firstly, we check that all necessary conditions to activate R i by U i are satisfied.If this is the case, the role is added to the activated roles of U i , and a first transition (activate) is fired.Secondly, we check if the role R i has some junior roles (with respect to the Inheritance Hierarchy relation); if this is the case then all these junior roles must be identified.This identification is done by the two transitions (inhiriting_roles_1 and inhiriting_roles_1).Thirdly, the set of permissions of the role R i and all its junior roles are assigned to the user U i (using the transition taking_permissions).During these three steps, the U i and the role R i must not be used by another transition (for example assign), and once these steps are finished, a fifth transition (restore) restores U i and R i to their places P 1 , and P 2 .The subnet that models the activation process shares the places P 1 , P 2 , P 4 with the subnet modelling assignment.The conditions necessary to fire activate: • There is a user U i and a role R i : this is modelled by the existence of a token (U i , SCU, DCU) in the place P 1 and a token (R i , SCR, DCR) in the place P 2 .
• The role R i is assigned to the user U i : this is modelled by the fact that there is a token (U i , RL) in the place P 4 , where RL is the assigned roles to U i , and the R i is a member in the list RL.We add the guard [mem RL R i ] to the transition activate.
• The role R i is not yet activated by U i : this is modelled by the fact that there is a token (U i , RLAct) in the place P 9 , where RLAct is the list of activated roles by U i , and the R i in not a member in the list RLAct.We add the guard [mem RLA R i =false] to the transition activate.
• The role R i is not in a dynamic conflict with one of the currently activated roles by U i : this is modeled by the fact that there is a token (R i , RLDC) in the place P 10 , where RLDC is the list of roles which are in dynamic conflicts with R i , and a token (U i , RLAct) in the place P 9 , where RLAct is the list of activated roles by U i , and finally the intersection between the two lists RLAct and RLDC is empty.We add the guard [intersect RLAct RLDC=nil] to the transition activate.
• The user U i is not in a dynamic conflict with one of the users activating the role R i : this is modelled by the fact that there is a token (U i , R i , ULDC) in the place P 11 , where ULDC is the list of users which are in dynamic conflicts with U i , and a token (R i , ULAct) in the place P 12 , where ULA is the list of users activating the role R i , and finally the intersection between the two lists ULAct and ULDC is empty.We add the guard [intersect ULAct ULDC=nil] to the transition activate.
• The number of roles activated by U i is less than the dynamic cardinality of the user U i : this is modeled by the fact to have a token (U i , RLAct) in the place P 9 , where RLAct is the list of activated roles by U i , and the number of elements in RLAct is less than DCU.We add a guard [length RLAct<DCU] to the transition activate.
• The number of users activating R i is less than the dynamic cardinality of the role R i : this is modelled by the effect to have a token (R i , ULAct) in the place P 10 , where ULAct is the list of users activating the role R i , and the number of elements in ULAct is less than DCR.We add a guard [length ULAct<DCR] to the transition activate.After the firing of the transition activate, • The role R i is added to the list of activated roles by the user U i : we model this by updating the marking of the place P 9 , with the token (U i , ins RLAct R i ).The expression ins RLAct R i adds the role R i to the list of role activated by U i : RLAct.
• The user U i is added to the list of users activating the role R i : we model this by updating the marking of the place P 12 , with the token (R i , ins ULAct U i ).• The user U i will take all permissions defined for the role R i and all its juniors roles.We model this by : (i) extract the R i 's juniors roles.This is done using the transitions inheriting_roles_1.This transition requires a token (R i , RLIH) from the place P 13 , where RLIH is the list of junior roles of R i .This list is then puts into the place P 16 .(ii) The transition inheriting_roles_2 will be fired iteratively to extract all roles from the list RLIH.Once inheriting_roles_2 is fired, it puts a role in the place P 18 .
(iii) The transition taking_permissions checks the place P 18 , and once a role R j is found in P 18 , this transition will use a token (R j , PLR), (where PLR is the list of permissions defined in R j ) from the place P 19 to update the marking of the place P 20 with the token (U i , union ULP RLP).The expression union ULP RLP is evaluated to the union of the list RLP and the list ULP (the permissions assigned previously to the user U i (iv).Once the list RLIH is empty, the transition restore will re-put the user U i and the role R i into their places P 1 , P 2 , and ER (enabled Roles).According to the above description, the CPN model of the activation event will be as shown on Figure 4.

MODELS VERIFICATION
The verification of the model is realized using the CPN-tool [23].CPN tool is a free software that can be used to model systems with colored Petri Nets (Timed and hierarchical also).It allows simulations and analysis of different kinds of proprieties.In the case of the CPN model for an RBAC policy, the initial marking of the model represents the initial state of the system.This initial state can be also considered as a scenario example of an RBAC policy.The properties that we must verify depend on the scenario and the system developed.In this section, we present a simple RBAC scenario, and we will show as an analysis process the reachability graph that will be drawn by the CPN.This reachability graph can be used to prove some proprieties and to answer some questions that we will discuss after.

A scenario example
Let's consider a system in which we have two users (i) U(1) with 2 as static cardinality and 1 as dynamic cardinality (ii) U( 2) with 1 as static cardinality and 1 as dynamic cardinality; three roles {R(1), R(2), R(3)}.The role R(1) with 2 as static cardinality and 1 as dynamic cardinality, and permissions {P(1), P(2)}.The role R(2) with 1 as static cardinality and 1 as dynamic cardinality, and permission {P(2)}.The role R(3) with 1 as static cardinality and 1 as dynamic cardinality and permission P(4).We consider that U(2) could not practice the role R(2), and that R(3) could not be assigned simultaneously to {U(1), U(2)}.We consider that the Role R(3) is a junior role to R(1).This scenario will represent the initial marking of the CPN model.

The analysis
The reachability graph is a representation of the state space of the system.If this graph can be computed, so the system has a finite space state.In this case, lot of proprieties can be deduced: reachability of some state, home state, boundedness of places, deadlock or liveness of transitions, … For example for the above scenario, the CPN tool generates a reachability graph with 755 nodes and 1388 arcs (figure 4 shows some nodes of the reachability graph).All places in all states are bounded.This propriety allows us to verify if some bad marking is reachable.By bad marking, we mean here some state where the constraints are not satisfied.In our case, the scenario specified has no problem.

Some important properties of the RBAC policy and their interpretation in the reachability tree
1) Can a user U(i) play all its allowed roles?This is formulated as the following: from each state where U(i) is allowed to play roles {R(1), …, R(n)} (which means a state where the marking of P 3 contains (U(i),[R(1),…,R(n)])), and for each R(i) in {R(1), …, R(n)}, we must find some path in the reachability tree in which there is at least one binding: <assign, U i =U(i), R i =R(i)>; 2) Can a user U(i) activate all its assigned roles?This is formulated as the following: From each state where {R(1), …, R(n)} are assigned to U(i) (which means a state where the marking of P 4 contains (U(i),[R(1),…,R(n)])), and for each R(i) in {R(1), …, R(n)}, we must find some path in the reachability tree in which there is at least one binding: <activate, U i =U(i), R i =R(i)>; 3) A user U(i) will never have a role R(i) which could not be assigned to him: This is formulated as the following: Every role R(i) assigned to a user U(i) in the place P 4 (AssignedRoles), must be an allowed role to the user U(i), in the place P 3 (AllowedRoles).4) A user will never activate a role which is not assigned to him: This is formulated as the following: Every role R(i) activated by a user U(i) in the place P 9 (ActivatedRoles), must be an assigned role to this user, in the place P 4 (AssignedRoles).

5) Cardinality constraints:
• A user will never have a number of assigned roles more than its SCU (static cardinality for a user): This is formulated as the following: in the place P 4 (AssignedRoles), each user U(i) must have in its list of roles a number of roles less than or equal its SCU, which is defined in the place P 1 (Users); • A user will never activate a number of roles more than its DCU (dynamic cardinality for a user): This is formulated as the following: In the place P 9 (ActivatedRoles), each user U(i) must have in its list of roles a number of roles less than or equal its DCU which is defined in the place P 1 (Users); • A role will never be assigned to a number of users greater than the SCR (static cardinality for a role): This is formulated as the following: In the place P 5 (AssignedUsers), each role R(i) must have in its list of users a number of users less than or equal its SCR which is defined in the place P 2 (Roles); • A role will never be activated by a number of users greater than the DCR (dynamic cardinality for a role): This is formulated as the following: In the place P 12 (UsersActivateRole), each role R(i) must have in its list of users a number of users less than or equal its DCR which is is defined in the place P 2 (Roles); 6) SoD constraints: • A role must never be assigned to two conflicting users (Static Conflict between users): This is formulated as the following: In the place P 5 (AssignedUsers), for each role R(i), let LU 1 =[U(1),…,U(n)] its list of users; for each user U(i) in this list, the list of its conflict users on the Role R(i), LU 2 =[U'(1),…,U'(m)] defined in the place P 7 (UsersInStaticConflicts), in the token (U(i),R(i),LU 2 ); then LU 2 ∩(LU 1 )=∅.
• A role must never be activated by two conflicting users (Dynamic Conflict between users): This is formulated as the following: In the place P 12 (UsersActivateRole), for each role R(i), let LU 1 =[U(1),…,U(n)] its list of users; for each user U(i) in this list, the list of its conflict users on the Role R(i), LU 2 =[U'(1),…,U'(m)] defined in the place P 11 (UsersInDynamicConflicts), in the token (U(i),R(i),LU 2 ); then LU 2 ∩(LU 1 )=∅.
• A user must never have two assigned conflicting roles (Static Conflict between roles): This is formulated as the following: In the place P 4 (AssignedRoles), for each user U(i), lets LR 1 =[R(1),…,R(n)] be its list of roles; for each role R(i) in this list, lets LR 2 =[R' (1),…,R'(m)] (defined in the place P 6 (RolesInStaticConflicts), in the token (R(i), LR 2 )) the list of its conflict roles; we must have : then LR 2 ∩(LR 1 )=∅.
• A user must never activate two conflicting roles (Dynamic Conflict between roles): This is formulated as the following: In the place P 9 (ActivatedRoles), for each user U(i), lets LR 1 =[R(1),…,R(n)] be its list of roles; for each role R(i) in this list, lets LR 2 =[R' (1),…,R'(m)] (defined in the place P 10 (RolesInDynamicConflicts), in the token (R(i), LR 2 )) be the list of its conflicting roles; then we must have LR 2 ∩(LR 1 )=∅.7) A user has only permissions defined in its activated roles and their junior roles (I-Hierarchy relations) even if these last ones are not activated by the user: This is formulated as the following: Every permission assigned to a user U(i) in the place P 20 (UserPerm), must be a permission defined in a role R(j) in the place P 19 (RolePerm), and the role R(j) must be activated by U(i) in P 9 (ActivatedRoles).
The CPN-tool offers the possibility to write queries using the ML (meta-language).These queries will use the reachability tree (or graph) to verify these properties.

CONCLUSION
The use of Petri Nets to model RBAC (Role Bases Access Control) policies is one of the ambitious axes to ensure the analysis and verification of security policies.The Petri Nets formalism is an event based formalism.So the specification with Petri Nets requires firstly defining events from the RBAC models.Most works consider the enabling, disabling, assignation, and activation of roles as basic events that must be modeled.The analysis of Petri Net model allows to the designer to prove the consistency of its policy.The analysis can be done through the reachability tree or graph.Colored Petri Nets is an extension of Petri Nets with more expressive power.The modeling of RBAC using CPN is more practical than using classical Petri Nets.The CPN has many tools that can be used to verify and to check the models.The proposed extensions of RBAC (Temporal RBAC, General Temporal RBAC) consider temporal constraints on RBAC events.The use of a temporal formalism like (Timed CPN) is more adequate to model these constraints.In this paper, we have presented an approach to model and to analyze the TRBAC policies.This approach uses Timed CPN formalism to construct models.After the construction of model, we use CPN-tool, to verify the consistency of the model.Through this paper, we have presented how to specify several TRBAC constraints, we have presented a scenario example, and we have discussed about results of its analysis, and what kinds of properties to be analyzed.The current work can be extended to handle more temporal constraints (those specified in the GTRBAC).The current specification can be considered as a template where scenario of RBAC written in XML can be injected and verified.This last possibility is important because this work is a part of a project dedicated to specify RBAC policies in XML, composition of policies, the optimization of the composition, and finally the formal verification of policies.By using XML specification language, this work can be integrated with the other parts of the project.
(ii) P is a finite set of places.(iii) T is a finite set of transitions.(iv) A is a finite set of arcs such that: A⊆ (P*T)∪(T*P).and P ∩T = P ∩ A = T ∩ A = Ø.(vi) C is a colour function (it defines the type of each place in the CPN).It is defined from P into Σ.(vii) G is a guard function.It is defined from T into expressions such that: ∀tr∈T: Type(G(tr)) = Boolean and Type(Var(G(tr))⊆ Σ. (viii) E is an arc expression function.It is defined from A into expressions such that: ∀a∈A: Type(E(a)) = C(p) TMS and Type(Var(E(a))) ⊆ Σ.Where p is the place component in a. (ix) I is an initialisation function (or an initial marking of the set of places).It is defined from P into closed expressions such that: ∀p∈P: Type(I(p))=C(p) TMS .

Definition 3 .Definition 4 .
A binding of a transition tr is a function b defined on Var(tr), such that:(i) ∀v∈Var(tr): b(v)∈Type(v).(ii)G(tr)<b>.The binding satisfies the guard function of tr.A timed-binding of a transition tr is a couple <b,t>, where b is a binding defined on Var(tr), t is a time and at the time t, we have :(i) ∀v∈Var(tr): b(v)∈Type(v).

Figure 3 .
In this Figure, types of places are near the places and their identifiers are inside the circle.The expressions labelling arcs are written near each arc.The guards associated to the transition are written in italic between brackets: [mem RL R i , mem RL Ri = false, intersect ULSC UL=nil, intersect RLSC RL=nil, length RL<SCU, length UL<SCR].

Figure 5 :
Figure 5: Some nodes from the reachability graph