Pattern 4 (Authorization)
FLASH animation of Authorization pattern
Description
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.
Example
- 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.
Motivation
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.
Overview
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.
Context
There are no specific context conditions associated with this pattern.
Implementation
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.
Issues
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.
Solutions
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.
Product/Language |
Version |
Score |
Motivation |
---|---|---|---|
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 |
---|---|
|
|