Human Task Manager is an IBM WebSphere Process Server component that enables human beings to interact with Web services and business processes. A person can invoke Web services using originating tasks, act as a Web service himself using participating tasks, and collaborate with other people by invoking or working on purely human tasks. Together with Business Flow Manager, Human Task Manager provides powerful support for the execution of business processes that involve humans. Both components together make up the Business Process Choreographer.
One of the major features of Business Process Choreographer is its ability to provide an instance-based authorization for business processes and human tasks, enabling you to model sophisticated authorization rules, such as the four eyes principle, in review or approval processes. Instance-based authorization relies on staff resolution being performed to assign people to various roles for later authorization checks.
This article introduces the concepts for Business Process Choreographer authorization and staff resolution, and describes the architecture of the Human Task Manager components that are involved in staff resolution. The interaction between components such as the business process engine, human task engine, authorization management, and staff support service, are also explained.
The article assumes familiarity with the Business Process Choreographer concepts and architecture as described in the WebSphere Process Server V6 -- Business Process Choreographer: Concepts and Architecture white paper.
Figure 1 shows an overview of the Business Process Choreographer architecture, which consists of two major components:
- Business Flow Manager navigates business processes.
- Human Task Manager coordinates human interaction.
Both components share a set of common infrastructure subcomponents and are embedded in WebSphere Process Server, which is based on the J2EE™ runtime provided by IBM WebSphere Application Server.
Figure 1. Business Process Choreographer architecture
Business Flow Manager enables you to execute business processes modeled with the WS-BPEL industry standard (see Resources). Human Task Manager offers human beings the ability to participate in business processes, either by "implementing" a Web service using a participating task, or by invoking a Web service with an originating task. It also leverages the ad-hoc collaboration between humans, with purely human tasks, subtasks, and follow-on tasks.
To work with business processes and human tasks, you can model them as Service Component Architecture (SCA) modules using IBM WebSphere Integration Developer. You can then deploy the SCA modules to the runtime, where you can access them as a process or task using the respective process or task templates. From a template, you can create and start a process or task instance and work with it. For participating and purely human tasks, you can additionally define the model ad-hoc, using the runtime API only.
Business Process Choreographer provides instance- and rule-based authorization for business processes and tasks, enabling you to model sophisticated authorization scenarios based on process context, or the four-eyes principle: people are authenticated by WebSphere Application Server and then also authorized by Human Task Manager based on their user IDs. Be aware that authentication and authorization relies on WebSphere Application Server global security. Business Process Choreographer and (especially) Human Task Manager require security to be enabled; scenarios with disabled global security are supported for test purposes only.
This article focuses on staff resolution, which is mainly used to determine user IDs so people can be authorized for certain actions on processes or tasks. Staff resolution is also used to resolve e-mail addresses when the Human Task Manager e-mail service is sending notices for escalations.
Business processes that involve human interaction often need very sophisticated authorization to support multiple user roles, and to enable the processes to behave differently for each instance of the same business process template, since different business case data can be handled by the same process. J2EE authorization capabilities alone are not sufficient to handle such complex authorization rules, such as the four eyes principle used for business-critical approval or review processes.
Business Process Choreographer supports J2EE authorization, but extends it with rule-based authorization that considers business context data, and is thus able to ensure authorization at the instance level. The authorization rules are defined using so-called staff verbs (also known as people assignment criteria), which are authorization rule templates. Staff verbs are abstract authorization rules for a human task role that can be parameterized and bound to a specific staff repository during business process and human task modeling.
Business Process Choreographer provides a default set of staff verbs that can be used for standard authorization rules. You can extend the set of staff verbs to define rules that are more complex or that more closely match your needs, as required.
During deployment, the parameterized staff verbs are transformed into concrete staff queries (also known as people queries) that are specific to the staff repository used to perform the query. These staff queries are used to query for people who will become authorized to perform certain actions at run time. Querying a staff repository at run time for people, groups, and their attributes, to evaluate an authorization rule is called staff resolution (also known as people resolution). The result of a staff query can be the flag "Everybody," a set of user IDs or e-mail addresses, or the name of a group of people.
A staff repository (also known as an enterprise, staff, or people directory) is the data store that actually contains the user and group information. The most popular staff repository is the LDAP directory, which is based on the standardized Lightweight Directory Access Protocol.
When staff query parameters contain context variables that are resolved at run time, authorization is then based on process and task instance data; therefore, even though authorization is based on the same rule, the data that determines authorization can be different for each instance of the business process or human task. Context variables are enclosed in percent signs, and can refer to:
|Context variable type||Example|
|process and task custom properties||
|process and task input messages||
Be aware that only inline human tasks have access to the process context.
Figure 2. Work item
The result of a staff query is used to create so-called work items (and occasionally to send e-mail notifications). Work items are used to provide instance- and rule-based authorization by associating users with a certain business object (like a task or process instance) and, simultaneously, with one of the task's (or process') predefined authorization roles, such as reader or administrator. Each predefined role grants authorization for a fixed set of actions that the user is permitted to perform on this business entity, such as claiming a task or getting the process instance data. Thus, authorization is granted by associating a person with a role on a business object.
There are three types of work items used to store the three types of staff query results:
- Everybody work items grant authorization to every (authenticated) user associated with the work item role (also known as assignment reason).
- User work items grant role authorization to each user whose user ID is stored with the work item.
- Group work items grant role authorization to an entire group of people. Authorization is not performed using the user ID, but by verifying the list of group memberships associated with the user's login context information.
Work items cache the staff query results; since staff queries do not need to be executed for every authorization check (which would cause a heavy load on the staff repository in use), work items provide a major performance advantage. However, cached information does have the potential of becoming outdated. Business Process Choreographer supports refreshing the work item cache manually from the administrative console, or automatically using a staff query result refresh daemon that refreshes expired results. If the original result has been modified manually using the work item transfer functionality, a refresh of the original result considers the transfer history and does not override manual changes. (Only user work items are refreshed in this manner. Authorization based on group work items is refreshed automatically each time a user logs in to WebSphere Process Server.)
Figure 3 shows the Business Process Choreographer components involved in authorization and staff resolution.
Figure 3. Staff resolution architecture
Users interact either with the Business Process Choreographer Explorer, or with another client based on the Business Process Choreographer APIs. These client applications send their requests to either the Business Flow Manager Process API or the Human Task API. Authentication is provided by the WebSphere Application Server security component, and the instance- and rule-based authorization is provided by Human Task Manager using work items.
Key Business Process Choreographer components include:
Authorization management is the central instance that evaluates staff verbs (authorization rules) and performs authorization based on them. Authorization management invokes other components to perform staff resolution queries, and creates work items based on the results. These work items are stored in the Business Process Choreographer database, thus caching staff resolution results. When a client invokes the Business Flow Manager or Human Task Manager API, authorization management checks the stored work items for a matching authorization of the calling user.
Authorization management coordinates other components, such as the staff support service and staff query result post-processor plug-in, whenever staff resolution needs to resolve user IDs or e-mail addresses.
The e-mail service is responsible for creating and sending e-mails whenever an escalation occurs that is modeled to send an e-mail to all escalation receivers. In this case, authorization management is invoked to resolve the e-mail addresses of the escalation receivers, along with their user IDs to grant them authorization for the escalation and task.
Every organization is subject to changes, and so staff resolution results can become outdated and need to be refreshed in the work item cache. The staff query result refresh daemon (also known as people assignment refresh daemon) is responsible for refreshing staff query results that have expired.
When the refresh daemon finds a staff query result that is expired, it invokes authorization management according to the staff verb associated with the corresponding work item, then stores the newly retrieved staff query result with the existing work item. Therefore, in the case of an organizational change, the refresh daemon keeps the work item cache up to date.
Keep in mind that when refreshing the work item cache, changes of context variables will not be considered; the refresh occurs based on the context data available when staff resolution for this staff query was performed the first time. Also, a work item transfer is not canceled by this refresh, since the transfer history is applied again to the refreshed result.
The staff query result refresh is controlled by two parameters:
- Timeout for staff query result determines how long after the last update a staff query result remains valid. When this time period has passed, the query result is available for update.
- Staff query refresh schedule controls when the refresh daemon runs to refresh expired query results.
Remember that you can also enforce staff query result refreshes manually using either the administration console or the JACL script refreshStaffQuery.jacl. When you refresh in this way, all staff query results that you specify are refreshed, not only the expired ones.
(The refresh daemon is only available in WebSphere Process Server V6.0.2 and later.)
Staff support service
The staff support service (also know as people assignment service) manages, configures, and selects staff resolution plug-ins, transforms parameterized staff verbs into queries specific to a staff resolution plug-in, and delegates deployment and staff resolution requests to the selected plug-in.
As mentioned earlier, when you model a business process or human task, you can use abstract staff verbs and parameterize them to create an authorization rule. The staff support service translates the parameterized staff verb, generated by WebSphere Integration Developer at modeling time, into a staff resolution plug-in-specific query, bound to a specific staff repository. This transformation is done when the business process or human task is deployed, using a mapping XSLT (Extensible Stylesheet Language for Transformations) file.
A staff plug-in provider is supplied for each staff resolution plug-in supported by Business Process Choreographer. A staff plug-in provider (also known as people directory provider) can have multiple configurations. Each staff plug-in configuration (also known as people directory configuration) has its own set of configuration properties that can be set in the administrative console. Some of these properties, such as LDAP server settings, might need to be customized before the plug-in can be used. Each configuration also has its own JNDI (Java™ Naming and Directory Interface) name, and a reference to an XSLT transformation file.
The staff support service uses the configuration JNDI name to locate the configuration. The human task modeler in the WebSphere Integration Developer Human Task Editor uses the configuration JNDI name to select which staff plug-in configuration to use with a human task. The XSLT transformation file is used to transform the parameterized staff verb into the plug-in language and staff directory schema of the selected staff plug-in configuration.
LDAP and user registry plug-ins
Staff resolution plug-ins (also known as people directory plug-in) query staff repositories to resolve authorization rules, and to retrieve the user IDs or e-mail addresses of people authorized for a certain human task role.
A staff resolution plug-in is bound to a specific staff repository, like the WebSphere Application Server user registry or an LDAP directory. The plug-in is responsible for the deployment and execution of staff queries, and performs these queries by invoking a set of API calls against its associated staff repository. (More on staff resolution plug-ins later.)
Staff repositories are not part of Business Process Choreographer. They are accessed in read-only mode by staff resolution plug-ins.
The staff query result post-processor plug-in (also known as people assignment post-processor plug-in) is an optional service provider interface (SPI) that you can implement, enabling you to alter the results returned by a staff resolution plug-in. This can be used, for example, if load balancing is required for potential task owners, to delete users from the list that already have a high workload, add further users, and so on, perhaps to ensure a certain level of performance to match a service level agreement.
The plug-in receives the existing staff query result and context information as input, and returns the altered staff query result, which is then used for authorization. The plug-in can even change the query result type by returning, for example, a group name instead of the original set of users.
This plug-in also provides the ability to plug custom staff repositories into Human Task Manager staff resolution. If the plug-in ignores the input provided by the staff resolution plug-in, and performs full staff queries against the custom staff repository, it can act as a staff resolution plug-in itself, thus providing staff query functionality for custom repositories that is even more sophisticated than the query functionality of the user registry staff resolution plug-in.
Human Task Manager authorization management coordinates other components when evaluating the modeled authorization rules, and creates work items that store the result of this evaluation. When a client invokes a Business Flow Manager or Human Task Manager API, the authorization manager checks the stored work items for a matching authorization of the calling user. The same applies to the result set entries when a user queries items on the Business Process Choreographer database view using one of the query() API methods (see Resources).
Authorization management is involved when:
- A human task is deployed.
- A human task is created or started.
- A Human Task Manager and Business Flow Manager EJB API method is invoked.
- The Business Process Manager database views are queried using the query() method.
- A work item is transferred.
- The e-mail service sends e-mails.
- The refresh daemon is running.
Work items are managed by the authorization manager, based on the lists of associated user IDs provided by the staff support service, using the respective staff resolution plug-in. The staff support service and its plug-ins perform staff resolution and are involved whenever a list of user IDs or a group name is needed for creating or refreshing a work item, or when a list of user e-mail addresses is needed by the e-mail service. The staff support service does not perform staff resolution itself; rather, it delegates the task to one of the staff resolution plug-ins. The selected plug-in invokes the API of the associated staff repository and, as a result, retrieves a list of user IDs, a group name, and, optionally, e-mail addresses.
Since authorization can be specific to a task or process instance, rather than to a task or process template, the authorization to perform a certain action can depend on the context of the task; for example, the manager of the process starter can be assigned as the potential owner to an approval task in that specific business process.
When authorization management invokes the staff support service to resolve a staff query, it selects the suitable plug-in to which it delegates the staff resolution task. Staff resolution plug-ins are then responsible for retrieving the staff information from the external staff repository. Various types of staff repositories can be supported in this way.
Staff resolution plug-ins are also involved when a business process or human task model is deployed; this means the parameterized staff verbs contained in the model need to be deployed as well. After the staff support service has transformed the parameterized staff verbs into the plug-in-specific query language, the plug-in is invoked to verify the resulting staff query syntax, and to deploy the query by producing an optimized form of the query that can be executed quickly at run time. The resulting deployed staff query is stored in the Business Process Choreographer database and is available at run time.
At run time, the plug-ins are invoked with the deployed query and a list of resolved context variables as parameters. A plug-in performs staff resolution by querying the back end staff repository's API according to the instructions stored in the deployed staff query, and returns a list of user IDs (caller principal names), e-mail addresses, or a group name. The result is used by authorization management to create work items.
Staff resolution plug-ins can be considered to be stateless; only their configuration information is kept in memory. Since every request is handled in a separate thread, better scalability is possible.
Staff resolution plug-ins are tailored to particular staff repository types. Figure 4 shows the supported staff resolution plug-ins and staff repositories.
Figure 4. Supported staff resolution plug-ins and staff repositories
The default configuration that can be used out-of-the-box is the user registry plug-in with the Local OS user registry. However, this configuration does not offer the powerful query functionality provided by the LDAP plug-in with an LDAP directory, which is recommended for production environments.
You should use the same staff repository for Business Process Choreographer authorization that you use for WebSphere Application Server security and authentication (the one configured for the user registry). Otherwise, the two staff repositories might not always be synchronized, possibly resulting in authenticated users not being authorized to access business objects, or vice versa.
The staff resolution plug-ins included with Business Process Choreographer are:
User registry staff resolution plug-in
This plug-in enables you to refer to users and groups that are known to WebSphere Application Server by performing queries against the user registry API. Because the user registry is available whenever WebSphere Application Server security is enabled, and because the plug-in does not require any configuration parameters, this plug-in can be used out-of-the-box.
The plug-in supports static staff assignments and context variables, but not retrieval of e-mail addresses. It supports user ID validation, retrieval of groups and group members, user searching, and group searching, where the group's members will get a work item assigned.
The plug-in supports the retrieval of staff information from the various types of staff repositories the user registry supports:
- The user and group administration of the operating system on the machine where WebSphere Application Server is installed can be used as a staff repository. If both a domain controller and the local machine are used for security and the same group exists in both places, the local OS user registry on Windows returns users from both the domain and the local machine. You can avoid this by fully-qualifying the group name; for example, mymachine\mygroup.
- Any LDAP directory server supported by WebSphere Application Server can be used when WebSphere Application Server security is configured for this LDAP server. The query functionality offered by the LDAP plug-in is superior to the one offered by this configuration, since the LDAP plug-in accesses the LDAP server directly and can perform more sophisticated queries. Whenever possible, use the LDAP plug-in directly when accessing LDAP repositories.
- Any custom repository that implements the user registry SPI can be used as a staff repository. However, the deprecated getUsersForGroup() method of the UserRegistry interface must be implemented for custom registries to be supported by the user registry staff resolution plug-in.
LDAP staff resolution plug-in
This plug-in provides access to organizational information that is stored in LDAP directories, and uses the JNDI API to access the LDAP directory server. You can configure multiple LDAP plug-ins, with each one accessing a different LDAP directory server. Also, many configurations connecting to the same LDAP server can improve the total staff query performance.
You can use this plug-in to query for user attributes, retrieve groups, evaluate members of LDAP groups, perform searches based on the LDAP filter syntax, or perform queries with intermediate results; for example, retrieve the user ID of the user's manager. The plug-in supports static staff assignments and context variables, as well as retrieval of e-mail addresses.
The LDAP staff resolution plug-in requires several deployment parameters that are managed via the staff support service administration user interface. Most configuration parameters are needed to set up the JNDI connection, and others set query default values.
System staff resolution plug-in
This plug-in supports static staff assignments of user IDs, group names, and context variables, but no retrieval of e-mail addresses. It has no staff repository assigned, no configuration parameters, and can thus be used out-of-the-box. It has no back end repository to query against and is not enabled for production environments, but it is useful for simple test scenarios with staff support.
"Everybody" staff plug-in configuration
The "Everybody" staff plug-in configuration is based on the system staff resolution plug-in and supports all queries, but always returns "everybody" as the staff query result. It is intended for functional tests, not for production. Using this plug-in provider, you can model your staff queries for any plug-in, and switch authorization during your tests on and off by simply changing the staff plug-in provider JNDI name for a task.
Human Task Manager provides powerful instance- and business context-based authorization for those involved in business process and service-oriented architectures. It performs staff resolution queries based on flexible authorization rules, and caches the query results for better authorization performance. Given its modular architecture, Human Task Manager can support various people directories for authorization.
This article described the WebSphere Process Server Business Process Choreographer rule- and instance-based authorization concepts, and the architecture of the Business Process Choreographer components supporting the open and flexible staff resolution. The people directories that are supported by the Business Process Choreographer were also described, along with configuration recommendations for production environments.
The author thanks his colleagues Eric Van Norman and Gerhard Pfau for their help in preparing this article.
WebSphere Process Server V6 Business Process Choreographer: Concepts and Architecture
WS-BPEL Specification Version 1.1
WS-BPEL Specification Version 2.0
WebSphere Process Server Information Center
WebSphere Application Server Information Center
Working with Business Process Choreographer
Work items and the query() API call
Member Manager staff plug-in provider