This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing IEEE TRANSACTIONS ON JOURNAL NAME, MANUSCRIPT ID
1
Composability Verification of Multi-service Workflows in a Policy-Driven Cloud Computing Environment Basit Shafiq, Sameera Ghayyur, Ammar Masood, Zahid Pervaiz, Abdulrahman Almutairi, Farrukh Khan, and Arif Ghafoor Abstract— The emergence of cloud computing infrastructure and semantic Web technologies has created unprecedented opportunities for composing large-scale business processes and workflow-based applications that span multiple organizational domains. A key challenge related to composition of such multi-organizational business processes and workflows is posed by the security and access control policies of the underlying organizational domains. In this paper, we propose a framework for verifying secure composability of distributed workflows in an autonomous multi-domain environment. The objective of workflow composability verification is to ensure that all the users or processes executing the designated workflow tasks conform to the time-dependent security policy specifications of all collaborating domains. A key aspect of such verification is to determine the time-dependent schedulability of distributed workflows, assumed to be invoked on a recurrent basis. We use a two-step approach for verifying secure workflow composability. In the first step, a distributed workflow is decomposed into domain-specific projected workflows and is verified for conformance with the respective domain’s security and access control policy. In the second step, the cross-domain dependencies amongst the workflow tasks performed by different collaborating domains are verified. Index Terms— Security and Privacy Protection, Access controls, Verification, Workflow management
—————————— ——————————
1 INTRODUCTION The emergence of cloud computing infrastructure and semantic Web technologies has created unprecedented opportunities for composing large-scale business processes and workflow-based applications that span multiple organizational domains [8]. For example, the IBM Municipal Shared Services Cloud Ecosystem [17] enables application integration and composition of business processes across different Municipal Government departments. In this Shared Services Cloud environment, the applications of the different departments in the Municipal Government reside on the Shared Services Cloud and access to such applications for interdepartmental processes is provided through Web services. The cloud computing infrastructure addresses the technology and platform related challenges for interoperability. However, such infrastructure support is not enough for composition of multi-organizational business processes and workflows. The organizational domains providing their services can be autonomous entities and operate according to their own security and access control policies [2, 9, 19]. In addition, several contextual parameters such as time, location, etc., may be considered in the access control ————————————————
• Basit Shafiq and Sameera Ghayyur are with the Department of Computer Science, Lahore University of Management Sciences, Pakistan. Email:
[email protected] • Ammar Masood is with the Department of Avionics Engineering, Air University, Pakistan. • Farrukh Khan is with the Computer Science Department, Texas Southern University, Texas. Email:
[email protected] • Abdulrahman Almutairi is with the Collage of Computer and information Sciences, King Saud University, Saudi Arabia • Arif Ghafoor are with the School of Electrical and Computer Engineering, Purdue University, Indiana. Email:
[email protected]. xxxx-xxxx/0x/$xx.00 © 200x IEEE
requirements of organizations for their shared services. For example, in IBM Municipal Shared Services Cloud for a large Municipality such as New York City, suppose that the municipal Assessment Office provides electronic assessment service of property parcels in all five boroughs (Manhattan, Brooklyn, Queens, Bronx, and Staten Island) for property tax redemption purpose. However, access to this service for the Treasury Offices (responsible for collection of property taxes) of different Boroughs may be available at different times. For example, the Assessor Office allows accesses from Manhattan Borough in the time interval [9:00am-12:00pm] and from Queens Borough in the time interval [11:00am – 2:00pm]. Given such context-dependent policies of service providers, the compositional requirements of multi-organizational business process (e.g., which organizational services need to be invoked, in what order, and at what time?) may conflict with the access control policies of service providers [24]. Consequently, such business process may not be composed at all, or may be composed under some scheduling constraints [5]. In this paper, we focus on verifying the composability of multi-organizational business processes/workflows with respect to the context-driven and time dependent access control policies of service providers. These workflows are assumed to be executed on a recurrent basis and require long term collaboration among the organizational domains providing underlying services. For verifying composability of such workflows, their specifications need to be verified for conformance with the access control policies of all collaborating domains.
Published by the IEEE Computer Society
1545-5971 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing 2
IEEE TRANSACTIONS ON JOURNAL NAME, MANUSCRIPT ID
Figure 1. Overall process for workflow composability verification.
A distributed workflow specification provides a logical sequence of tasks that need to be performed by collaborating and possibly autonomous domains. In several distributed applications, workflows may have strict deadlines which may not always be satisfied because of the time dependent access control policies of domains. For verifying secure composability of such workflows, following two questions need to be answered: i) Do the security and authorization policies of collaborating domains support execution of the distributed workflow under the given timing constraints? ii) What are the possible time instants at which the distributed workflow can be executed recurrently? The composability verification approach proposed in this paper attempts to answer the above questions. The domains to which the workflow tasks are assigned are considered to be autonomous with time dependent non-reentrant behavior [1, 16]. The behavior of a domain is characterized as reentrant or non-reentrant based on the underlying software system enforcing a time-dependent access control policy. We use the Generalized Temporal Role Based Access Control (GTRBAC) [19] model to specify the time dependent access control policy of a domain. A nonreentrant system does not allow simultaneous, interleaved, or nested invocations and only one instance of such system exists at any time [16]. The non-reentrant behavior of a system is governed by its finite state model (FSM) and any interaction with such system has to be compatible with its current state [16]. At any time, a domain can have only one instance of its GTRBAC policy against which all access requests are evaluated. In addition, the GTRBAC policy instance has a finite number of authorization states. Therefore, according to the above criterion a domain is a nonreentrant system. For verifying workflow composability, the distributed workflow specifications need to be analyzed for being consistent with the individual as well as with the collective behavior of collaborating domains. Accordingly, workflow composability verification entails two steps: i) verification of workflow specifications with respect to the FSM of individual domains, and ii) verification of dependencies
among domains for execution of workflow tasks. These two steps can either be carried out separately in the above order, or can be performed simultaneously by using a unified global meta-policy that captures all intra-domain and inter-domain authorizations [24, 27]. The methodology proposed in this paper uses the two step verification approach and does not consider the global meta-policy based approach for the following reason. The global meta-policy is composed by integrating the access control policies of all collaborating domains, however, domains may not disclose their policies due to privacy concerns. Therefore, it may not be feasible to compose an integrated global meta policy given the privacy requirements of domains. Figure 1 depicts the overall process for workflow composability verification. The process involves a coordinator and interacting domains responsible for workflow execution. The distributed workflow specification is given in form of a workflow sequence diagram (WSD). Given this specification, the coordinator identifies the component services and selects domains providing the needed component services. Each of these domains takes the WSD specification and generates the domain specific projected workflow. The projected workflow specification is verified by the respective domain for conformance with the authorization and execution time requirements specified in the GTRBAC policy of the domain. Since this verification is performed with respect to the internal GTRBAC policy of the domain, it is called intradomain workflow composability verification. After verification of projected workflows, the cross-domain dependencies amongst the workflow tasks performed by different collaborating domains are verified. This verification is performed by the coordinator and requires the following information: i) component service ordering and dependency constraints, which are extracted from the WSD; ii) the possible initiation and completion times of all the relevant component services provided by the interacting domains. Each domain shares the possible initiation/completion time of its component services with the coordinator, without disclosing its internal operations for execution of the component services and policies. The coordinator uses this information to verify satisfaction of cross-domain dependencies of the distributed workflow. The remainder of this paper is organized in the following manner. Section 2 introduces the Interaction Model (IM) for distributed workflow specification. Section 3 provides a brief overview of GTRBAC model and its statebased representation. Section 4 discusses the proposed approach for composability verification. Section 5 presents related work and Section 6 provides conclusion.
2 INTERACTION MODEL FOR WORKFLOW SPECIFICATION Interaction model is used to provide a formal and precise specification of a distributed workflow including different tasks that are performed by different domains [28, 13, 15, 28]. We use the term component service to refer to a task or set of tasks in a distributed workflow that can be executed by a domain independently. More precisely, a component service encapsulates a set of domain-specific
1545-5971 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing AUTHOR ET AL.: TITLE
3
tasks that are advertised to other interacting domains as a single capability/functionality of the domain. We use UML 2.0 sequence diagrams to model the distributed workflow specification. The UML sequence diagrams can be directly transformed to the BPEL or BPMN model using the existing tools [12, 10]. A sequence diagram, shown in Figure 2(a), specifies the communication among the interacting entities as message exchanges. The vertical line in a sequence diagram represents time and is called the lifeline of the corresponding interacting entity. Message exchange between two entities is shown by an arrow from the sender to the receiver.
2.1 Workflow Sequence Diagram (WSD) In WSD, we consider the interacting entities of a sequence diagram as interacting domains (IDs) defined below. Definition 1 (ID). An Interacting Domain (ID) is a tuple {EV, ≤, CS, ES_Map} where, (a) EV= In ∪ Out is a set of events which are partitioned into input and output events; (b) ≤ ⊆ EV × EV is a partial ordering of events such that ⇒ ; (c) CS: {c1,…,cr} is a set of component services offered by the ID; (d) ES_Map: 2EV→ CS maps a set opf events to the corresponding CS. Definition 2 (WSD). A Workflow Sequence Diagram (WSD) is a tuple WSD= {ID, TR} such that: (a) ID= {ID1, …, IDm } is a finite set of interacting domains with IDi={EVi, ≤i,, CSi, ES_Mapi}. Without loss of generality we assume that ID1 always initiates the interaction. (b) For a given ID, TR maps a pair of events to the minimum and maximum duration allowed between them. TR(evx, evy)= [dl,du] where dl, du ∈ , evx ≤ evy and x ≠ y. The set of component services (CS) offered by an ID is included in its specification (see Definition 1). A component service is associated with an input event and output event. An input event corresponds to an input message (or request message) for invoking the service. An output event corresponds to the output message (or response message) generated by the invoked service after completion. The mapping function ES_Map in the ID definition links a component service to its input/output events or messages. The second element TR in the WSD tuple is a function that maps any pair of events (evi, evj) to a finite time interval. This interval specifies the minimum and maximum duration allowed between evi and evj. Example 1. Figure 2(a) shows the WSD of a distributed workflow involving urgent processing of tax redemption request for delinquent real-estate property. The urgent processing entails that the entire business process of tax redemption be completed in 4 hours (240 minutes). The domains involved in provisioning of this distributed workflow include: property owner, County Clerk Office (IDCCO), County Treasurer Office (IDCTO), and District Clerk Office (IDDCO) as shown in Figure 2(a). The distributed workflow of Figure 2(a) is initiated by the property owner by filing a tax estimate request for the delinquent property with IDCCO. This request invokes the initial assessment service in
Figure 2. (a) WSD of a distributed tax redemption workflow. (b) Component services of the tax redemption workflow. (c) Projected workflow of corresponding domains.
IDCCO. After completion of the initial assessment, the IDCTO and IDDCO are queried for exemption processing and tax sale charges for the given delinquent property index. Based on the exemption amount and tax sale charges returned by IDCTO and IDDCO respectively, the final estimate for the tax redemption amount is calculated and is submitted to the property owner. Upon receiving the redemption cost estimate, the property owner initiates the redemption payment service for tax redemption with IDCTO. After the redemption payment is completed, the property owner requests for issuance of delinquent tax clearance certificate which launches the clearance processing service in IDCCO. The component services and their ordering dependence of the WSD of Figure 2(a) are shown in Figure 2(b). The ES_Map function maps the input message (event) in the WSD to the corresponding component service. The time interval between events in the WSD of Figure 2(a) corresponds to the interval returned by the TR function for the given events pair as specified in the WSD definition.
2.2 Domain-specific Projected Workflow
1545-5971 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing 4
IEEE TRANSACTIONS ON JOURNAL NAME, MANUSCRIPT ID
Specification The WSD specifies a high level description of the distributed workflow and considers the component services as atomic operations provided by domains. However, a component service may encapsulate a workflow process comprising multiple tasks. For example the redemption payment service, shown in Figure 2(c) comprises two tasks, namely, refund adjustment and payment processing. The refund adjustment task precedes the payment processing task in the workflow associated with the redemption payment service. This low level description of the component service is specific to a domain and is not required for distributed workflow specification. However, as discussed later, such description is needed for composability verification, which is performed for each domain separately. Definition 3 (CS). For an ID, a component service (c ∈ CS) is a tuple = , , , where is a set of tasks included in the workflow of c, denotes partial ordering between the tasks such that ( , ∈ ) implies that τ1 precedes τ2 in the execution order. : → is a function that maps a task to a positive integer value denoting the time duration required for its completion. : × → × is a function that maps a task pair ( , ) to time interval "#$ , #% & (#$ , #% ∈ ) denoting the minimum and maximum duration between the completion and initiation of and respectively. Each task of the component service has certain authorization constraints specified in the corresponding domain’s access control policy. In order to verify workflow composability, we need to ensure that all the authorization constraints associated with each task of the component service are satisfied. As discussed in the Introduction, each domain is autonomous and may not reveal its access control policy to other domains for security and privacy concerns. To facilitate workflow composability verification with respect to the access control policy of each domain, a domain-specific projected workflow (PW) specification is generated from the WSD of the distributed workflow. The PW specification provides the following information related to the corresponding domain’s involvement in the distributed workflow: i) component services provided by the domain in the WSD, ii) temporal constraints between the component services, and iii) the task workflow associated with each component service as defined above. We model the PW of a domain as a directed acyclic graph, which is constructed from the WSD and the component service specification. Each node of PW graph represents a task and an edge (τ1, τ2) represents the precedence relationship between the tasks τ1 and τ2. The node of a PW graph is annotated with a non-negative integer specifying the maximum time duration for completion of the corresponding task. For example, the Initial Assessment task in Figure 2(c) is annotated with 5 minutes corresponding to its maximum completion time. This maximum completion time of a task is obtained from the task duration mapping function λ given in the respective CS specification. Each edge in a PW graph is annotated with an interval that specifies the minimum and maximum duration between the completion and initiation of successive tasks connected by the edge.
For example, the edge between Refund Adjustment task and Payment Processing tasks in Figure 2(c) is annotated with the interval [0, 40min] meaning that Payment Processing task can be initiated within 40 minutes after completion of the Refund adjustment task. In case the successive tasks belong to the same CS, the interval mapping function β provides this information; otherwise, the interval is computed from the WSD specification (TR function in the WSD definition). Figure 2(c) shows the PW graph of IDCTO, IDCCO and IDDCO for the tax redemption workflow described in Example 1. The procedure for generating projected workflow for a given domain from a WSD specific is given in the Appendix.
3 FSM OF A DOMAIN’S ACCESS CONTROL POLICY To analyze the consistency of the workflow specification against a domain’s dynamic and non-reentrant behavior, a state based representation of the domain’s access control policy is needed. We use the GTRBAC model to specify the time dependent access control policy of a domain [19]. Below, we first provide a brief description of GTRBAC model and then describe a finite state model for state-based representation of GTRBAC policies.
3.1 GTRBAC Model A domain’s GTRBAC policy specifies the authorizations for its component services. As mentioned in Section 2, a component service is essentially an encapsulation of one or more tasks with certain temporal and ordering constraints. At the interaction modeling level, a task is viewed as an operation on a resource by an authorized subject without considering who is authorized to access the resource and how such operation can be executed. In the GTRBAC model, a task can be represented as an activation of a particular role by an authorized user, where the role is a collection of permissions required to perform the requested operation on the underlying resource object(s) and the user corresponds to the subject executing the task. For establishing the semantics relationship between a component service and the underlying user-role activation in the GTRBAC policy, we define a function called domain user-role mapper (DURM) that maps each task of the component service to a set of user role activation pairs (u, r) such that role r has all the relevant permissions required for processing of the task and the user u is authorized for role r. Formally: DURM(τ) = {(u, r) | u is authorized for r and r contains all permission required for processing τ }. The GTRBAC authorization and constraints considered in this paper can be divided in to six types: i) user-role and role-permission assignments, ii) periodicity constraints on role enabling, iii) role activation constraints, iv) run-time events, v) triggers, and vi) separation of duty (SoD) constraints. These authorizations and constraints are summarized in Table 1. We refer readers to [19] for a detailed description of GTRBAC model.
1545-5971 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing AUTHOR ET AL.: TITLE
5
Table 1. GTRBAC Constraints
However, the proposed approach is applicable to the complete GTRBAC model proposed by Joshi et al. [18, 19, 20].
r ∈ R, u ∈ U, p ∈ P, tg ∈ TRG R is a set of roles, U is a set of users, P is a set of permissions, and TRG is a set of Triggers Constraints Expression User-role as- (assignU r to u ) – role r is assigned to user u signment Role-Perm. (assignP p to r ) – permission p is assigned assignment to role r Periodicity (PEr enable r ) – role r is periodically enabled constraint on during the intervals contained in the periodic role enabling expression PEr Duration ([drmin, drmax] active r) – the activation duration constraint on of role r in any session must be greater than or role activa- equal to drmin, and less than or equal to drmax tion Run-time re- (activate/deactivate r for u) – quest user’s/administrator’s request for role activation or deactivation. Trigger ev1, sp1,…spk → ev’ – An event ev1 must be immediately followed by ev’ provided that all status predicates sp1,…spk hold at the time of the occurrence of ev1. S Role-spe- ∀ r, r’ ∈ R-SoD(u), u-active(u, r) ⇒ ¬u-aco cific tive(u, r’) – D R-SoD(u) is a set of conflicting roles for user u, i.e., u can activate at most one role in R-SoD(u) at any given time. User-Spe- ∀ u, u’ ∈ U-SoD(r), u-active(u, r) ⇒ ¬u-accific tive(u’, r) – U-SoD(r) is a set of conflicting users for role r, i.e., r can be activated by at most one user in U-SoD(r) at any given time.
Table 2. Event and status predicates
In Table 1, the periodicity constraints on role enabling/disabling are specified using periodic expression [6, 22]: 1
PE = ∑ Oi Cali > x.Cald i =n
where Cald, Caln, Caln-1,…,Cal1 are calendars (countable set of contiguous intervals) and On = all, Oi ∈ 2 ∪ {all}, Cali-1 ⊆Cali, and x ∈ . The symbol > separates the first part of the periodic expression that distinguishes the set of starting points of the intervals, from the specification of the duration of each interval in terms of the calendar Cald. For example, {all.days + {9, 15}.Hours + {20}.Minutes ⊳ 15.Minutes} represent the set of intervals {[09:20, 09:35], [15:20, 15:35], …}. GTRBAC triggers are used to specify the dependence relationship among events. The expression for a trigger considered in this paper has the following form: ev1, sp1,…spk → ev’, where ev1 is a simple event expression and spis are GTRBAC status predicates listed in Table 2. The event ev1 in the body of the trigger is called the triggering event and ev’ is called the triggered event. We consider the triggered event ev’ to be a role deactivation event. In this paper, for simplicity in explaining the proposed approach we consider a subset of GTRBAC constraints.
GTRBAC Event enable r disable r activate r for u De-acti vate r for u
Status Predicate ur-assigned(u, r) – u is assigned to r pr-assigned(p, r) – p is assigned to r r-enabled(r) – r is enabled r-active(r) – r is active in at least one user’s session u-active(u, r) – r is active in u’s session trg-enabled(tg) – trigger tg is enabled
Example 2. Table 3 shows the GTRBAC policy of domain IDCTO for tax collection and payment processing. The roles of the IDCTO include Tax Exemption Processor (TEP), Tax Refund Processor (TRP), and Tax Payment Processor (TPP). TEP is enabled daily from 9:00am to 4:00 pm, while TRP and TPP are enabled from 10:00am to 2:00pm every day. For security reasons, IDCTO does not allow a single user to perform both exemption processing and payment processing for the same property index. This constraint is defined in Row 5 of Table 3 as a role-specific separation of duty (SoD) constraint (R-SoD) between TEP and TRP roles, prohibiting any user (in this case u1) to activate both roles TEP and TRP simultaneously. Also, the role TPP has a user-specific SoD that prohibits both users u1 and u2 to activate this role simultaneously.
3.2 State-based Representation of GTRBAC Policy We model the GTRBAC policy of a domain as a timed graph introduced by Alur et al. [3, 4]. Definition 4 [GTRBAC Timed graph]. A GTRBAC timed graph is represented by a tuple TG = , where • R is a set of roles, U is a set of users, TRG is a set of GTRBAC triggers, S is a finite set of nodes representing GTRBAC states. • SP denote the set of GTRBAC status predicates. SP={renabled(r)| r ∈ R}∪{u-active(u, r)| u∈U, r∈R, and urassigned(u, r)}∪{trg-enabled(tg)| tg ∈TRG}. • µ: S → 2SP such that for any s ∈ S, µ(s) = a ∈A, and A is closed under the rules in Table 4. µ is a labeling function assigning to each state the set of status predicates that are true in that state. Where, A = {a | a ⊆ SP, a is maximal, and the resulting state is consistent w.r.t. the given GTRBAC policy}. • C is a finite set of clocks. • E ⊆ S x S is a set of edges. The edges represent the events causing the domain to move from one state to another. • s0 ∈ S is the initial state and sreset ∈ S is the calendar clock reset state. In state s0 and sreset, all roles are disabled.
1545-5971 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing 6
•
•
IEEE TRANSACTIONS ON JOURNAL NAME, MANUSCRIPT ID
c0 is a calendar clock which is reset with the occurrence of clock reset event represented by the edge from s0 to sreset. bmax = max {br}, where br is the end point of the interval
state sj, if the enabling condition associated with the edge (si, sj) is satisfied by the current values of clock. A clock can be reset with any state transition. At any instant, the value of a clock is equal to the time elapsed since the last time the clock was reset.
during which role r is enabled. γ is a function labeling each edge with an enabling condition of the form (d1 ≤ c0 ≤ d 2 ) ∧ (d1x ≤ x ≤ d 2 x ) ,
Table 4. Constraints on all valid status predicate assignments to GTRBAC States
r∈R
•
x∈C '
•
where C′ ⊆ C and d1, d2, d1x, d2x ∈ with d1 ≤ d2 ≤ bmax and d1x ≤ d2x < bmax. For the edge ereset from s0 to sreset, γ(ereset) is bmax ≤ c0 ≤ bmax, and for the edge e0 from sreset to s0, γ(e0) is 0 ≤ c0 ≤ 0. δ : E → 2C is a function mapping an edge to a set (possibly an empty set) of clocks that are reset with the edge. The function δ maps the edge ereset from s0 to sreset to c0, i.e., δ(ereset) = c0. Table 3. GTRBAC policy of IDCTO 1 User-role assignment assignU u1 to {TEP, TPP}; assignU u2 to TPP; assignU u3 to TRP 2 Role-permission assignment assignp p1(Tax Exemption Records, {read,write,approve}) to TEP; assignp p2(Tax Refund Records, {read,write,approve}) to TRP; assignp p3(Tax Payment Records, {read,write,approve}) to TPP; assignp p4(Tax Billing Records, {read,write,approve}) to TRP and TEP; assignp p5(Tax Billing Records, {read) to TPP 3 Periodicity constraints on role enabling PETEP: all.Days +10.Hours + (PETEP, enable TEP) 0.Minutes ⊳ 420.Minutes = [09:00, 16:00] daily PETPP: all.Days + 11.Hours + (PETPP, enable TPP) 0.Minutes ⊳240.Minutes = [10:00, 14:00] daily PETRP: all.Days, +11.Hours + (PETRP, enable TRP) 0.Minutes ⊳ 240.Minutes = [10:00, 14:00] daily 4 Role activation constraints ([120min, 420min] active TEP); ([240min, 240min] active TPP); ([240min, 240min] active TRP) 5 SOD R-SoD(TEP, TRP); U-SoD(TPP) = {u1, u2}
A node in a GTRBAC timed graph models the access control state of a domain characterized by the status predicates true in that state. All states in S satisfy the GTRBAC policy constraints including separation of duty constraints, dependence constraint between role enabling and role activation, dependence constraint between role assignment and activation, and trigger enabling constraint. These constraints are listed in Table 4. Edges in the GTRBAC timed graph represent the state transition events, which are listed in Table 2. Each edge is labeled with an enabling condition defined using clock values. At any point in time, the domain can make a transition from its current state si to a next
SP={r-enabled(r)| r ∈ R}∪{u-active(u, r)| u∈U, r∈R, and ur-assigned(u, r)}∪{trg-enabled(tg)| tg is a trigger in GTRBAC policy} ∀a ∈ A such that A is a maximal subset of 2SP, the following constraints must be satisfied: Constraints Only enabled roles can be activated. Formally: 1 u-active(u, r) ∈ a ⇒ r-enabled(r) ∈ a Two roles r, r’ with disjoint enabling intervals cannot 2 be enabled simultaneously in any GTRBAC state. Formally: r-enabled(r) ∈ a ⇒ r-enabled(r’) ∉ a If the enabling interval of a role r is contained in the enabling interval of another role r’, then in any GTR3 BAC state in which r is enabled, r’ is also enabled. Formally: r-enabled(r) ∈ a ⇒ r-enabled(r’) ∈ a In any GTRBAC state, a user u can activate at most 4 one role in R-SoD(u). Formally: ∀ r, r’ ∈ R-SoD(u), u_active(u, r) ∈ a ⇒ u_active(u, r’) ∉ a In any GTRBAC state, at most one user in the set U5 SoD(r) can activate r. Formally: ∀ u, u’ ∈ U-SoD(r), u_active(u, r) ∈ a ⇒ u_active(u’, r) ∉ a For any trigger tg: ev1, sp1,…spk → deactivate r for u A trigger tg is enabled only if the event ev1 occurs and at the time of occurrence of ev1, all status predicates defined in the triggers body hold. After enabling of trigger tg, the only event that can occur is deactivate r for u. k
6
trg-enabled(tg) ∈ a ⇒
∧
i =1
spi∈ a ∧
u-active(u, r) ∈ a ∧[ (u-active(u’, r’) ∈ a if ev1==activate r’ for u’) ∨ (u-active(u’, r’) ∉ a if ev1==deactivate r’ for u’) ∨ (r-enable(r’) ∈ a if ev1==enable r’) ∨ (r-enable(r’) ∉ a if ev1==disable r’)]
Each edge in the GTRBAC timed graph is mapped to a set (possibly an empty set) of clocks that are reset when the corresponding state transition event occurs. In states s0 and sreset all roles are disabled. The state sreset is visited when no role can be enabled during the current calendar period. By
1545-5971 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing AUTHOR ET AL.: TITLE
GTRBAC-FSM INPUT: GTRBAC Policy Instance OUTPUT: Timed graph 1. Let SP={r-enabled(r)| r ∈ R}∪{u-active(u, r)| u∈U, r∈R, and ur-assigned(u, r)}∪{trg-enabled(tg)| tg is a trigger in GTRBAC policy} 2. Let A be a maximal subset of 2SP such that each a ∈ A satisfies all the GTRBAC constraints listed in Table 4. 3. Generate a set of states S such that |S| = |A| + 1. 4. Create a one-to-one mapping µ from states in the set S-{sreset} to predicate assignments in the set A. Name the state that is mapped to an assignment in which all roles are disabled as s0. Let µ(sreset) = µ(s0). 5. For each pair of states si and sj, if there is a GTRBAC event ev that can cause state transition from si and sj, then create an edge eij from si and sj. a. If ev is an enabling event of a role r then define the mapping: γ(eij) = ar ≤ c0 ≤ ar b. If ev is a disabling event of role r then define the mapping: γ(eij) = (br ≤ c0 ≤ br) c. If ev an activation event of role r by user u then define the following mappings: γ(eij) = ar ≤ c0 ≤ (br – drmin) δ(eij) = curact, where, curact ∈ C is a clock that measure the time elapsed since activation of role r by u. d. If ev is a deactivation event of role r by user u then define the following mapping: γ(eij) = (ar + drmin ≤ c0 ≤ br ) ∧ (drmin ≤ curact ≤ drmax) e. For each GTRBAC trigger tg: ev1, sp1,…spk → deactivate r for u, such that trg-enabled(tg) ∈ µ(si), trg-enabled(tg) ∉ µ(sj), and (ev == deactivate r for u), then γ(eij) = et(si). [comment: et(si) is entry time of state si (see Definition 6) ] 6. Delete all edges eij corresponding to some event ev, if there exists a GTRBAC trigger tg: ev1, sp1,…spk → deactivate r for u, such that one of the following holds: a. trg-enabled(tg) ∈ µ(si) and trg-enabled(tg) ∈ µ(sj). b. trg-enabled(tg)∈ µ(si) and (ev ≠ deactivate r for u). c. (ev ≠ ev1) and trg-enabled(tg) ∈ µ(sj). 7. Create an edge e0 from sreset to s0 and define the mapping: γ(e0) = 0 ≤ c0 ≤ 0 8. Create an edge ereset from s0 and sreset and define the following mapping: γ(ereset) = bmax ≤ c0 ≤ bmax and δ(ereset) = c0 Figure 3. Procedure for generating GTRBAC Policy timed graph.
visiting state sreset, the calendar clock c0 of a domain is reset/initialized to the starting point of next calendar period in which the enabling and activation of roles follow the pattern of previous calendar periods. The procedure for generating the FSM of a GTRBAC policy in a timed graph representation is depicted in Figure 3. This procedure first generates the state space of the
7
Figure 4. (a) Time graph of the GTRBAC policy of IDCTO. (b) GTRBAC status predicate assignment. (c) Events associated with the edges of GTRBAC timed graph of IDCTO
given GTRBAC policy by considering all valid status predicate assignments that satisfy the GTRBAC constraints listed in Table 4. After generating the state space, the state transitions in the GTRBAC timed graph are defined by creating the edge set E. For all pairs of GTRBAC states si and sj, an edge is created from si to sj only if there exists a GTRBAC event evij such that si satisfies all the precondition of evij and sj satisfies the post conditions of evij. The GTRBAC events correspond to enabling/disabling of roles or activation/deactivation of roles. These GTRBAC events are listed in Table 2. After creation of the edges corresponding to the GTRBAC events, these edges are labeled with appropriate enabling conditions and clock reset function.
1545-5971 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2015.2481881, IEEE Transactions on Dependable and Secure Computing 8
IEEE TRANSACTIONS ON JOURNAL NAME, MANUSCRIPT ID
The timed graph of the GTRBAC policy of the IDCTO generated by this procedure is shown in Figure 4(a). The initial state of this timed graph is s0CTO and the calendar clock reset state is sresetCTO. The status predicates that are true in the GTRBAC states of Figure 4(a) are tabulated in Figure 4(b). The events corresponding to the edges of Figures 4(a) are listed in Figure 4(c). These states are generated by following steps 1- 4 of Figure 3. Each edge is labeled with an enabling condition defining the timing constraints for the corresponding GTRBAC event. The timing constraints are defined with respect to clocks, c0, c1, c2, c3 and c4, where c0 calendar clock the value of which provides the time of the day at a given instant. An edge between states may represent enabling event of a role, disabling event of a role, activation of a role for a user, deactivation event of a role for a user, or resetting of the calendar clock c0. In Figure 4, the resetting of the calendar clock c0 is captured by the edge e21 for IDCTO.
3.3 State Path and Timing Constraints In this subsection, we define state path and the state timing constraints. These timing constraints are used to determine the composability of a given distributed workflow with respect to the FSM of domains as discussed in Section 4. Definition 5 (State Path). A state path π is a sequence s1.e1.s2.e2……,en-1.sn, n > 0, such that the symbol si (1 ≤ i ≤ n) in path π denotes a GTRBAC state, and the symbol ej (1 ≤ j ≤ n-1) denotes an edge in the timed graph of GTRBAC policy. The edge ej represents the event that causes a transition in the GTRBAC system from state sj to sj+1. Definition 6 (State Entry Time). The entry time of a given GTRBAC state is the time instant at which the domain enters the given state. The entry time of a state is measured relative to the domain’s calendar clock c0, The entry time of a given GTRBAC state sj is denoted by et(sj). For computing et(sj), we need to determine the enabling and activation times of all roles that are enabled and active in state sj. Let Rjen denote the set of all roles that are enabled in state sj and let Rjact denote the set of all roles that are enabled and active in state sj. The following constraint defines an upper and lower bound on value of et(sj), here [ar, br] is the enabling interval of role r, and drmin is the minimum duration for which r can be activated by any user.
max{ a r } ≤ et ( s j ) ≤ min min{ br }, maxact {br " − d rmin " } en r ∈ R r∈R en r " ∈ R j j j Definition 7 (State Residence Time). Given a state path π: s1.e1……sj-1ej-1sj.ejsj+1.…,en-1.sn, the residence time of a GTRBAC state sj is the time the domain stays in the state sj while traversing the path π. Let tπsj denote the residence time of state sj in path π: s1.e1……ej-1sj.ejsj+1.…,en1.sn. Suppose γ(ej) = ∧ d1x ≤ x ≤ d2x x∈C ' is the enabling condition for the event represented by edge ej, where C’ ⊆ C and c0 ∈ C’. For a clock x ∈ C’, let ej-kx be an edge in π such that x ∈ δ(ej-kx), (i.e., clock x is reset at the edge ej-kx) and there is no other edge ep between ej-kx and ej in π for which x ∈ δ(ep). The following inequality provide
a bound on the residence time tπsj with respect to the residence time of the predecessor states of sj in path π. / 3 #( ∑4( .56 *+, -. #( (∀1 ∈ 2 ) We refer to this inequality as residence time constraint. It can be noted that a state may appear multiple times in a given state path implying that the domain visits the corresponding states multiple times while traversing that path. The residence time is computed separately for each visit. Example 3. Consider the state path, π: s0CTO.e21.sresetCTO.e0. s0CTO. e1.s2.e2 s3.e3.s4.e4.s5.e5.s6.e8.s5, taken from the GTRBAC timed graph of Figure 4(a). In this state path, state s5 is visited twice. Let tπs5_1 denote the residence time of state s5 during the first visit and tπs5_2 denote the residence time of state s5 during the second visit. In order to determine the state residence time constraint for state s6 in the path π, the following two enabling conditions associated with edge e8 in Figure 4(a) needs to be considered: 840≤c0≤840 and 240≤c2≤240. In the given state path π, the edge closest to e8 that resets clock c0 is e21 and the edge closest to e8 that resets clock c2 is e5. Therefore, with reference to clock c0 the residence time constraint for s6 in path π is given by: / >?@ / >?@ / / / / / 840 * :;
