Satisfiability Analysis of Workflows with Control-Flow Patterns and Authorization Constraints

Abstract

Abstract-Workflow security has become increasingly important and challenging in today's open service world. While much research has been conducted on various security issues of workflow systems, the workflow satisfiability problem, which asks whether a set of users together can complete a workflow, is recently identified as an important research problem that needs more investigation. In this paper, we study the computational complexity of the problem along two directions: one is by considering either one path or all paths of a workflow, and the other is by considering the possible patterns in a workflow. We have shown that the general workflow satisfiability analysis problem is intractable. This result motivates us to consider restrictions on workflow control-flow patterns and access control policies, and to identify tractable cases of practical interest.

A Declarative Framework for Specifying and Enforcing Purpose-Aware Policies

“…As a consequence, achieving a purpose amounts to the succesful execution of the associated workflow, which is called the Workflow Satisfiability Problem (wsp) in the literature [12] and is known to be NP-hard already in the presence of one sod constraint [33]. Several works have proposed techniques to solve both the off-line [33,26] and the on-line [6,8] version of the wsp but none considers purpose-aware policies as we do here. Indeed, we are not the first to use first-order ltl for the specification of security policies.…”

A Workflow Criticality-Based Approach to Bypass the Workflow Satisfiability Problem

“…As described in the previous section, solving the WSP is hard, in general, and proven to be NP-hard [7,8], which means that naive algorithms for solving the WSP may try all possible combinations of usertask assignments before finding a valid plan that satisfies the workflow specifications and authorizations [15].…”

“…is is a logical result (1) for each user U k in "Non_Conflict" or "Non_Conclict_CT" do (2) if t′ ← U k in ω′ and st(t′) ← ("Assigned" or "Started") then (3) if T′ is "Optional" then (4) st(t′) ← "Cancelled" (5) Return U k (6) else if T′ is "Interruptible" then (7) if T′ is "NonDelay_Sensitive" or [T′ is "Delay_Sensitive" and (H + H′ < D × nb)] then (8) if U k ∊ "Non_Conflict" then (9) if Pr(t′) < Pr(t) and Cr(ω(t′)) ≤ eta(ω) then (10) st(t′) ← "Interrupted" (11) Return U k (12) else (13) Return "null" (14) end if (15) else if U k "Non_Conflict_CT" then (16) if Cr(ω(t′)) ≤ eta(ω′) then (17) st(t′) ← "Interrupted" (18) Return U k (19) else (20) Return "null" (21) end if (22) end if (23) else (24) Return "null" (25) end if (26) else (27) Return "null" (28) end if (29) else…”

iPOJO flow: a declarative service workflow architecture for ubiquitous cloud applications

“…We compare our iCDL language and BPEL with regards to workflow pattern coverage. In the literature, workflow patterns are defined as a means of categorizing recurring problems and solutions in modeling business process (Yang et al 2014). Workflow pattern coverage should indicate how effectively complex composition scenarios can be modeled by the workflow language (Gupta et al 2015).…”