Pattern 4 (Authorization)

FLASH animation of Authorization pattern


The ability to specify the range of privileges that a resource possesses in regard to the execution of a process. In the main, these privileges define the range of actions that a resource can initiate when undertaking work items associated with tasks in a process.


  • Only the Finance Director, Senior Loans Manager and Financial Accountant are authorised to execute instances of the Finalise Loan task.
  • Only Senior Managers can suspend instances of the conduct audit task.


Through the specification of authorizations on task definitions, it is possible to define a security framework over a process that is independent of the way in which work items are actually routed at runtime. This can be used to restrict the range of resources that can access details of a work item or request, execute or redistribute it. This ensures that unexpected events that may arise during execution (e.g. work item delegation by a resource or reallocation to another resource outside of the usual process definition) do not lead to unexpected resources being able to undertake work items.


The Authorization pattern takes the form of a set of relationships between resources and the privileges that they possess in regard to a given process. These privileges define the range of actions that the resource can initiate and can include operations such as:

  • choose - the ability to select the next work item that they will execute;
  • concurrent - the ability to execute more than one work item simultaneously;
  • reorder - the ability to reorder work items in their work list;
  • view offers - the ability to view all offered work items in the process environment;
  • view allocations - the ability to view all allocated work items in the process environment;
  • view executions - the ability to view all executing work items in the process environment; and
  • chained execution - the ability to enter the chained execution mode.

Additionally, it is also possible to specify further user privileges on a per task basis including:

  • suspend - the ability to suspend and resume instances of this task during execution;
  • stateless reallocate - the ability to reallocate instances of this task which have been commenced to another user;
  • stateful reallocate - the ability to reallocate instances of this task which have been commenced to another user and retain any associated state data;
  • deallocate - the ability to deallocate instances of this task which have not been commenced and allow them to be re-allocated;
  • delegate - the ability to delegate instances of this task which have not been commenced to another user;
  • skip - the ability to skip instances of this task; and
  • piled execution - the ability to enter the piled execution mode for work items corresponding to this task.


There are no specific context conditions associated with this pattern.


COSA is the only offering observed that implements the notion of task authorization as a distinct concept to that of task distribution. It treats authorization and distribution of tasks in a similar way in the design time model and provides facilities for defining the resources, groups and roles that are authorized to execute a task and also those to which it can be allocated. FLOWer uses roles as the main basis for case and work item distribution. Roles are organized as hierarchies and only resources that directly (or indirectly) possess a required role are able to view and execute a specific work item.


The range of resources that are authorized to undertake a task may not correspond to those to which it could be assigned based on the current resource pool within the PAIS.


COSA provides a solution to this scenerio as follows:

  • Where a resource is allocated a work item that is not authorised to execute, the work item will appear in its work list, but the resource cannot execute it. The resource can however reassign it to another resource that may be able to execute it
  • Where a resource is authorised to undertake a given task, but the task is not able to be distributed to the resource (i.e. the distribution rules for the task preclude it from being allocated to the resource), work items corresponding to the task will never appear in the work list for the resource but resource is able to execute them if they are directly allocated to it by other resources.

Evaluation Criteria

An offering achieves full support if it satisfies the description for the pattern.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.





Staffware 9 - Not supported
Websphere MQ Workflow 3.4 - Not supported
FLOWer 3.0 + Use of execute roles allows authentication to be enforced
COSA 4 + Distinct authorisation and distribution mechanisms are supported
iPlanet 3.1 - Not supported
BPMN 1.0 - Not supported
UML 2.0 - Not supported
Oracle BPEL 10.1.2 - This pattern is not supported by Oracle BPEL. It is possible to assign a work item to a specified role, and this work item can be reassigned to any other user/role. However, it is not possible to (re-)assign a task based on the condition, i.e. to a user having a certain authority
jBPM 3.1.4 - jBPM does not support this pattern.
OpenWFE 1.7.3 - OpenWFE does not support this pattern.
Enhydra Shark 2 - Enhydra Shark does not support this pattern.

Summary of Evaluation

+ Rating

+/- Rating

  1. Workflow engine provides a distinct security framework defining which resources can execute which work items.
  2. Authorisation to execute a work item is independent of the routing mechanism.
  1. Authorisation is incorporated in the work distribution mechanisms.
  2. Achievable via precondition specification or programmatic extensions for each task.