Redpaper
Owen Cline
Paul Ilechko
WebSphere Process Server Staff
Resolution Using Virtual Groups
Introduction
This IBM® Redpaper™ publication discusses a flexible set of options for routing human tasks
provided by WebSphere® Process Server to the users who are qualified and authorized to
work on them. This process is known as staff resolution. Work can be assigned to individual
named users or to groups of users.
In this paper, we describe a mechanism that, in certain situations, provides an elegant and
flexible solution for integrating WebSphere Process Server staff resolution with an external
entitlements system.
© Copyright IBM Corp. 2011. All rights reserved.
ibm.com/redbooks
1
Approaches to staff resolution
When assigning a task to groups of users, you can assign a task to each of the current
members of the group at resolution time (early binding of group membership) or you can
assign work to a named group, and resolve a specific user’s membership at the time at which
they attempt to interact with a given human task (late binding of group membership).
There are advantages and disadvantages to these approaches:
򐂰 The early binding model can quickly become stale if users’ group memberships are
volatile, whereas the late binding model is limited, in that items can only be assigned to a
single group.
򐂰 Another common concern is the number of work items created. A full database is one of
the most typical causes of poor performance.
Staff resolution does not only affect which users can claim and work on tasks. There are
multiple authorization roles that can be assigned on a given human task, such as potential
owner, reader, or administrator. These roles affect the specific nature of a given user’s
allowable interactions with a task, and are described in the series of articles in “Related
articles” on page 9.
While this is a flexible model for authorization and staff resolution, there can be situations
where it is not sufficient. In particular, this model assumes that there is a user registry (such
as an LDAP) that can be queried to obtain groups and group memberships. This is not
necessarily always the case. Many organizations have legacy entitlement systems that keep
track of user functional roles, which can be difficult to integrate into this model.
Additionally, there may also be a data entitlement aspect to the staff resolution model that
goes far beyond the normal role-based entitlement model that can be easily addressed using
group memberships.
A good example of this is in financial services. Users in a retail branch office of a financial
services company might have various roles, such as financial advisor (FA), branch manager,
or operations staff member. However, not all FAs, for example, can claim the same set of
human tasks, particularly if the work is related to customer accounts. Each FA has his own
book of accounts, which is closely guarded and is not accessible to his peers. There might be
a small group of people who can see work related to any given account. For example, two or
more advisors might work as a team, or they might have a small number of sales associates
who support them with routine customer queries. In this case, the group of people who could
claim the work is defined by a combination of the roles that those users play, in conjunction
with a data entitlement. This data entitlement could be defined based on an FA number that is
stored as an attribute on the customer account record.
A similar issue occurs at branch manager levels, where a given manager might have access
to accounts belonging to her own branch, but not to other branches. As you can see, the
number of logical groups of users is the product of the number of functional roles and the
number of distinct data entitlements. This can be an extremely high number, potentially in the
tens of thousands for a large brokerage firm. Attempting to manage these as LDAP groups
would be difficult.
An additional complication is that the functional roles and data entitlements of a person might
change on a daily basis. This can be the case if, for example, someone is sick and another
person must stand in for the absent person. Also, managing LDAP groups in this case would
also be an unnecessary overhead, as the information regarding a user’s functional and data
entitlements typically already exists in the legacy entitlements system.
2
WebSphere Process Server Staff Resolution Using Virtual Groups
The remainder of this paper describes a method for integrating WebSphere Process Server
with the functional and data entitlements maintained in external systems, using a concept that
we are calling virtual groups.
Virtual groups
WebSphere Process Server staff resolution is primarily built around the concept of using
group membership within a user registry to determine which users have access to certain
work items. However, the WebSphere Application Server security model provides the
flexibility to assert group memberships that do not actually exist in the registry. In fact, not
only can the memberships be asserted, the groups themselves do not even have to exist in
the user registry. The way that this is achieved is through the use of a custom Trust
Association Interceptor (TAI) that executes when a user logs in, and which adds a list of
virtual group names to the user’s subject (Figure 1).
Trust association model
HTTP Request:
User ID and password in basic authentication data
Modified HTTP Request:
Trusted server ID and password in basic authentication
data and user ID in the HTTP request header
Modified
HTTP
request
HTTP
request
Web
client
(1)
Reverse
proxy
server
(6)
Requested
resource
(2)
(5)
Requested
resource
Web application server
User ID
User
request
(4)
Credentials
Web
authenticator
Modified HTTP
(3)
User ID
(using the old TAI interface)
or Subject
(using the version 5.1.1
TAI++ interface)
if trust is valid
Trust
association
interceptor
Figure 1 Sample usage of a TAI
A custom TAI implements the TrustAssociationInterceptor interface defined at the
following website:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.
websphere.javadoc.doc/public_html/spi/com/ibm/wsspi/security/tai/TrustAssociation
Interceptor.html
In addition to creating virtual groups, the TAI can also look up any user registry groups (for
example, from LDAP) that the logging-in user has membership in, and add those groups to
the user’s subject. So the subject becomes a collection of virtual groups derived from the
legacy entitlement system and physical groups from the user registry. Then when the
application makes a call to WebSphere Process Server to retrieve the list of human tasks that
the user is entitled to work on, those asserted virtual groups, as well as the physical groups in
the user registry for that user, can be used to query for the appropriate human tasks.
There are good reasons for the TAI to always package any physical groups in the user’s
subject. These physical groups might be required by other applications or they might give the
user access to WebSphere Process Server administration tools such as the BPC Explorer.
WebSphere Process Server Staff Resolution Using Virtual Groups
3
Note: To use virtual groups for J2EE authorization (map users/groups to a J2EE role), the
group actually has to exist in the user registry. Only membership can be asserted. When
starting an application, WebSphere verifies the mapped groups and, if it does not exist at
application startup time, having the group name in your subject will not grant you access.
For WebSphere Process Server instance-based authorization, the groups do not need to
exist in the registry as stated above.
If work items are to be assigned to a virtual group, that group name must be one that the TAI
will actually assert to some portion of the user population. Otherwise, the tasks might be
permanently orphaned. For this to be successful, a naming system for these virtual groups
needs to be defined.
Going back to our financial services example above, the logical group of people who can
work on a given task is defined by the combination of the role that they play in the company
and certain data entitlements related to their position in the organizational hierarchy. A group
name that has sufficient uniqueness must therefore contain both the user role name and a
data entitlement. So, for example, a financial advisor who works in branch 127 and owns all
of the accounts with his FA number of 354 could be logically said to be a member of group
FA-127-354.
There might be other members of this group, for example, a sales associate who supports
that FA, or another advisor in the scenario where the FA number is a pool number used for
sharing commissions. Similarly, a branch manager who oversees branch 823 would be a
member of the group BM-823, and an operations staff person in branch 774 would be a
member of group OP-774.
So now that we have established a naming convention, how is work assignment
implemented? There are three aspects to this:
򐂰 Assigning work items to the appropriate groups at the time that the human task is created
򐂰 Placing any given user in the correct groups when they log in to the system
򐂰 Querying for tasks to display the ones belonging to this particular logged in user
Assigning work to the correct group is easily accomplished in WebSphere Process Server
using standard staff assignment capabilities. Work can be assigned using the group verb,
and a simple Java™ snippet can be written to examine metadata related to the process
instance and determine what the group name should be (Figure 2). Note that WebSphere
Process Server can only assign work to a single group name, so any single item must be
assigned specifically to one role, and to one data entitlement within that role.
In our scenario, even though certain work items might be available to be worked on by both
financial advisors and sales associates, we use the generic prefix FA for the group names.
This means that it is necessary to ensure that associates are placed in the correct groups for
all of the FAs that they support.
Figure 2 Staff assignment definitions in a human task template using replacement variables
4
WebSphere Process Server Staff Resolution Using Virtual Groups
Note that the following replacement variables are computed in a Java snippet prior to the
in-line human task being instantiated:
򐂰 %wf:variable.staffAssignment\administrators%
򐂰 %wf:variable.staffAssignment\potentialOwners%
򐂰 %wf:variable.staffAssignment\readers%
For example, the Java snippet would set the replacement variable
%wf:variable.staffAssignment\potentialOwners% equal to the virtual group FA-127-354.
The replacement variables are set to the appropriate virtual groups based upon data
extracted from the human task input message.
To ensure global administrator access to the in-line human task and its enclosing BPEL
process, you can define global administrator groups on the BPEL (Figure 3, Figure 4, and
Figure 5).
Figure 3 3 BPEL Process Administration tab
Figure 4 4 BPEL Process Administrative settings
Figure 5 BPEL Activities Administrative settings
WebSphere Process Server Staff Resolution Using Virtual Groups
5
Adding users to the groups that they need to be part of can be accomplished by writing a
custom TAI. This TAI needs to be able to make calls at login time to the existing entitlement
systems to retrieve all of the relevant data for that user, such as what roles they play in the
company and what data entitlements they possess. This is necessarily unique for any
given environment.
In certain companies, a user only has one role, based on his human resource job title. In
others, users might have multiple functional entitlements, and these might be application
specific. It might be the case that functional and data entitlements are stored separately, with
no relationships defined between them. Or it might be that data entitlements are stored for
each functional role. Whatever the case may be, the TAI needs to be able to use this data to
generate the complete list of virtual groups that the user must belong to in order to be able to
do their job. Once these groups have been correctly added to the WebSphere subject, the
WebSphere Application Server security runtime will behave the same way as if these were
actual registry groups of which the user was a member.
The final piece of the puzzle is displaying human task lists to the user. If the application uses
the standard business space or portal widgets for this, there is nothing extra to do. If the
application uses a custom user interface, then code will have to be written to make a
WebSphere Process Server API call to retrieve work items of which this user is a potential
owner. In either case, this is where the group information comes into play. The list of user
groups is retrieved by WebSphere Process Server from the WebSphere security run time,
and a query is made against the BPEDB, which is the database that contains records for
outstanding human tasks. Even though the virtual groups do not really exist in a registry, that
does not matter. It is merely a string matching exercise at this point, which takes place in the
SQL processing of the database engine. The correct set of tasks will be displayed to the user
based on her entitlements.
Other roles: Readers and administrators
There might be business requirements to allow users to see work that is not currently
assigned to them as a potential owner (or owner, once they have claimed a work item). It
might be necessary for a user to have visibility to a work item that she had previously worked
on, so that she can track its progress. There might also be a need to allow a manager to
intervene when work has been claimed by a user who, for whatever reason, can no longer
complete the task. Perhaps she is out sick, or has left the company. In that case, the manager
usually releases the item back to an unclaimed status so that someone else can take it.
The way that this is achieved is to use the WebSphere Process Server roles of reader and
administrator. These roles, just like the potential owner role, can also be assigned to either
groups or to individuals. However, there is a WebSphere Process Server limitation that might
cause problems here, which is that any given work item, for any given WebSphere Process
Server role, can only be assigned to a single group. Let us look at this in more detail.
Imagine a work item that was originally worked on by an FA from the group FA-121-452, and
then by an operations person from the group OP-123. The work item has now been sent to
the branch manager for final approval and is assigned for potential owners in the group
BM-123. There might be a requirement that both the FA and operations staff who were
entitled to work on the item previously still have read-only visibility to it, so that they can see
where it is in the workflow. But what group do you assign it to?
The role of the people with read access is no longer relevant, so you could remove that, or
replace it with a generic indicator such as READ-121-452, which is a group for people with
6
WebSphere Process Server Staff Resolution Using Virtual Groups
read access to items for that FA number. But you still have the issue of what level of
organizational hierarchy do you use?
It is probably against security policy to give FAs read access for every account in the entire
branch, but to assign the role to the lower level means that you would need to put the
operations person into a virtual group for every FA number in the branch, for every branch
that they are entitled to. This could lead to a very large number of groups, which can have
potential issues. One is that this could lead to out memory constraints in the system if a very
large number of users are logged in at the same time. Another is that this could actually
cause SQL query problems if there are more parameters than the database engine can
cope with.
There are workarounds for this problem. A different role could be used, such as admin or
editor, for giving read access to the branch level. The point is that this needs to be thought
through very carefully. If there are more layers in the hierarchy, this can easily become very
complex and very fragile.
Alternative solutions
Using virtual groups is not the only solution for integrating staff resolution with custom
entitlement systems. Another option is to use custom people queries to determine the actual
users to whom a work item can be assigned. There are various ways in which this can be
achieved, including writing a custom VMM adapter or custom VMM plug-in, or writing a
WebSphere Process Server post-processing plug-in.
One thing to be aware of is that this type of solution will require a different set of operations to
be made available by the legacy entitlement system. For the virtual group solution, the
entitlement system is called at login time, and the query that it has to answer is “what are my
set of entitlements?” For a custom staff assignment solution, the query is executed at work
assignment time, and the query that needs to be answered is “what is the set of users that
this work should be assigned to?” Clearly, these are very different operations, so it is
important to understand the capabilities of the legacy system before determining which of
these approaches is more appropriate.
A downside of using virtual groups in combination with a TAI is that a user's request has to
actually pass through the TAI to get the groups asserted. When using the WebSphere
Process Server Web Services APIs, the TAI might not be executed.
Future considerations
In WebSphere Process Server v7, there is a J2EE role for the Web Service APIs, so you can
make SOAP requests go through the TAI. In WebSphere Process Server v7, there is a
protected REST provider, which triggers the TAI too. But, unless a Web service client was
coded to create a session (getting an LTPA token and sending it with subsequent requests),
the TAI would be invoked very often and that might be a performance issue.
Summary
This IBM Redpaper publication described a mechanism that, in certain situations, provides an
elegant and flexible solution for integrating WebSphere Process Server staff resolution with
WebSphere Process Server Staff Resolution Using Virtual Groups
7
an external entitlements system. It also briefly addressed certain potential shortcomings of
this solution and pointed the reader in the direction of alternatives that might serve them
better in those situations.
The team who wrote this paper
This paper was produced by a team of specialists.
Owen Cline is a member of the IBM Software Services for WebSphere team based in San
Diego, CA. He earned a bachelor’s of science in computer science from the University of
Pittsburgh and a MS from San Diego State University. He has over 20 years of experience in
the software development field. He holds four software patents, has written IBM Redbooks®
publications, and has presented at multiple technical conferences. For the past five years,
Owen has specialized in SOA and J2EE architecture, and application development and
deployment with a special emphasis on the WebSphere platform. In addition, he has also
worked on many high-profile websites over the past few years.
Paul Ilechko is a Senior Solutions Architect with IBM Software Services for WebSphere. He
has over 25 years of experience in the IT Industry, including a background in both mainframe
and distributed technologies. He has several industry patents and is a frequent speaker at
technical conferences. Paul has been involved with WebSphere and J2EE technology almost
since their inception. His primary goal is to help IBM clients be successful with these
products. Paul has a bachelor’s of science in mathematics from the University of London.
The authors would like to thank the following colleagues for reviewing this paper:
Jens Engelke
Senior Accredited IT Specialist
IBM Software Group, Application and Integration Middleware Software
WSS WebSphere Solution Center
Keys Botzum
Senior Technical Staff Member (STSM)
Advanced WebSphere Technology Practice
IBM Software Service for WebSphere (ISSW)
Now you can become a published author, too!
Here's an opportunity to spotlight your skills, grow your career, and become a published
author—all at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
8
WebSphere Process Server Staff Resolution Using Virtual Groups
Stay connected to IBM Redbooks
򐂰 Find us on Facebook:
http://www.facebook.com/IBMRedbooks
򐂰 Follow us on Twitter:
http://twitter.com/ibmredbooks
򐂰 Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
򐂰 Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
򐂰 Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
Related articles
The following web sites provide additional information:
򐂰 Authorization and staff resolution in Business Process Choreographer: Part 1:
Understanding the concepts and components of staff resolution
http://www.ibm.com/developerworks/websphere/techjournal/0710_lind/0710_lind.html
򐂰 Authorization and staff resolution in Business Process Choreographer: Part 2:
Understanding the programming model for staff resolution
http://www.ibm.com/developerworks/websphere/techjournal/0711_lind/0711_lind.html
򐂰 Authorization and staff resolution in Business Process Choreographer: Part 3:
Customization options for staff resolution
http://www.ibm.com/developerworks/websphere/techjournal/0712_lind/0712_lind.html
򐂰 IBM WebSphere Developer Technical Journal: Advanced authentication in WebSphere
Application Server
http://www.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_
benantar.html
WebSphere Process Server Staff Resolution Using Virtual Groups
9
10
WebSphere Process Server Staff Resolution Using Virtual Groups
Contact an IBM Software Services Sales Specialist
Start SMALL,
Start BIG, ... JUST START
architectural knowledge, skills, research and development . . .
that's IBM Software Services for WebSphere.
Our highly skilled consultants make it easy for you to design, build, test and deploy solutions, helping
you build a smarter and more efficient business. Our worldwide network of services specialists wants you
to have it all! Implementation, migration, architecture and design services: IBM Software Services has
the right fit for you. We also deliver just-in-time, customized workshops and education tailored for your
business needs. You have the knowledge, now reach out to the experts who can help you extend and
realize the value.
For a WebSphere services solution that fits your needs, contact an IBM Software Services Sales Specialist:
ibm.com/developerworks/websphere/services/contacts.html
Contact an IBM Software Services Sales Specialist
11
®
Redpaper ™
12
WebSphere Process Server Staff Resolution Using Virtual Groups
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
Notices
13
This document REDP-4730-00 was created or updated on February 23, 2011.
®
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
Redpaper ™
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
IBM®
Redbooks®
Redpaper™
Redbooks (logo)
WebSphere®
®
The following terms are trademarks of other companies:
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Other company, product, or
service names may be
14
trademarks or service marks of
others.
WebSphere Process Server Staff Resolution Using Virtual Groups