Overview

Authorization is used to assign specific privileges to particular users or particular groups of users. In business terms, these privileges could be the permissions to access sensitive business data or the allowance to launch sensitive business processes.

Some business processes might change sensitive business data and therefore only authorized personnel should be authorized to start and use these processes. The WebSphere Process Server offers the option to assign a human task to the initiating Receive activity of the process. Technically spoken, an inline invocation task is specified for the process template. The staff query result of the assigned human task is used to derive the set of potential starters for that process. At runtime, the WebSphere Process Server enforces that only those who are authorized according to the specified staff query results are able to start processes.

This security constraint is enforced for nested processes as well: if some process tries to invoke a subprocess, the invoked subprocess will again check at runtime that the starter of the parent process is also an authorized potential starter specified for the initiating Receive activity of the subprocess. In case that the user who started the parent process is not authorized to start the subprocess as well, an exception is thrown.

Note that if you do not explicitly specify a human task for the potential starters, the default (Everybody) is implicitly used by WebSphere Process Server.

Administrative Tasks

To enable a user or group of users to perform administrative actions like suspending, resuming, or terminating and deleting a business process you can use administrative tasks. A task definition for an administrative Task (aTask) can be specified as a part of a long running BPEL process to define which users are allowed to perform administrative actions. Another aTask template can be modeled in order to define the users who are allowed to perform administrative operations on failed activities of that process. In this sample, an aTask is used to administer business process instances. When the respective process instance is initiated, a corresponding aTask instance is created implicitly by the process engine, which will manage to enable the appropriate users to administer the process instance; the aTask instance is automatically deleted together with the associated process instance.

Sample business scenario

In this sample, we use two simplified business processes which access business data of different sensibility.

On the one hand, we simulate an Order process, which is meant to be a typical non-sensitive business process that can be initiated and carried out by most employees of a company. Throughout this sample we use an organizational group sellers, which contains all user IDs that are allowed to start this particular process. To keep the sample as simple as possible, this process only consists of four steps:

1. In the first step called Receive, the process receives the name of the customer, the id of the ordered item and the prize.
2. The second step just waits for a predefined length of time (e.g. 2 minutes), to simulate the processing of additional operations, for example plausibility checks, which are left out for simplicity reasons. This step extends the duration during which a process instance is found in the running state, which is helpful if you want to try administrative operations while this is the case.
3. The third step simulates the update of a repository holding operational data. Actually, no data are accessed during this sample; instead, just a log entry is written to the Application Server's output log.
4. In the final step, the business process terminates.

Figure 1: Order process

On the other hand, we simulate a Delete Customer process, which is meant to be a typical sensitive business process that can be initiated and carried out only by a few employees in the company. For defining this group of more privileged users, we use the organizational group approvers. For simplicity of the sample, here the groups sellers and approvers are defined as disjoint groups; instead, you could rather define overlapping groups (i.e. define particular users to be members in several groups).

The business process definition of Delete Customer is almost identical to the Order process; these are the differences:

• The name is different, to suggest the difference between sensitive and non-sensitive processes;
• The input data are slightly different;
• The third step now simulates access to sensitive customer data (rather then operational data); again, no real data are accessed, but the log record written is slightly different;
• The staff definition representing the authorized users to start this process specifies a different organizational group.

Figure 2: Delete Customer process

Prerequisites

This sample uses the user registry of your local operating system as repository. In order to use this sample you have to ensure that a group Sellers exists on your systems and that several users are members of that group.

These user groups and users can be created running a command line script; a simple command line script that administrators can run on Windows(TM) looks like this:
ADDUSERS1.BAT

Similarly, these user groups and users can be deleted again after finishing this sample; a simple command line script for Windows(TM) looks like this:
DELETEUSERS1.BAT