Securing process applications
IBM Business Automation Workflow defines a fine-grained authorization model that uses groups, roles, and teams.
Groups
Groups are collections of users. Being a member of a group does not grant a user any specific permission. Users are added to the collection, which simplifies administration by allowing administrators to assign the entire collection of users within the group to a role instead of having to manage long lists of users individually. Business Automation Workflow default security groups are an exception; permissions are associated with membership in these configurable groups. Refer to the IBM Business Automation Workflow default group types topic for more details and a list of the IBM Business Automation Workflow default groups, including their corresponding descriptions.In the JavaScript API for processes and service flows (which is described in the topic JavaScript API in processes and service flows), the word role and the object TWRole are synonyms for the word group. They have nothing in common with the roles authorization model described in the following Roles section.
Roles
Roles are a logical application level construct that divides the user population into multiple classes of users. For example, in a website shopping application, you might have the following roles:- Administrators
- Catalog managers
- Customers
- Anonymous
Different roles can be assigned different levels of security, and the security access of individuals, or groups of individuals, can be controlled by assigning them to specific roles.
- WebSphere®
Application Server administrative
roles. See Administrative roles
. - Business Automation Workflow application Java EE roles. See IBM Business Automation Workflow application Java EE roles.
- Business Automation Workflow security roles that allow configuring system accounts. See Business Automation Workflow security roles.
Teams
Teams are used to define groups of users who can perform tasks. A team can either be defined as a static list of users and groups, or be defined dynamically by a service. You can assign a team of managers to each team to define which people in the organization can perform managerial actions for the team. Teams have aspects of both groups and roles. As tasks are assigned to teams, a user is granted access to a task by adding the user to the team. Teams with statically defined members are a collection of users, which is similar to a group. Unlike groups, teams have the concept of team managers.| Task | Interface | To learn more |
|---|---|---|
| Granting access to the repository | Workflow Center | See Managing access to the Workflow Center repository. |
| Binding users to teams during process development | Designer in Process Designer | See Creating a team. |
| Defining who has managerial authority over a team | Designer in Process Designer | See Defining team managers. |
| Using services to define dynamic teams | Designer in Process Designer | See Using services to define dynamic teams. |
| Assigning an activity to a team | Designer in Process Designer | See Assigning teams to process activities. |
| Adding users and groups from a user registry to Business Automation Workflow security groups | Process Admin Console | See Creating and managing groups. |
| Modifying existing teams at run time | Process Admin Console | See Configuring runtime teams. |
Users
| Task | Interface | To learn more |
|---|---|---|
| Restricting inactive users from participating in runtime operations | Command line | See Runtime user availability and lifecycle. |
User registry
IBM Business Automation Workflow authorization relies on users and groups that are defined in the user registry. A user registry is an architectural layer that manages users and groups in WebSphere Application Server. LDAP servers are the most commonly used source of user and group data storage. Although IBM Business Automation Workflow can utilize a stand-alone LDAP registry, you should use a federated repository configuration that can comprise multiple LDAP repositories. For more information, see Authentication of users.
IBM Business Automation Workflow does
not lock user accounts after a configurable number of failed authentication
attempts. End user accounts are managed in a user repository (typically
LDAP connected to Federated Repositories). IBM Business Automation Workflow is
just one of many client systems to the user repository. The user repository
is the system of records for the user accounts and therefore defines
rules such as password lock policy. For IBM Security Directory
Suite,
you can read more about password policies at Additional information on password policy
.
The following diagram illustrates how WebSphere Application Server and applications access user and group data in the user registry.
The following diagram illustrates how the user registry works for member management APIs.
Encrypted communication
In most interactions between a client, such as a browser, and the server, user credentials are sent. To avoid attacks on those credentials, we recommend that encrypted communication is used. For example, if you open a web browser and it containshttp:// and it is asking for a user
name and password, you should not enter that information. Only a secure https:// page
should be used. For more information, see Configuring Secure Sockets Layer (SSL) communication in a network deployment environment.Authorization
Authorization roles are used to determine the actions that a user can take on objects, such as processes, tasks, and user data. For information about how to protect the REST services, coach views, or external implementations that call a service flow, see step 6 in Creating a service flow. For information about how to protect REST APIs, see Authorization for Workflow REST APIs.
This topic only applies to BAW, and is located in the BAW repository. Last updated on 2025-03-13 12:15