Databases Reference
In-Depth Information
the organization. In workflow environments, role-based authorization also fa-
cilitates dynamic load balancing when a task can be performed by several
individuals. Most commercials WFMSs support role-based authorizations.
The synchronization of the workflow and the authorization flow, as accom-
plished by WAM, is illustrated with the following example:
Example 2.
Consider the workflow in example 1. Suppose the associated ex-
ecuting agents for performing tasks
T
1
,
T
2
and
T
3
are John, Mary, and Ken
respectively. The authorization templates associated with the tasks would
be:
AT
(
T
1
)=(
employee,
(
claim
)
, prepare
),
AT
(
T
2
)=(
supervisor,
(
claim
◦
)
, approve
)and
AT
(
T
3
)=(
clerk,
(
claim
)
, issue
). When John initiates a
◦
◦
claim, the hole (i.e.,
)in
AT
(
T
1
) will be filled with the object being pro-
cessed by
T
1
. As soon as the object hole in the authorization template is filled
with the claim form, John receives the authorization to prepare it. Assume
he starts this at time 40. At this point, John is granted the authorization
to prepare the claim. Suppose he finishes it and sends it to his supervisor at
time 47. The authorization template then generates the authorization (John,
claim1, prepare, [40,47]), which means the authorization is revoked as soon
as he finishes his task. When he finishes
T
1
, the object was send to
T
2
, i.e.,
for approval. Now the hole in
AT
(
T
2
) is filled with this object. When the
claim (the instance is claim1) arrives to Mary at 47, an authorization to ap-
prove is given to Mary. However, John no longer holds the authorization on
this instance of the claim any more. When Mary finishes the approval task,
say at 82, her authorization is revoked, thus generating (Mary, claim1, ap-
prove, (47,82)). Finally, when Mary approves the claim, the hole in
AT
(
T
2
)
and filled in
AT
(
T
3
), and appropriate authorizations are generated. In this
fashion, WAM synchronizes the authorization flow with the progression of the
workflow.
◦
4 Separation of Duty
By using authorization templates, one can ensure that access to resources to
perform relevant tasks is only given along with the progression of the workflow.
In addition to this simple authorization specification as to who is allowed
to perform a task and when, workflow designers often specify separation of
duty constraints primarily to minimize risk due to fraudulent activities. These
constraints, also know as Separation of Duty (SOD) constraints, are rules
stating that the executing agent for one task is constrained from performing
another task. Considering once again example 1, such a constraint could be
that the tasks “prepare claim” and “issue check” should not be executed by
the same user [24]. Constraints can also be specified to obtain the opposite
effect of separation of duty, that is to specify a binding constraint. An example
of a binding constraint is that the person assigned to one task should also be
assigned to another.
