Databases Reference
In-Depth Information
Crampton et al. [14, 26] provide a simpler reference model for those cases
where tasks can be partially ordered. They define a workflow reference model
which determines whether a workflow can complete if a particular user is
assigned to a particular task. The reference monitor works by considering
only those tasks that directly flow from the task in question.
Wainer et al. [27] describe a permission system that is used in conjunc-
tion with a workflow management system. When a task is to be executed,
the WFMS queries the permission system as to which users are authorized to
perform the task. The permission system has an organizational model includ-
ing business rules and constraints, organizational assignments (i.e., who is in
what group or department or division) and project assignments. It can be an
Enterprise Resource Planning (ERP) component. Proposals like this one help
to move business policies away, not only from applications, but even from
workflow systems, allowing consistent utilization of business policies across
all applications. This proposed approach can work with any of the constraint
checking models.
Hung and Karlapalam [19] define a multi-level state machine to address
workflow security at three levels: workflow, control and data. At the work-
flow level, the state machine is concerned with task authorization and as-
signment/revocation of needed permissions. The control level is involved with
monitoring events during the execution of a task. Finally, the data level is
concerned with actually information object access. Associated with each task
in a workflow are the data objects needed and the order in which the objects
should be accessed. The data level enforces the rules associated with access
to the data objects.
Atluri and Warner [7] identify the need to further coordinate or check run-
time workflows with other conditions and constraints that might apply on the
people or objects one might want to associate with the workflow instance. In
particular, they describe the need to check task dependencies conditions and
conditional authorization constraints against role activation constraints as in-
troduced by Bertino et al. in [8]. Role activation constraints are constraints
that limit when a role can be activated. Discussed in [8] were temporal con-
straints such that a role could only be activated during certain periods of time.
For example, a consultant role might only be activated during the timeframe
of a contract. Alternatively, role activation constraints might be introduced
based on environmental or variables of the activity being performed. For ex-
ample, one might constrain a user from activating a Area Manager role from
a remote computer for fear of intellectual property leakage over the Internet.
Atluri and Warner [28] further describe the need to be able to constrain
participation in tasks based upon historical participation in tasks. This is
particularly important if a set of users can perform both tasks involving sub-
mitting a request and approving a request. In a single instance of the workflow,
SoD can be accomplished by forbidding the same user form performing both
tasks. However, over several instances, a group of individuals can collude where
they continue to participate in the two tasks but different people perform the
