Securing IBM Business Process Manager and applications

Security of IBM Business Process Manager depends on securing the runtime environment and securing applications.

Securing the environment involves enabling administrative security, enabling application security, creating profiles with security, and restricting access to critical functions to users or groups assigned to specific roles. See IBM Business Process Manager security roles.

Application security is turned on by default in BPM and cannot be turned off.

IBM Business Process Manager security is based on the WebSphere Application Server version 8.5 security. For detailed information, see the WebSphere Application Server Network Deployment Information Center.

Security tasks can be broadly divided into those concerning the administration of security in the BPM environment and those that are related to the applications running in BPM. The security of the server environment is central to the security of applications, and therefore the two sides should not be thought of in isolation.


Related reference:

Security considerations specific to IBM Business Process Manager


Getting started with security

Security is an integral consideration when you are planning to install BPM, when you are developing and deploying applications, and in the day-to-day running of IBM Business Process Manager.



Related concepts:

Securing access to timetables in the Business Calendars widget


Related tasks:

Configure administrative and application security

Configure a user account repository

Deploy secure applications

Assigning users to roles

Configure IBM Business Process Manager security for a stand-alone server

Configure IBM Business Process Manager security for a deployment environment server


Understanding elements of application security

Applications that run in BPM are secured through a number of elements such as authentication, access control, data integrity, privacy, and identity propagation.

The following topics provide more information for application security in BPM:



Authentication of users

Clients must be authenticated by providing a user name and password from the user registry when administrative security is enabled. If a client tries to access a secured application without being authenticated, an exception is generated.

Table 1 lists typical clients that would invoke IBM Business Process Manager components, and the authentication options available for each type of client.

Authentication options for various clients

Client Authentication options Notes
Web services clients You can use WS-Security/SOAP authentication  
Web or HTTP clients HTTP Basic authentication (the browser prompts the client for a user name and password) These clients reference JSPs, Servlets, and HTML documents
Java™ clients JAAS  
All clients SSL client authentication  


Web Services Security support


Characters that are valid for user IDs and passwords

Understanding character limitations for user IDs and passwords is important because they are used throughout IBM Business Process Manager to provide access and secure content. The character limitations provided here apply to the BPM administrator, the database administrator, the LDAP server administrator, and user IDs. Database and LDAP servers can have more restrictive limitations than provided here. Therefore you should check the database, and LDAP server product documentation for restrictions. Failure to define user IDs and passwords correctly during the installation process can result in installation failure. In addition, your specific installation might have more restrictive user ID and password requirements that also follow.

When a person signs up as a user, or when an administrator enrolls a user, they must complete the user information form. On this form, do not enter characters that might not be supported. Regardless of which characters you are able to enter on the user information form, user ID and passwords are limited to the valid characters described here. You can specify other characters in the First Name and Last Name fields. If your company policy is more restrictive, you can provide that information to your users in the enrollment form help or as inline help directly on the form.

Avoid trouble: IBM Business Process Manager cannot user IDs or passwords that contain spaces, although it fully supports any existing user IDs and passwords or those created in the user repository that contain spaces.

Under normal circumstances, a valid user ID and password can contain the following characters:

Avoid trouble: These are all ASCII characters. Non-ASCII characters are not allowed for a username or password.

If you plan on using a non-ASCII based encoding, ensure your Java Virtual Machine has the correct generic arguments specific for the non-ASCII based encoding. For example, for UTF-8 encoding, the following two parameters should be added to the Java Virtual Machine generic arguments for WebSphere Portal: -Dfile.encoding=UTF-8 and -Dclient.encoding.override=UTF-8.

Note: Some tasks might require you to enter the fully qualified user ID. If your fully qualified user ID contains a space; for example: cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com, you must place the fully qualified user ID in the properties file or into a parent properties file instead of as a flag on the command line. For example, create a parent properties file called mysecurity.properties, enter the fully qualified user ID, and then run the task: ./ConfigEngine.sh task_name -DparentProperties=/opt/mysecurity.properties.

Note: Some tasks may require you to enter the fully qualified user ID. If your fully qualified user ID contains a space; for example: cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com, you must place quotes around the fully qualified user ID before running the task; for example, "cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com".

The following table contains a list of the required fields on the user information form and the supported characters.

Valid characters and unsupported characters for user information

User information Valid characters Unsupported characters
User ID

  • Lowercase characters {a-z}
  • Uppercase characters {A-Z}
  • Numbers {0-9}
  • Exclamation point {!}

  • Open parenthesis {(}
  • Close parenthesis {)}
  • Dash {-}; this character is not supported as the first character in the user ID or password
  • Period {.}; this character is not supported as the first character in the user ID or password
  • Question mark {?}

  • Open bracket {[}
  • Close bracket {]}

  • Underscore {_}; this is the only supported special character in IBM i
  • Grave accent {`}
  • Tilde {~}
  • Semicolon {;}
  • Colon {:}
  • Exclamation mark {!}
  • Commercial at {@} (this character is not supported when creating the cell administrator during installation)
  • Number sign {#}
  • Dollar sign {$}
  • Percent sign {%}
  • Circumflex accent {^}
  • Ampersand {&}
  • Asterisk {*}
  • Plus sign {+}
  • Equals sign {=}

Only ASCII characters are allowed.

Other restrictions: The user ID cannot contain spaces; for example, user name.

User IDs cannot be longer than 200 characters.

If you enter any unsupported characters during the installation, you will receive an error message that states which character is invalid. For example, The special character [@] was found in the administrative user ID field. Enter the administrative user ID again.

Avoid trouble: You receive a different error message if you enter any unsupported characters when creating users through the Manage users and groups portlet.

Password / Confirm password:

For bpm.cell.authenticationAlias:

    Lowercase characters {a-z}     Uppercase characters {A-Z}     Numbers {0-9}     Exclamation point {!}     Open parenthesis {(}     Close parenthesis {)}     Dash {-}; this character is not supported as the first character in the user ID or password     Period {.}; this character is not supported as the first character in the user ID or password     Question mark {?}     Open bracket {[}     Close bracket {]}     Underscore {_}; this is the only supported special character in IBM i     Grave accent {`}     Tilde {~} Number sign {#} Dollar sign {$} Circumflex accent {^} Ampersand {&} Asterisk {*} Plus sign {+} Equals sign {=}

For all other user IDs:

    Lowercase characters {a-z}     Uppercase characters {A-Z}     Numbers {0-9}     Exclamation point {!}     Open parenthesis {(}     Close parenthesis {)}     Dash {-}; this character is not supported as the first character in the user ID or password     Period {.}; this character is not supported as the first character in the user ID or password     Question mark {?}     Open bracket {[}     Close bracket {]}     Underscore {_}; this is the only supported special character in IBM i     Grave accent {`}     Tilde {~}     Commercial at {@} Number sign {#} Dollar sign {$} Circumflex accent {^} Ampersand {&} Asterisk {*} Plus sign {+} Equals sign {=}

Diacritics, such as the umlaut, and DBCS characters are not allowed.

Other restrictions: The password cannot contain spaces; for example, pass word.

Passwords cannot be longer than 128 characters.

Avoid trouble: Login or ConfigEngine tasks might fail if the password contains any unsupported characters, including DBCS characters. This action happens even if a user is successfully enrolled using a password containing DBCS characters.

If you enter any unsupported characters during the installation, you will receive an error message that states which character is invalid. For example, The special character [@] was found in the password field. Password again.

First Name All characters n/a
Last Name All characters n/a



Access control

When authenticating a user for BPM, it is important for security purposes that access to all operations is not automatically be granted to that user. Allowing some users to perform certain operations, while denying access to those same operations for other users, is termed access control.

Access control can be arranged for components that you develop to make them secure. You provide access control for components by using service component architecture qualifiers at development time.

Some IBM Business Process Manager components, packaged as enterprise archive (EAR) files, secure their operation using Java EE role-based security. In contrast to code-based security, which secures the operation of components, role-based access control secures resources. For example, in the Business Calendars widget, you can specify the type of access that users have to individual timetables.


Security Roles widget

Use the Security Roles widget in Business Space to specify, for each timetable, the owner of the timetable as well as those who have writer and reader access to the timetable.

The following table shows the administrative roles and their default permissions:

Roles Default permission
BPMAdmin Primary administrative user
BPMRoleManager All authenticated users


EAR files and associated roles

The Business Process Choreographer and the Common Event Infrastructure are installed as part of IBM Business Process Manager.

EAR files and associated roles in BPM

Name of .ear file Role Default
BPEContainer_nodeName_serverName.ear

OR

BPEContainer_clusterName

APIUser All Authenticated
SystemAdministrator None
SystemMonitor None
JMSAPIUser All Authenticated
AdminJobUser All Authenticated
JAXWSAPIUser Everyone
BPCExplorer_nodeName_serverName.ear

OR

BPCExplorer_clusterName

WebClientUser All Authenticated
BPCArchiveExplorer_nodeName_serverName.ear

OR

BPCArchiveExplorer_clusterName

WebClientUser All Authenticated
BSpaceEAR_nodeName_server.ear businessspaceusers All Authenticated
BSpaceForms_nodeName_server.ear WebFormUsers All Authenticated
BusinessRulesManager.ear BusinessRuleUsers All Authenticated
NoOne None
AnyOne Everyone
BusinessRules_nodeName_server.ear Administrator All Authenticated
EventService.ear eventAdministrator All Authenticated
eventConsumer All Authenticated
eventUpdater All Authenticated
eventCreator All Authenticated
catalogAdministrator All Authenticated
catalogReader All Authenticated
mm.was_nodeName_server.ear All Authenticated All Authenticated
everyone Everyone
REST Services Gateway.ear RestServicesUser All Authenticated
REST Services Gateway Dmgr .ear RestServicesUser All Authenticated
TaskContainer_nodeNameserverName.ear

OR

TaskContainer_clusterName

APIUser All Authenticated
SystemAdministrator None
SystemMonitor None
EscalationUser All Authenticated
AdminJobUser All Authenticated
JAXWSAPIUser Everyone
wpsFEMgr_7.0.0 Security WBIOperator Everyone


Business Process Choreographer Java EE roles

The following table lists Business Process Choreographer Java EE roles:

Business Process Choreographer roles

Component Roles Value
BPEContainer BPEAPIUser All authenticated users
BPESystemAdministrator User names, group names, or both, entered during configuration
BPESystemMonitor All authenticated users
JMSAPIUser User name entered during configuration
AdminJobUser User name entered during configuration
JAXWSAPIUser Everyone
TaskContainer TaskAPIUser All authenticated users
TaskSystemAdministrator SystemAdministrator
TaskSystemMonitor SystemMonitor
EscalationUser EscalationUser
AdminJobUser AdminJobUser
JAXWSAPIUser Everyone

RunAs roles

In addition, applications make use of securityIdentity or RunAs roles as follows:

The.ear files and associated RunAs roles

.ear file Java EE Role
BPEContainer_nodeNameserverName.ear JMSAPIUser

AdminJobUser

TaskContainer_nodeNameserverName.ear EscalationUser

AdminJobUser



Related concepts:

Securing access to timetables in the Business Calendars widget

Administrative security roles


Access control in business process and human task applications

Business Process Choreographer, which is installed as part of the BPM installation, uses roles to determine the capabilities of the user on a production system.

The Business Process Choreographer roles are shown in Table 1.

Roles and default permissions

Roles Default permission Notes
System Administrator User names, group names, or both, entered during configuration Has access to all business processes and all operations.
System Monitor All authenticated users Has access to read operations.
JMSAPIUser User name entered during configuration All Business Process Choreographer JMS APIs are run on behalf of this single user ID.
EscalationUser User name entered during configuration Used by the human task manager to process asynchronous API calls.
AdminJobUser User name entered during configuration

The user supplied must be a member of the Business Process Choreographer System Administrator role.

Administrative jobs ( the cleanup service or business process instance migration) are run on behalf of this single user ID.

The WebClientUser role, which is associated with the Bpcexlorer.ear file, can access the Business Process Choreographer Explorer. The default permission for this role is All Authenticated.


Authorization roles for business processes

Authorization roles for human tasks


Data integrity and privacy

The privacy and integrity of data when IBM Business Process Manager processes are invoked is critical to maintaining security.

Data privacy and data integrity are closely related concepts. For a more detailed discussion, refer to the WebSphere Application Server Network Deployment Information Center.


Privacy

Privacy means that an unauthorized user should not be able to intercept and read data.


Integrity

Integrity means that an unauthorized user should not be able to alter data.


Data integrity and privacy solutions provided in BPM

IBM Business Process Manager supports two widely-used solutions for data privacy and integrity:

In a business integration environment with multiple systems interacting with one another, it is likely that some of the communication will be asynchronous. Therefore, in most instances, WS-Security may be a more suitable solution.


Configure a web services web client to use SSL

You can configure a web services client to invoke a web service using SSL.

The details of how to configure your web services web client to use SSL are provided in this WebSphere Application Server technote. A more general discussion of securing web services can be found in the WebSphere Application Server topic Securing applications at the transport level for Web services .


Security planning overview

Editing module deployment properties


Single sign-on

When a single sign-on is used, a client is asked to provide the user name and password information only once. The provided identity then propagates throughout the system.

Single sign-on using Tivoli Access Manager WebSEAL is supported for Process Portal, and for Business Space only.

For more information about integrating with third-party authentication products, see Configure third-party authentication products.

Single sign-on from Windows to BPM ( to Process Portal) can be achieved using SPNEGO. For more information about single sign-on, refer to Create a single sign-on for HTTP requests using SPNEGO Web authentication.


Create a single sign-on for HTTP requests using SPNEGO Web authentication


Considerations for securing adapters in BPM Advanced

An adapter is the mechanism used by an application to communicate with an Enterprise Information System (EIS). The information exchanged between an application and an EIS can be highly sensitive and therefore important to ensure the security of this information transaction. Two types of adapters are supported in BPM Advanced: WebSphere Business Integration Adapters and WebSphere Adapters. The security of both types of adapters is discussed in the following topics:



Considerations for securing WebSphere Business Integration Adapters

When working with WebSphere Business Integration Adapters, there are a number of considerations for administering application security.

The following list provides security considerations when working with WebSphere Business Integration Adapters:



Considerations for securing WebSphere Adapters

When working with WebSphere Adapters, there are a number of considerations for administering application security.

The following list provides security considerations when working with WebSphere Adapters:



Create end-to-end security

There are a number of potential end-to-end security scenarios for BPM Advanced, each involving differing security steps. Several typical scenarios, with the necessary security options, are presented in this topic.

These scenarios all assume that administrative security is enforced.

  1. Determine which of the examples provided in this section most closely match your security needs. In some instances, your needs might involve a combination of information from more than one of the scenarios.
  2. Read the security information for the relevant scenarios and apply it to your security needs.


Example

The following examples illustrate common scenarios.

Example: Classic integration scenario (inbound and outbound adapters)

An inbound request comes in from a WebSphere Business Integration Adapter. The Service Component Architecture (SCA) invokes an interface map based on the SCA export. The request flows through a process component and a second interface map and is then passed on to a second EIS (B), by way of a WebSphere Adapter. These are SCA invocations, with one component invoking a method on the next component.

There is no authentication mechanism for the inbound adapter. You can establish the security context by defining the SecurityIdentity qualifier on the first component (in this instance, the first interface map component). From that point, SCA will propagate the security context from each component to the next. Access control for each component is defined by use of the SecurityPermission qualifier.

Example: Inbound web service request

In this scenario, a web service client invokes a component in BPM. The request passes through several components in the BPM environment before being passed to an EIS by an adapter.

You can authenticate the web service client as an SSL client, using HTTP Basic authentication or using WS-Security authentication. When the client is authenticated, access control is applied based on the SecurityPermission qualifier. Between the client and the BPM instance, you can secure the data integrity and privacy using SSL or WS-Security. SSL secures the entire pipe, whereas with WS-Security, you can encrypt or digitally sign parts of the SOAP message. For web services, WS-Security is the preferred standard.

Example: Outbound web service request

In this scenario, the inbound request can be from an adapter, a web service client, or an HTTP client. A component in BPM (for example a BPEL component) invokes an external web service.

As for the inbound web service request, you can authenticate with the external web service as an SSL client, using HTTP Basic authentication or using WS-Security authentication. Use LTPACallBackHandler as the callback mechanism to extract the usernameToken from the current RunAs subject. Between IBM Business Process Manager and the target web service, you can ensure data privacy and integrity using WS-Security.



IBM Business Process Manager security roles

A IBM Business Process Manager role maps to an authentication alias for a user ID that is authorized to access applications that run in BPM.

The authentication alias contains a user ID, password, and a description.

You specify the authentication alias values using one of the following methods:

To update the role to an authentication alias mapping:

  1. Log in to the administrative console.

  2. Click Servers > Deployment Environments > Deployment Environment Name > Related Items > Authentication Aliases.

The following roles require additional steps when updating the role to an authentication alias mapping:

To make changes to the authentication alias, see Modify authentication aliases.

Table 1 lists the required roles for BPM. You must provide the values for these roles during installation and configuration. Any additional software installed on the Process Server might have additional roles.

Required roles

IBM Business Process Manager Required roles Description
CellAdmin

This role maps to an authentication alias that contains the cell administrator user, which is the primary administrator at the WebSphere Application Server level. The cell administrator user:

  • Has authorization in all deployment environments
  • Can assign other administrator roles
  • Is responsible for the administration of the cell and topology
  • Has access to all interfaces, enabling users to alter or delete all types of available library items and assets, including process applications and toolkits

  • Enables administration of Process Servers, Performance Data Warehouses, and internal users and groups

The following characters are supported when specifying the cell administrator user name and password during initial configuration:

LDAP determines whether to restrict or not restrict characters in usernames and passwords when using the LDAP security provider.

  • User name characters: a-zA-Z0-9!()-._`˜
  • Password characters: a-zA-Z0-9!()-.?[]_`˜

DeAdmin

This role maps to an authentication alias that contains the deployment environment administrator user, which is the primary administrator at the BPM level. This user must be a member of the tw_admins group and must be added to the administrator, deployer, and operator roles in WebSphere Application Server.

The deployment environment administrator user:

  • Has authorization in their assigned deployment environments
  • Has administrative access to Process Center and Process Admin Console
  • Has access to all interfaces, enabling users to alter or delete all types of available library items and assets, including process applications and toolkits
  • Is authorized to administer Process Servers, Performance Data Warehouses, and internal users and groups

The following characters are supported when specifying the deployment environment administrator user name and password:

  • User name characters: a-zA-Z0-9!()-._`˜
  • Password characters: a-zA-Z0-9!()-.?[]_`˜

DbUser

This role maps to an authentication alias for a user that has been granted permission to access the specified database.

DbUserXAR

This role maps to an authentication alias for a user that has been granted permission to do XA recovery for the specified database. The authentication alias for this role can also be assigned to the DbUser role.

Table 2 lists the optional roles for BPM. If you do not specify users for the role name during installation and configuration, it is defaulted to the authentication alias that is assigned to the username specified for the deployment environment administrative account.

Optional roles

IBM Business Process Manager Optional roles Description
PerformanceDWUser This role maps to an authentication alias that requires authorization to run the Performance Data Warehouse.
ProcessServerUser This role maps to an authentication alias for a Process Server user used to authenticate with a JMS connection to access the JMS queues.
ProcessCenterUser This role maps to an authentication alias for a Process Center user who is authorized to connect from the Process Server to the Process Center. This user does not need any special permission in Process Center.
BPMAdminJobUser If you are using BPM V8.5.0.1, this role maps to an authentication alias for a user that requires the authority to perform actions on the Process Admin LifeCycle (PAL) Admin task. For example, to deploy or activate a snapshot, to work with orphaned tokens, and so on. If specified, the system will execute PAL actions from the mbean of type PALService as this user.
BPMAuthor This role maps to an authentication alias for a user that requires the authority to access and deploy snapshots to the runtime Process Server and access that Process Server from the Process Inspector, which is located in Process Designer. When using Process Inspector in Process Designer to connect to an online Process Server, the authentication alias that maps to this role must be defined in both the Process Server and the Process Center, and the passwords must be the same. This authentication alias will also be used when Process Center connects to Process Server for online deployment.
BPMUser This role maps to the BPC_Auth_Alias authentication alias.
BPMWebserviceUser This role maps to the authentication alias for the Anyonymous Webservice User. Web Services exposed by IBM Business Process Manager Standard process applications can be called by unauthenticated users. The code is executed as BPMWebserviceUser. It is referred to as the guest user in the code.
EventManagerUser This role maps to an authentication alias for a user used as the run-as user for the Event Manager.
RALUser This role maps to the authentication alias for the Remote Artifact Loader (RAL) users. user. The RALUser role is defined at the cell level must be modified using the wsadmin AdminConfig commands. See Commands for the AdminConfig object using wsadmin scripting.
SCADeploymentUser This role maps to an authentication alias for a user that has authorization to deploy SCA applications.
SCAUser This role maps to an authentication alias for a user that has SCA authorization to login to a secured SIBus.
CEIDbUser This role maps to the Derby authentication alias for the Common Event Infrastructure.
CEIUser This role maps to the authentication alias for the user that has authorization to administer the Common Event Infrastructure JMS topics and queues.
BPCUser This role maps to the Business Process Choreographer JMS authentication alias.
EmbeddedECMTechnicalUser When IBM Business Process Manager interacts with IBM IBM Business Process Manager Document Store, all invocations occur as the technical user specified for this role. This user must be authorized to work with the IBM IBM Business Process Manager Document Store using the maintainDocumentStoreAuthorization command.

Table 3 lists the groups that are included by default.

Default groups

Default group Description
tw_admins Members of this group have full access to all interfaces, assets, servers, and security.

You can rename this group, but there must always be an administrator group defined. Administration of BPM is not possible without this group.

tw_allusers This group is the default lane assignment for non-system lanes when creating business process definitions (BPDs) in Process Designer in the Process Designer. The dashboards that you create in Process Designer are available to this group by default.
tw_allusers_managers This group contains the team of managers for the tw_allusers group. In the Team Performance dashboard in Process Portal, members of this group can see dashboard for the All Users team and the sample teams that are delivered with BPM.

By default, the tw_allusers_managers group includes the tw_admins group.

tw_authors Members of this group have access to the Designer and other interfaces in the Process Designer, including the Process Center console. From the Process Center console, members of this group can process applications and toolkits and control access to projects. Access to other process applications and toolkits (projects) and the assets they contain is controlled by Process Center repository administrators.
Debug You can use this account to restrict access to service debugging in the Inspector in the Process Designer.
tw_eventmanager Members of this group have full access to historical information about Event Manager processing.
tw_managers Members of this group can see the Team Performance dashboard in Process Portal. To see dashboards for individual teams, the group member must also be a member of a managers team defined in Process Designer.

By default, the tw_managers group includes the tw_allusers group.

tw_portal_admins Because of functionality changes in BPM V8, members of this group no longer have any special access rights.
tw_process_owners Members of this group can see the Process Performance dashboard. By default, this group is also assigned to the ACTION_CHANGE_CRITICAL_PATH Process Portal policy, which allows members to view and change the projected path of a process instance.

By default, the tw_process_owners group includes the tw_admins group.


Default users and authentication aliases removed from {!} V8.5

Authentication Alias


Business Process Choreographer roles

Business processes have predefined roles which can be modified using the administrative console.

Table 1 describes the roles created for business processes.

Roles associated with business processes.

RunAs role Description Information
User-defined JMSAPIUser role Used by the BFM JMS API MDB in bpecontainer.ear. Enter user name assigned to the User-defined JMSAPIUser role on the Business Process Choreographer configuration page of PMT.Enter user name assigned to the User-defined JMSAPIUser role in the applicable Business Process Choreographer properties in the response file.
User-defefined EscalationUser role Used by the task.ear MDB. Enter user name assigned to the User-defefined EscalationUser role on the Business Process Choreographer configuration page of PMT.Enter user name assigned to the User-defefined EscalationUser role in the applicable Business Process Choreographer properties in the response file.



Common Event Infrastructure roles (deprecated)

The Common Event Infrastructure has predefined roles which can be modified using the administrative console.

The roles in Table 1 are used to invoke the components regardless of the identity of the invoking user.

Roles associated with the Common Event Infrastructure.

Roles Description Information
User-defined CommonEventInfrastructure role Used to authenticate with the messaging engine. Enter user name assigned to the User-defined CommonEventInfrastructure role on the Common Event Infrastructure configuration page of PMT.Enter user name assigned to the User-defined CommonEventInfrastructure role in the applicable Common Event Infrastructure configuration properties in the response file.
User-defined database role Used to authenticate with databases. Enter user name assigned to the User-defined database role on the Common Event Infrastructure configuration page of PMT.Enter user name assigned to the User-defined database role in the applicable Common Event Infrastructure configuration properties in the response file.



Service Component Architecture role

The Service Component Architecture (SCA) has a predefined role which can be modified using the administrative console.

The role in Table 1 is used to invoke the components regardless of the identity of the invoking user.

Role associated with SCA components

Role Description Information
SCAUser Used to authenticate with the messaging engine. Enter user name assigned to the SCAUser role on the SCA configuration page of PMT.Enter user name assigned to the SCAUser role in the applicable SCA configuration properties in the response file.



Remote Artifact Loader (RAL) role

The Remote Artifact Loader (RAL) has a predefined role which can be modified using the administrative console.

The role in Table 1 is used to invoke the components regardless of the identity of the invoking user.

Role associated with Remote Artifact Loader (RAL) users

Role Description
User-defined RALSecurity_Auth_Alias role Used to authenticate for Remote Artifact Loader (RAL) users.



Modify authentication aliases

Existing authentication aliases are modified from the administrative console or by using wsadmin AdminConfig.

Modify authentication aliases using one of the following methods

From the administrative console.

  1. Access the Business Integration Authentication Alias page.

    From the administrative console, click Security > Global Security > Java Authentication and Authorization Service > J2C authentication data.

    You can also access this page from various administrative console pages that require authentication alias information. The authentication alias configuration page is displayed.

    This page contains a list of authentication aliases, the associated component, the user ID associated with this alias, and optionally a description of the alias.

  2. Select the authentication alias to modify by clicking its name in the Alias column.

    In some cases, the Alias column might not provide a link, in which case you select the check box in the Select column corresponding to the alias to edit.

  3. Change the properties of the alias.

    On the authentication alias configuration page for the selected alias, you can modify either the alias name or the associated user ID and password. You can also modify the description of the authentication data entry.

  4. Confirm your changes.

    Click either OK or Apply. Return to the Business Integration Authentication Alias page, and click Apply to apply your changes to the master configuration.

    For a Network Deployment installation, make sure that a file synchronize operation is performed to propagate the changes to other nodes.



Related tasks:

Enable security for additional components


Manage IBM Business Process Manager users, groups, and teams

IBM Business Process Manager uses the WebSphere Application Server file registry, which you can use to create and maintain BPM users and groups as outlined in the following sections.

You can also use the WebSphere Application Server file registry with an external security provider (such as LDAP with Microsoft Active Directory) that you registered with the BPM embedded application server.

The WebSphere Application Server file registry includes several default users and groups.

When use the WebSphere Application Server file registry with an external provider, the users, and groups from both providers are available for selection from BPM Standard components.

Teams are used to define groups of users who can perform tasks. A team can be either defined as a static list of users and groups, or it can be defined dynamically by a team retrieval 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.

The following table describes where these user accounts and teams are made available in BPM:

Task Interface To learn more
Grant access to the repository Process Center Console See Manage access to the Process Center repository.
Binding users to teams during process development Designer in Process Designer See Create a team.
Defining who has managerial authority over a team Designer in Process Designer See Defining team managers.
Use services to define dynamic teams Designer in Process Designer See Use services to define dynamic teams.
Assigning an activity to a team Designer in Process Designer See Assigning activities.
Add users and groups from an external provider to BPM security groups Process Admin Console See Create and managing groups.
Modify existing teams at run time Process Admin Console See Configure runtime teams.

BPM does not lock user accounts after a configurable number of failed authentication attempts. Note that end user accounts are managed in a user repository (typically LDAP connected to Federated Repositories). BPM 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 has to define rules such as password lock policy. For IBM Tivoli Directory Server, you can read more about password policies at http://www.ibm.com/developerworks/tivoli/library/t-tdspp-ect/ If you are using the BPM Internal Security Provider, there is no policy for locking users after a number of failed authentication attempts.



Create and maintain users for a stand-alone server

Use the Process Admin Console to create, update and delete users for a stand-alone server in BPM Express .

Log in to the Process Admin Console.

Notes:

You cannot create a new user using the Process Admin Console if a user was created in the past with the same user name. Once a user has been created using the Process Admin Console, it is kept in the BPM system. Even if the user is subsequently deleted, the user entry is not removed from the BPM DB and the internal authorization system.

Specify unique user IDs for every user in the following groups:

Restriction: A user name cannot have more than 64 characters.



Create and maintain users for a network deployment environment server

Use the Process Admin Console to create and configure user accounts for a deployment environment server. A deployment environment is an environment in which server processes, which are typically on different physical computer systems, are managed together.

During installation and profile creation on a deployment environment server, a file-based federated user repository is configured as the active user registry. You can change the default user repository by using the administrative console, or in the case of the Tivoli Access Manager, by configuring the repository with the wsadmin command.

Restriction: A user name cannot have more than 64 characters.

Restriction: Specify unique user IDs for every user in the following groups:

The procedure for creating and configuring user accounts in a network deployment environment varies according to the type of user registry that is implemented, and whether the deployment uses an external security provider.

In the Server Admin area of the Process Admin Console, the User Management section in the User Management window displays only internal users, that is, users that exist in the file registry part of VMM.



Change the deployment environment administrator

You can change to a new deployment environment administrator in BPM.

Log in to the WebSphere administrative console as the administrative user corresponding to the BPM CellAdmin security role specified as the default administrative account during installation.

  1. Create a new WebSphere Application Server user if you do not already have one configured in the user repository. For example, the LDAP user repository.

  2. In the Server Admin area of the Process Admin Console, click User Management > User synchronization > Add and enter the new user ID. Click Synchronize.
  3. Assign the new user to the WebSphere Application Server operator, deployer, and administrator roles. See Authorizing access to administrative roles in the WebSphere Application Server Information Center.

  4. Add the user to the bus connector role. See Add users and groups in the bus connector role.
  5. Change the alias mapped to the BPM DeAdmin security role to use the new user. See IBM Business Process Manager security roles.

  6. Add the user to the administrators group, by default, tw_admins. See Create and managing groups.

  7. Restart the deployment environment.



Enable users to manage other users

A user must be authorized to manage other users in BPM.

You can enable a user to add, delete, or modify other users in BPM using one of the following methods:

IBM Business Process Manager recommends using the second method shown below.

Assigning the user to the IdMgrWriter role.

  1. Add the user to the tw_admins group in the Process Admin Console. See, Create and managing groups.

  2. Run the following command using the wsadmin tool.

    The command cannot be run in local mode.

    INSTALL_HOME\AppServer\bin>wsadmin
    WASX7209I: Connected to process "dmgr" on node Dmgr using SOAP connector;  The t
    ype of process is: DeploymentManager
    WASX7029I: For help, enter: "$Help help"
    wsadmin>$AdminTask mapIdMgrUserToRole {-roleName IdMgrWriter -userId uid=tes_user,o=defaultWIMFileBasedRealm}
    CWWIM5099I Command completed successfully.
    wsadmin>$AdminConfig save 


Refer to http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rxml_atidmgrconfig.html for more information on the WebSphere Application Server IdMgrWriter role.



Related tasks:

Configure a user account repository


Create and managing groups

If you have configured IBM Business Process Manager to work with an external security provider, you can view the groups from that external provider in the Process Admin Console, but you cannot edit the external groups. You can, however, add users and groups from your external provider to any BPM security groups that you create. You can also combine accounts from different providers into one group.

Log in to the Process Admin Console.

To create and maintain groups, log in as an administrative user, such as the default administrative user account, or an account that you added during installation that has administrator privileges. If you added a new administrative user, the user is added to the tw_admins user group. Members in the administrators group, by default, tw_admins can administer Process Servers, Performance Data Warehouses, and internal users and groups.

To return a list of members of a nested group for an LDAP repository:

  1. Run the following command:

      $AdminTask setIdMgrCustomProperty { -id Ldap Repository Id -name com.ibm.ws.wim.adapter.ldap.returnNestedNonGroupMembers -value true}

    For example:

      wsadmin>$AdminTask setIdMgrCustomProperty { -id LDAP1 -name com.ibm.ws.wim.adapt er.ldap.returnNestedNonGroupMembers -value true}

    Save the changes and exit.

      wsadmin>$AdminConfig save wsadmin> exit

  2. Restart the server.

The default installation of IBM Business Process Manager provides a federated repository that contains the WebSphere Application Server file registry. To implement an external security provider, which uses a different user registry than the WebSphere Application Server file registry, add the provider to the federated repository. Several types of repositories are supported, including the local operating system registry, a standalone LDAP registry, a standalone custom registry, and federated repositories.

See the related links at the bottom of this topic for more information about registries and external security providers.

Groups created in BPM cannot be edited in WebSphere Application Server and groups created in WebSphere Application Server cannot be edited in BPM.

Security considerations for BPM


Selecting a registry or repository

Configure local operating system registries

Configure Lightweight Directory Access Protocol user registries

Configure standalone custom registries

Configure external security providers


Synchronizing external users and groups

If you have configured IBM Business Process Manager to work with an external security provider, you can use the Process Admin Console to synchronize external users and groups.

IBM Business Process Manager synchronizes external users and groups based on the following triggers:

The following commands, which are located in the install_root\IBM BPM\Lombardi\tools\security directory, can be executed to do this synchronization administratively, which prevents user logins from slowing down while the BPM database content is being updated.

groupMembershipFullUpdate -username [options] -dynamicGroupUpdate [required value]

Updates the LDAP group membership of all users that are known to IBM Business Process Manager. At the end of the group membership update, dynamic groups are updated once. Specify one of the following values for the -dynamicGroupUpdate parameter:

  • never to stop dynamic group updates.
  • always to enforce dynamic group updates.

Omitting this option or specifying default or any other value will result in updates to dynamic groups only if a group membership change was detected.

groupMembershipUpdate -username [options] userID1 userID2 ...userIDn -dynamicGroupUpdate [required value]

Updates the LDAP group membership of the user or users specified with this command. If a specified user ID is unknown to IBM Business Process Manager, this user is created within BPM. At the end of the group membership update, dynamic groups are updated once. Specify one of the following values for the -dynamicGroupUpdate parameter:

  • never to stop dynamic group updates.
  • always to enforce dynamic group updates.

Omitting this option or specifying default or any other value will result in updates to dynamic groups only if a group membership change was detected.

usersFullSync [options]

Synchronizes all users available from LDAP. No group membership is updated. This admin task is equivalent to the Full Synchronize command in the Process Admin Console.

usersSync [options]userID1 userID2 ...userIDn

Synchronizes the specified user or users from LDAP. No group membership is updated. This admin task is equivalent to the Synchronize command in the Process Admin Console.

Each command has the following options:

-username

The name of the user

-password

The password of the user

-host

The server host name

-port

The server SOAP port number



Configure Web Inspector to work with Portal Admin Teams

You can configure Web Inspector to work with Portal Admin Teams that contain users or groups that have permission to view and administer process instances.

  1. Open the 100Custom.xml configuration file. Refer to The 99Local.xml and 100Custom.xml configuration files for the correct file locations that are based on the environment type.

  2. Add the following lines:
    <server>
            <process-inspector merge="mergeChildren">
                <use-administer-interaction-filter merge="replace">true</use-administer-interaction-filter>
            </process-inspector>
        </server>

  3. Verify 100Custom.xml changes by opening the TeamWorksConfiguration.running.xml file, which is in:

    • Stand-alone environment

        BPM_HOME\profiles\stand-alone_profile_name\config\cells\cell name\nodes\node name\servers\server_name\process-center

    • Clustered environment

        BPM_HOME\profiles\dmgr_profile_name\config\cells\cell name\clusters\cluster_name\process-center

  4. Optional: Enable logging for Web Inspector requests to confirm the interactionFilter=ADMINISTER parameter is set.

    1. From the administrative console, go to Troubleshooting > Logs and trace.

    2. Click the Server name of the server to enable logging and tracing.

    3. Click Diagnostic Trace in the General Properties section.

    4. In the Additional Properties section, click Change log detail levels.

    5. In the Change log detail levels field, append com.ibm.processinspector.*=all to existing content separated by : a colon.

    6. Click Apply.

    7. Click OK.

    View the log file, located at BPM_HOME\profiles\profile_name\logs, to confirm the returned code contains the interactionFilter=ADMINISTER parameter. For example:

      [8/9/13 14:09:29:685 EDT] 0000013a ProcessAdminR 3 url = http://bobs-vm.canlab.ibm.com:9080/rest/bpm/wle/v1/processes/query/IBM.PI_PROCESSLIST_ALL?queryFilter=(PI_MODIFY%20%3E%20TS('2013-08-09T00:00:00')%20)&includeTaskData=true&interactionFilter=ADMINISTER&offset=0&size=20&sortAttributes=PI_MODIFY+DESC:com.ibm.processinspector.*=all

  5. Create the Portal Admin Team:

    1. From the Process App Settings editor in Process Designer, select the Overview tab, and expand Authorization Settings.

    2. Click New.

    3. In the New Team panel, input the new team name and click Finish.

    4. Expand Members and click Add user or Add group.

    5. Select a user or group name. You can also locate the user or group name by starting to type the name.

  6. Click Save.



Assigning user attributes

In the Designer in Process Designer, you can user attribute definitions to associate unique capabilities or qualities with one or more users. The Process Admin Console enables you to assign existing user attributes to multiple users simultaneously This procedure triggers dynamic group creation, which can be time consuming. You can configure IBM Business Process Manager to deactivate these triggers. See Deactivating dynamic group updates.

You can assign user attributes as described in the following procedures.

  1. Go to Start > Programs > IBM > Business Process Manager Advanced 8.0 > Profiles > Profile name > Process Admin Console.

  2. In the Server Admin area of the Process Admin Console, click the indicator next to User Management to list the available management options.

  3. Click the Bulk User Attribute Assignment option.

  4. Click either the View by Attribute or View by User option.



If you select View by Attribute

  1. In the Select an Attribute list, click the attribute that you want. The Process Admin Console displays all user attribute definitions that exist in the Process Center repository, including the default definitions from the System Data toolkit.

  2. Under Select Users, do one of the following:

    • In the User field, type the first few letters of the user names that you want and click Search.

    • In the Team field, type the first few letters of the team that contains the users that you want and click Search.

  3. In the User column, click the check box next to each user to whom you want to assign a user attribute value.

  4. From the Value drop-down list, select the user attribute value to assign and click Assign. If the user attribute has no assigned values, you can type an appropriate value in the Value field and click Assign.

    When you assign an attribute value to a user, that value is displayed under Current Attribute Value .



If you select View by User

  1. Under Select a User in the User Filter field, type the first few letters of the user name that you want and click Retrieve.

  2. From the list of retrieved users, click the user to whom you want to assign an attribute value. Under Assign Attribute Values, the console displays the user ID, user name, and full name.

    Under Custom Attributes, the console displays each User Attribute for which you can assign a value to the selected user.

  3. Change a current value by typing the new value in the field and pressing the Enter key or by using a drop-down list to select a new value.
  4. Supply a new value for a Custom Attribute by typing in the value and pressing the Enter key.



Change IBM Business Process Manager and database passwords

You can change the BPM and database passwords after completing the installation and configuration.



Change IBM Business Process Manager passwords

When the password of the user defined in the file registry or external security provider is changed and the user ID is used by IBM Business Process Manager authentication aliases or RunAs roles of IBM Business Process Manager applications, the password must be synchronized. The updateBPMAliasesAndRunAsRolesPasswords command enables this synchronization in one step.

IBM Business Process Manager provides the following applications that contain users mapped to the RunAs roles:

Where the suffix is either the application cluster or the stand-alone server (for BPM Express and IBM Integration Designer's Unit Test Environment (UTE)), and the support cluster or stand-alone server: _clusterName or _nodeName_serverName.

The updateBPMAliasesAndRunAsRolesPasswords command cannot be used to change passwords for cell admin users or customer-supplied applications.

You must change the passwords at both the provider level and for the authentication aliases mapped to the RunAs roles for applications provided by IBM Business Process Manager.

  1. Go to the external security provider and change the password for the user at the provider level. The following steps use WebSphere Application Server as the provider:

    1. Change the password in the WebSphere Application Server file registry by logging into the WebSphere Application Server admin console.

    2. Click Users and Groups > Manage Users.

    3. Select the user and enter the new password in the Password field.

    4. Click Apply and then click OK.

      Save the changes.

  2. In an ND environment, stop the deployment manager. (In a stand-alone environment like BPM Express or the IBM Integration Designer unit test environment, stop the app server.)

  3. In the deployment manager profile bin folder (or in the AppServer profile bin folder for BPM Express or the Integration Designer unit test environment), run the updateBPMAliasesAndRunAsRolesPasswords wsadmin command to change the password in the authentication alias and RunAs role for the applications.

    • For Jacl
      dmgr_profile_root/bin > wsadmin -conntype NONE
      wsadmin> $AdminTask updateBPMAliasesAndRunAsRolesPasswords {-userName username -password new_password}
      
      You should see the following messages:
      
      Processing: IBM_BPM_PerformanceDW_SingleCluster
      Processing: IBM_BPM_Teamworks_SingleCluster
      Processing: BPEContainer_SingleCluster
      Processing: TaskContainer_SingleCluster
      
      wsadmin> $AdminConfig save 

    • For Jython
      dmgr_profile_root/bin>wsadmin -conntype NONE -lang jython
      wsadmin>AdminTask.updateBPMAliasesAndRunAsRolesPasswords('[-userName username -password new_password]')
      Processing: IBM_BPM_PerformanceDW_SingleCluster
      Processing: IBM_BPM_Teamworks_SingleCluster
      Processing: BPEContainer_SingleCluster
      Processing: TaskContainer_SingleCluster
      
      wsadmin>AdminConfig.save()

  4. In an ND environment, start the deployment manager and synchronize your changes on the other nodes. (In a stand-alone environment like BPM Express or the IBM Integration Designer unit test environment, start the app server.)
  5. In an ND environment, restart the application cluster members and support cluster members.



Related tasks:

Defining RunAs roles user assignments for system applications


Defining RunAs roles user assignments for system applications

The bpmModifyMapRunAsRole script provides a way to define the RunAs roles user assignments for the system applications that are shipped with the BPM product. IBM Business Process Manager provides the following applications that contain users mapped to the RunAs roles:

Where the suffix is either the application cluster or the stand-alone server (for BPM Express and IBM Integration Designer's Unit Test Environment (UTE)), and the support cluster or stand-alone server: _clusterName or _nodeName_serverName.

For more information on RunAs roles, see Assigning users to RunAs.

The bpmModifyMapRunAsRole script is used to update the IBM_BPM_Teamworks*.ear and IBM_BPM_PerformanceDW*.ear applications. It does not update other BPM applications.

To define the RunAs roles user assignments, run the bpmModifyMapRunAsRole script, which is located at install_root/util/Security/bpmModifyMapRunAsRole.py.



Related tasks:

Change IBM Business Process Manager passwords


Change database passwords

You can change the database password, as needed, once the database configuration is completed.

After you have finished configuring the database, you can change the database password using the administrative console.

To change the database password, perform the following tasks:

Before you make any configuration changes, it is suggested that you back up the config folder. The config folder is located beneath the Deployment Manager at <Dmgr-profile>/config. Contact your WebSphere Application Server administrator for more information.


Update the data source authentication alias

You need to update the data source authentication alias before you change a database password.

Make sure you do all the following items before you begin this procedure.

To change the data source authentication alias:

  1. Login to the administrative console.

  2. Select Resources > JDBC > Data sources.

    Make sure you write down the values that are configured for Component-managed authentication alias and Authentication alias for XA recovery.

  3. Select the datasource.

  4. Select the Related Items section and then select JAAS - J2C authentication data.

  5. Select the appropriate Component-managed authentication alias value noted in step 2. Edit the password, and then click OK to save the change.
  6. Go back to the JAAS - J2C authentication data panel and select the Authentication alias for XA recovery value noted in step 2. Edit the password, and then click OK to save the change.

    Save the updates and click Full Synchronize to synchronize the information to all the nodes.



Related tasks:

Update the messaging engine data store authentication alias


Update the messaging engine data store authentication alias

You must update the messaging engine data store authentication alias before you change the database password.

Make sure you complete all of the following items before you begin this procedure.

To change the messaging engine data store authentication alias:

  1. Login to the administrative console.

  2. Select Service Integration > Buses.
  3. To update the authentication alias for each bus:

    1. Select Buses > [Bus_NAME] > Messaging Engines > [MESSAGING_ENGINE] > Data Store .

      Remember: Make sure you write down and save the Authentication Alias value in the Data Store.

    2. Select the Related Items section and click JAAS - J2C authentication data.

    3. Select the value noted in step a. Edit the password, and then click OK to save the change.

      Save the updates and click Full Synchronize to synchronize the information to all the nodes.



Related tasks:

Update the data source authentication alias


Configure external security providers

To use an external security provider, add the provider to the federated repository. Several types of repositories are supported, including the local operating system registry, a standalone LDAP registry, a standalone custom registry, and federated repositories. The default installation of IBM Business Process Manager provides a federated repository that contains the WebSphere Application Server file registry. The following steps show an example of configuring an LDAP security provider (such as Microsoft Active Directory) with the federated repository. For more information about how to configure other supported repositories, such as Tivoli Directory Server, refer to the Configure LDAP as the user account registry section of the IBM Business Process Manager V7.5 Production Topologies IBM Redbook.

IBM recommends that you configure the LDAP security provider using a federated repository (also referred to as virtual member manager).

Restriction:

  1. Log in to the WebSphere Application Server administrative console.

  2. Click Security > Global security.

  3. Under User account repository, select Federated repositories from the list of Available realm definitions.

  4. Click Configure.

  5. Under Related items, click Manage repositories.

  6. Click Add > LDAP Repository and specify parameters for the provider that to add. For example, to add Microsoft Active Directory, specify values such as the following examples:

    Parameters for adding a provider

    Parameter Example values
    Repository identifier SALOMLDAP // change to suit
    Directory type Microsoft Windows Active Directory
    Primary host name 10.1.5.18
    Bind distinguished name cn=LDAP_USER,CN=Users,DC=COMPANYQA,DC=com
    Bind password pwsaaswp

  7. Click OK and then Save.

  8. On the Federated repositories page, click Add Base entry to Realm and specify values such as the following examples:

    Parameters for adding a base entry to a realm

    Base entry name Example values
    Distinguished name of a base entry that uniquely identifies this set of entries in the realm cn=Users,DC=COMPANYQA,DC=com
    Distinguished name of a base entry in this repository cn=Users,DC=COMPANYQA,DC=com

  9. Click OK and then Save.

    If your external security provider (LDAP) contains many entries, you must increase the maximum number of search results in federated repositories. A full synchronization queries all entries in LDAP. This process is limited by the maximum search value in the wimconfig.xml. In WAS, the default maximum search results is 4500 entries. This value is not the maximum number of LDAP users or groups that WAS can handle; rather, it is the maximum number that is returned based on the configuration value in the wimconfig.xml file. Check the SystemOut.log file for the CWWIM1018E error code. If you have this issue, you can increase the maximum search results in the wimconfig.xml file as described in the MaxResultsExceededException occurs during LDAP repository search topic in the WAS Information Center. After the change, restart both the WAS and BPM servers, then complete a full synchronization.

  10. On the Global Security page, click Set as current and then click Apply.
  11. Shut down all BPM servers. For a network deployment environment, you must shut down all of the servers, node agents, and deployment manager.

  12. Make sure that no duplicate users exist in the WebSphere Application Server file registry and the security provider that you just added. If duplicate users exist, errors will occur when you run IBM Business Process Manager product components.

  13. Start all BPM servers. For a network deployment environment, you must restart all of the servers, node agents, and deployment manager.

    If you have configured a server cluster for the runtime environment, stop and restart all servers in the cluster.


Configure multiple deployment environments

You can isolate multiple deployment environments within a single cell in your IBM Business Process Manager configuration.

See Considerations for multiple deployment environments in the same cell for things to consider prior to making changes to the deployment environment.

Create unique HTTP endpoints for each deployment environment. Optionally, you can specify different security settings for each deployment environment by creating multiple security domains and attaching one security domain to each deployment environment.

Only users that are assigned to the administrator role can configure multiple security domains. For more information on multiple security domains, see Multiple security domains in the WebSphere Application Server information center.

To isolate administrative access, you can specify administrative authorization groups to grant administrative access only to the resources of a single deployment environment. Administrative authorization groups are described .at Fine-grained administrative security.

The following tabbed sections provide instructions for three different configuration scenarios that isolate multiple deployment environments within a single cell. Notice that each of these sections includes instructions for configuring dedicated virtual host aliases, which is a mandatory task. Choose the tab that best describes your intended configuration scenario.

View all | View with tabs

Isolating deployment environments

To isolate multiple deployment environments within a single cell, configure dedicated virtual host aliases. Complete the following steps:

  1. Create the deployment environments. See Create a Deployment Environment.

  2. Select one of the following methods to create unique HTTP endpoints:

    • Use a dedicated virtual host for each deployment environment. See Step 3.

    • Use dedicated context root prefixes for each deployment environment. See Step 4.

    • Use dedicated Web servers for each deployment environment. See "Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.0" or "Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.1".

  3. If you have multiple deployment environments in a single cell, and to use the same web server, create a dedicated virtual host for each deployment environment. For each deployment environment (dep_env_name) in the cell, complete the following actions. See Virtual hosts .

    1. Decide on the virtual host name, virtual_host_name.

    2. Create a dedicated virtual host. Using the administrative console, navigate to Environment > Virtual hosts and click New.

    3. Specify a name for the new virtual host. For example, vh_de1.

    4. If you are using an external HTTP server, add the HTTP server's virtual host alias. Navigate to Environment > Virtual hosts > Name of the virtual host created in previous step > Host Aliases and click New. For example, navigate to vh_de1 and click New. Then enter the host name of your HTTP server and associate it with the HTTP or HTTPS port.

    5. To create access the web container of the cluster members, add the host name of the cluster member as a host alias. Navigate to Environment > Virtual hosts > Name of the virtual host created in previous step > Host Aliases and click New. Enter the host name of the cluster member and associate it with the WC_defaulthost_secure port.

      Here is an example of the host aliases that must be added for a single cluster deployment environment that contains two members:

      Deployment environment name: de1

      Cluster name: de1.AppTarget

      Cluster member 1: de1.AppTarget.Member1

      Cluster member 2: de1.AppTarget.Member2

      Virtual host name: vh_de1

      Virtual host aliases in vh_de1:

      • To access IBM Business Process Manager over HTTPS, add the cluster member host names and WC_defaulthost_secure ports to the host alias:

        • Cluster member host name for de1.AppTarget.Member1 on the WC_defaulthost_secure port . For example 9443.
        • Cluster member host name for de1.AppTarget.Member2 on the WC_defaulthost_secure port. For example 9443.

      • To access IBM Business Process Manager over HTTP, add the WC_defaulthost ports.

        • Cluster member host name for de1.AppTarget.Member1 on the WC_defaulthost port. For example 9080.
        • Cluster member host name for de1.AppTarget.Member2 on the WC_defaulthost port. For example 9080.

      • If you use an external HTTP server, add the HTTP server's virtual host alias. This is mandatory if you are using an external HTTP server.

        • Virtual host corresponding to your HTTP server.

          For example ihs.virtual.host.for.de1.ibm.com on port 80

        • Virtual host corresponding to your HTTP server.

          For example ihs.virtual.host.for.de1.ibm.com on port 443.

    6. Map the virtual host name, virtual_host_name, to the deployment environment, dep_env_name, by running the updateVirtualHost command on the deployment manager, DmgrProfile.

        install_root/profiles/DmgrProfile/bin/updateVirtualHost.sh -d dep_env_name -v virtual_host_name -username username -password password

        install_root\profiles\DmgrProfile\bin\updateVirtualHost -d dep_env_name -v virtual_host_name -username username -password password

      Where DmgrProfile is the deployment manager profile name, username is your user name, and password is the password.

      For more information about the updateVirtualHost command, see Configure a virtual host. For information on the BPMVirtualHostInfo object, see Configure BPM endpoints to match the topology.

    7. If you are using an external HTTP server, regenerate and propagate the HTTP server plug-in.

      1. In the administrative console, navigate to Servers > Server Types > Web Servers.

      2. Select the name of your HTTP server, then click Generate Plug-in.

      3. Select the name of your HTTP server, then click Propagate Plug-in.

        The administration service must be running on your HTTP server.

  4. Configure dedicated context root prefixes for each deployment environment by running BPMConfig. For more information about BPMConfig, see BPMConfig command-line utility.

  5. Configure an endpoint for the remote artifact loader (REMOTE_AL scenario) in each deployment environment. See Configure BPM endpoints to match the topology.

Configure security domains

To configure multiple deployment environments and security domains:

  1. Create the deployment environments. See Create a Deployment Environment.

  2. Select one of the following methods to create unique HTTP endpoints:

    • Use a dedicated virtual host for each deployment environment. See Step 3.

    • Use dedicated context root prefixes for each deployment environment. See Step 4.

    • Use dedicated Web servers for each deployment environment. See "Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.0" or "Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.1".

  3. If you have multiple deployment environments in a single cell, and to use the same web server, create a dedicated virtual host for each deployment environment. For each deployment environment (dep_env_name) in the cell, complete the following actions. See Virtual hosts .

    1. Decide on the virtual host name, virtual_host_name.

    2. Create a dedicated virtual host. Using the administrative console, navigate to Environment > Virtual hosts and click New.

    3. Specify a name for the new virtual host. For example, vh_de1.

    4. If you are using an external HTTP server, add the HTTP server's virtual host alias. Navigate to Environment > Virtual hosts > Name of the virtual host created in previous step > Host Aliases and click New. For example, navigate to vh_de1 and click New. Then enter the host name of your HTTP server and associate it with the HTTP or HTTPS port.

    5. To create access the web container of the cluster members, add the host name of the cluster member as a host alias. Navigate to Environment > Virtual hosts > Name of the virtual host created in previous step > Host Aliases and click New. Enter the host name of the cluster member and associate it with the WC_defaulthost_secure port.

      Here is an example of the host aliases that must be added for a single cluster deployment environment that contains two members:

      Deployment environment name: de1

      Cluster name: de1.AppTarget

      Cluster member 1: de1.AppTarget.Member1

      Cluster member 2: de1.AppTarget.Member2

      Virtual host name: vh_de1

      Virtual host aliases in vh_de1:

      • To access IBM Business Process Manager over HTTPS, add the cluster member host names and WC_defaulthost_secure ports to the host alias:

        • Cluster member host name for de1.AppTarget.Member1 on the WC_defaulthost_secure port . For example 9443.
        • Cluster member host name for de1.AppTarget.Member2 on the WC_defaulthost_secure port. For example 9443.

      • To access IBM Business Process Manager over HTTP, add the WC_defaulthost ports.

        • Cluster member host name for de1.AppTarget.Member1 on the WC_defaulthost port. For example 9080.
        • Cluster member host name for de1.AppTarget.Member2 on the WC_defaulthost port. For example 9080.

      • If you use an external HTTP server, add the HTTP server's virtual host alias. This is mandatory if you are using an external HTTP server.

        • Virtual host corresponding to your HTTP server.

          For example ihs.virtual.host.for.de1.ibm.com on port 80

        • Virtual host corresponding to your HTTP server.

          For example ihs.virtual.host.for.de1.ibm.com on port 443.

    6. Map the virtual host name, virtual_host_name, to the deployment environment, dep_env_name, by running the updateVirtualHost command on the deployment manager, DmgrProfile.

        install_root/profiles/DmgrProfile/bin/updateVirtualHost.sh -d dep_env_name -v virtual_host_name -username username -password password

        install_root\profiles\DmgrProfile\bin\updateVirtualHost -d dep_env_name -v virtual_host_name -username username -password password

      Where DmgrProfile is the deployment manager profile name, username is your user name, and password is the password.

      For more information about the updateVirtualHost command, see Configure a virtual host. For information on the BPMVirtualHostInfo object, see Configure BPM endpoints to match the topology.

    7. If you are using an external HTTP server, regenerate and propagate the HTTP server plug-in.

      1. In the administrative console, navigate to Servers > Server Types > Web Servers.

      2. Select the name of your HTTP server, then click Generate Plug-in.

      3. Select the name of your HTTP server, then click Propagate Plug-in.

        The administration service must be running on your HTTP server.

  4. Configure dedicated context root prefixes for each deployment environment by running BPMConfig. For more information about BPMConfig, see BPMConfig command-line utility.

  5. Create and configure a dedicated security domain for each deployment environment and map each cluster and service integration bus to the dedicated security domain. See Configure multiple security domains.

    • Every cluster and service integration bus in the deployment environment must be mapped to the same security domain.

    • If you use a dedicated user registry for each security domain, the user realm name for the security domain must be unique.

    • Users that are configured for the deployment environment must exist in the user registry.

  6. To have a user from the security domain of the deployment environment in the bus connector role, you must replace the user in the bus connector role with the users from the realm of the security domain. For each user:

    1. Click Service integration > Buses > BPM.yourDE.Bus > Security > Users and groups in the bus connector role.

    2. Select the user from the global realm. For example, de1Admin and click Delete.

    3. Click New.

    4. Select Users and click Next.

    5. Select the user from the security domain realm.

  7. Click Security > Global security > Custom Properties and set the com.ibm.websphere.security.useAppContextForServletInit custom property to global security.

      com.ibm.websphere.security.useAppContextForServletInit = true

    The next steps are only required to have dedicated administrators for each deployment environment.

  8. Configure trusted authentication realms:

    1. Click Security > Global security > Configure > Trusted authentication realms - inbound.

    2. Select the realm name that is associated with the security domain and click Trusted.

  9. For each deployment environment, create a dedicated WebSphere Application Server users that are used to perform WebSphere Application Server administrative functions from either the administrative console or the wsadmin system management scripting interface. These users must be created in the global user registry as only cell scope user are allowed to run wsadmin. If you are using the file registry:

    1. Click Users and Groups > Manage Users > Create.

    2. Create four additional users for each deployment environment. For example:

      • de1WASAdministrator
      • de1WASDeployer
      • de1WASMonitor
      • de1WASOperator

    See Role-based authorization.

  10. Create a dedicated Administrative Authorization Group (AAG) for each deployment environment:

    1. Click Security > Administrative Authorization Groups > New and input a name for the AAG.

    2. Click the new AAG.

    3. Expand Clusters and select all clusters that belong to the deployment environment.

    4. Expand Business-level applications and select all business level applications that belong to the deployment environment.

    5. Expand Applications and select all applications that belong to the deployment environment.

      Do not map any nodes or node groups.

      Save and synchronize your changes.

    6. Click Administrative user roles and press Add.
    7. Assign administrative roles to users:

      • de1WASAdministrator - Administrator
      • de1WASDeployer - Deployer
      • de1WASMonitor - Monitor
      • de1WASOperator - Operator

    8. Add the de1Admin@depenv1_realm deployment environment administrator with the following privileges:

      • Operator
      • Deployer
      • Configurator
      • Monitor
      • Administrator
      • Admin Security Manager

      The security domain realm must be selected when adding the de1Admin@depenv1_realm user.

    9. You can have different user registries in an environment with multiple security domains. To perform certain Process Admin LifeCycle (PAL) administrative functions you must have a user in the security domain of the deployment environment. However, to connect to the wsadmin scripting interface or to call MBeans, the user must be in the user registry of the global security domain. The BPMADminJobUser role maps to an authentication alias for a user that requires the authority to perform actions on the Process Admin LifeCycle (PAL) Admin task. If specified, the system will execute PAL actions from the MBean of type PALService as this user. Create a J2C authentication alias for the BPMAdminJobUser role:

      1. Click Security > Global security > Java Authentication and Authorization Service > J2C authentication data.
      2. - Click New and specify an arbitrary alias name, and the deployment environment administrator user ID and password.

        You must use the password specified for the deployment environment administrator during the deployment environment creation.

    10. Map the J2C authentication alias to the BPMAdminJobUser role:

      1. Click Servers > Deployment Environment > yourDE > Authenticatin Aliases.

      2. Select the new J2C authentication alias and map it to the BPMAdminJobUser role.

  11. Configure an endpoint for the remote artifact loader (REMOTE_AL scenario) in each deployment environment. See Configure BPM endpoints to match the topology.

Configure security domains, and third-party authentication

To configure multiple deployment environments, security domains, and third-party authentication:

  1. Create the deployment environments. See Create a Deployment Environment.

  2. Select one of the following methods to create unique HTTP endpoints:

    • Use a dedicated virtual host for each deployment environment. See Step 3.

    • Use dedicated context root prefixes for each deployment environment. See Step 4.

    • Use dedicated Web servers for each deployment environment. See "Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.0" or "Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.1".

  3. If you have multiple deployment environments in a single cell, and to use the same web server, create a dedicated virtual host for each deployment environment. For each deployment environment (dep_env_name) in the cell, complete the following actions. See Virtual hosts .

    1. Decide on the virtual host name, virtual_host_name.

    2. Create a dedicated virtual host. Using the administrative console, navigate to Environment > Virtual hosts and click New.

    3. Specify a name for the new virtual host. For example, vh_de1.

    4. If you are using an external HTTP server, add the HTTP server's virtual host alias. Navigate to Environment > Virtual hosts > Name of the virtual host created in previous step > Host Aliases and click New. For example, navigate to vh_de1 and click New. Then enter the host name of your HTTP server and associate it with the HTTP or HTTPS port.

    5. To create access the web container of the cluster members, add the host name of the cluster member as a host alias. Navigate to Environment > Virtual hosts > Name of the virtual host created in previous step > Host Aliases and click New. Enter the host name of the cluster member and associate it with the WC_defaulthost_secure port.

      Here is an example of the host aliases that must be added for a single cluster deployment environment that contains two members:

      Deployment environment name: de1

      Cluster name: de1.AppTarget

      Cluster member 1: de1.AppTarget.Member1

      Cluster member 2: de1.AppTarget.Member2

      Virtual host name: vh_de1

      Virtual host aliases in vh_de1:

      • To access IBM Business Process Manager over HTTPS, add the cluster member host names and WC_defaulthost_secure ports to the host alias:

        • Cluster member host name for de1.AppTarget.Member1 on the WC_defaulthost_secure port . For example 9443.
        • Cluster member host name for de1.AppTarget.Member2 on the WC_defaulthost_secure port. For example 9443.

      • To access IBM Business Process Manager over HTTP, add the WC_defaulthost ports.

        • Cluster member host name for de1.AppTarget.Member1 on the WC_defaulthost port. For example 9080.
        • Cluster member host name for de1.AppTarget.Member2 on the WC_defaulthost port. For example 9080.

      • If you use an external HTTP server, add the HTTP server's virtual host alias. This is mandatory if you are using an external HTTP server.

        • Virtual host corresponding to your HTTP server.

          For example ihs.virtual.host.for.de1.ibm.com on port 80

        • Virtual host corresponding to your HTTP server.

          For example ihs.virtual.host.for.de1.ibm.com on port 443.

    6. Map the virtual host name, virtual_host_name, to the deployment environment, dep_env_name, by running the updateVirtualHost command on the deployment manager, DmgrProfile.

        install_root/profiles/DmgrProfile/bin/updateVirtualHost.sh -d dep_env_name -v virtual_host_name -username username -password password

        install_root\profiles\DmgrProfile\bin\updateVirtualHost -d dep_env_name -v virtual_host_name -username username -password password

      Where DmgrProfile is the deployment manager profile name, username is your user name, and password is the password.

      For more information about the updateVirtualHost command, see Configure a virtual host. For information on the BPMVirtualHostInfo object, see Configure BPM endpoints to match the topology.

    7. If you are using an external HTTP server, regenerate and propagate the HTTP server plug-in.

      1. In the administrative console, navigate to Servers > Server Types > Web Servers.

      2. Select the name of your HTTP server, then click Generate Plug-in.

      3. Select the name of your HTTP server, then click Propagate Plug-in.

        The administration service must be running on your HTTP server.

  4. Configure dedicated context root prefixes for each deployment environment by running BPMConfig. For more information about BPMConfig, see BPMConfig command-line utility.

  5. Create and configure a dedicated security domain for each deployment environment and map each cluster and service integration bus to the dedicated security domain. See Configure multiple security domains.

    • Every cluster and service integration bus in the deployment environment must be mapped to the same security domain.

    • If you use a dedicated user registry for each security domain, the user realm name for the security domain must be unique.

    • Users that are configured for the deployment environment must exist in the user registry.

  6. To have a user from the security domain of the deployment environment in the bus connector role, you must replace the user in the bus connector role with the users from the realm of the security domain. For each user:

    1. Click Service integration > Buses > BPM.yourDE.Bus > Security > Users and groups in the bus connector role.

    2. Select the user from the global realm. For example, de1Admin and click Delete.

    3. Click New.

    4. Select Users and click Next.

    5. Select the user from the security domain realm.

  7. Click Security > Global security > Custom Properties and set the com.ibm.websphere.security.useAppContextForServletInit custom property to global security.

      com.ibm.websphere.security.useAppContextForServletInit = true

    The next steps are only required to have dedicated administrators for each deployment environment.

  8. Configure trusted authentication realms:

    1. Click Security > Global security > Configure > Trusted authentication realms - inbound.

    2. Select the realm name that is associated with the security domain and click Trusted.

  9. For each deployment environment, create a dedicated WebSphere Application Server users that are used to perform WebSphere Application Server administrative functions from either the administrative console or the wsadmin system management scripting interface. These users must be created in the global user registry as only cell scope user are allowed to run wsadmin. If you are using the file registry:

    1. Click Users and Groups > Manage Users > Create.

    2. Create four additional users for each deployment environment. For example:

      • de1WASAdministrator
      • de1WASDeployer
      • de1WASMonitor
      • de1WASOperator

    See Role-based authorization.

  10. Create a dedicated Administrative Authorization Group (AAG) for each deployment environment:

    1. Click Security > Administrative Authorization Groups > New and input a name for the AAG.

    2. Click the new AAG.

    3. Expand Clusters and select all clusters that belong to the deployment environment.

    4. Expand Business-level applications and select all business level applications that belong to the deployment environment.

    5. Expand Applications and select all applications that belong to the deployment environment.

      Do not map any nodes or node groups.

      Save and synchronize your changes.

    6. Click Administrative user roles and press Add.
    7. Assign administrative roles to users:

      • de1WASAdministrator - Administrator
      • de1WASDeployer - Deployer
      • de1WASMonitor - Monitor
      • de1WASOperator - Operator

    8. Add the de1Admin@depenv1_realm deployment environment administrator with the following privileges:

      • Operator
      • Deployer
      • Configurator
      • Monitor
      • Administrator
      • Admin Security Manager

      The security domain realm must be selected when adding the de1Admin@depenv1_realm user.

    9. You can have different user registries in an environment with multiple security domains. To perform certain Process Admin LifeCycle (PAL) administrative functions you must have a user in the security domain of the deployment environment. However, to connect to the wsadmin scripting interface or to call MBeans, the user must be in the user registry of the global security domain. The BPMADminJobUser role maps to an authentication alias for a user that requires the authority to perform actions on the Process Admin LifeCycle (PAL) Admin task. If specified, the system will execute PAL actions from the MBean of type PALService as this user. Create a J2C authentication alias for the BPMAdminJobUser role:

      1. Click Security > Global security > Java Authentication and Authorization Service > J2C authentication data.
      2. - Click New and specify an arbitrary alias name, and the deployment environment administrator user ID and password.

        You must use the password specified for the deployment environment administrator during the deployment environment creation.

    10. Map the J2C authentication alias to the BPMAdminJobUser role:

      1. Click Servers > Deployment Environment > yourDE > Authenticatin Aliases.

      2. Select the new J2C authentication alias and map it to the BPMAdminJobUser role.

  11. Configure an endpoint for the remote artifact loader (REMOTE_AL scenario) in each deployment environment. See Configure BPM endpoints to match the topology.

  12. Configure the third party trust association interceptors (TAI) for each dedicated security domain. See Configure third-party authentication products

  13. Configure InvokeTAIbeforeSSO for each dedicated security domain.

Configure BPM endpoints to match the topology

If the user's browser requests pass through a web server or load-balancing server before the request reaches the BPM server, configure the virtual host information used by BPM to generate URLs. Depending on the complexity of the topology and security setup, you might have to configure several different types of URLs.

BPM generates many different types of URLs for action links in the external browser client, internal communications, and connections to internal services. If the topology or security setup requires that BPM must generate certain types of URLs differently, there are various ways to configure them.

It is important to identify the different entry points in the network, such as load balancers and web servers, for external and internal clients. For example, generally, the protocol, host name, and port number of the entry point server must be used in any generated links that are served to clients. Sometimes the endpoints can be defined as a static URL, but in more complex topologies it might be necessary to use a dynamic strategy, such as extracting the information from the header of the request.

In simple topologies, the defaults should work without any changes. Generally, a production environment requires some changes to the defaults. For example, if you have a web server for external clients, you must make the following configuration changes:

More complex topologies and ones that include multiple deployment environments require more targeted configuration of specific objects.

Complete the following actions:

  1. Identify the components and structure of the topology. Components to consider include such things as load balancers, external web servers, reverse proxies, firewalls, internal web servers, Process Server, and Process Centers.

  2. Identify which default scenarios you must modify, and decide whether to use a virtual host object, a URL, or a list of dynamic strategies to determine the correct endpoint.

    For each deployment environment, use the following table to identify which of the default scenarios change, and whether to use a static virtual host definition, a static URL, or a list of dynamic strategies to get the host information for generated URLs.

    If you have multiple deployment environments, these settings must be evaluated and configured for each deployment environment.

    Default scenario keys for generated URLs

    Default BPMURL scenario keys Description
    EXTERNAL_CLIENT This generic scenario key is intended for non-relative URLs to be used by clients outside the data center, such as web browsers. 

    • If all external clients connect directly to the BPM server, there is no need to change the default value.

    • If all external clients use one entry point into the network, such as a web server, you can define the EXTERNAL_CLIENT scenario to use a static virtual host object or a static URL.

    • If you have multiple entry points for external clients, for example, a load balancer and a web server, using a single virtual host setting or a static URL is not appropriate, and you must define the EXTERNAL_CLIENT scenario to use one or more dynamic strategies. Use Table 2 to decide which strategies use.

    INTERNAL_CLIENT This generic scenario key is intended for non-relative URLs to be used by clients inside the data center, such BPM calling itself.

    • If all internal clients connect directly to the BPM server, there is no need to change the default value.

    • If all internal clients use one entry point into the network, such as a web server, you can define the INTERNAL_CLIENT scenario to use a static virtual host object or a static URL.

    • If you have multiple entry points for internal clients, for example, a load balancer and a web server, using a single virtual host setting or a static URL is not appropriate, and you must define the INTERNAL_CLIENT scenario to use one or more dynamic strategies. Use Table 2 to decide which strategies to use.

    RELATIVE This generic scenario key is intended for relative URLs to facilitate access to browser-based web applications through various entry points in the topology. For example, some users might access BPM through a reverse proxy whereas others might connect directly to the web server.

    These defaults are only used for a generated URL if the optional scenario that is specific to the URL type is not defined. For a list of which types of generated URLs are affected by each default, see Table 3. For each scenario, a BPMURL object defines a list of strategies. The strategies are attempted in the order specified until one returns the required information. Each strategy uses a different approach to determine the transport protocol, host, and port that are used to generate URLs, for example, by extracting them from a particular header in the request. The BPMURL object can also reference a BPMVirtualHostInfo object that contains fixed values for the transport protocol, host name, port number of the virtual host, and any URL prefix. Table 2 describes all strategies that are available.

    Strategies for identifying endpoint information for generated URLs

    Strategy name Description
    com.ibm.bpm.endpoint.impl.strategies.HttpProtocolHostStrategy This strategy attempts to extract the protocol, host, and port number information from the host header.
    com.ibm.bpm.endpoint.impl.strategies.RelativeUrlStrategy This strategy does not use host and port information.
    com.ibm.bpm.endpoint.impl.strategies.TeamworksWebappPrefixLegacyStrategy This strategy is for certain legacy paths such as the /exposed REST API and the /task/clientSettings REST API. The strategy searches for a BPMURL object that has the scenario attribute that is set to the value COMMON_TEAMWORKS_WEBAPP_PREFIX, and then uses the associated BPMVirtualHostInfo object.
    com.ibm.bpm.endpoint.impl.strategies.WCCMConfigStrategy This strategy uses static information from a BPMVirtualHostInfo object. The virtualHost property of the BPMURL object for the strategy identifies which virtual host information is used.
    com.ibm.bpm.endpoint.impl.strategies.WebsphereProxyHeaderStrategy If you use a WebSphere proxy, this strategy attempts to extract the protocol, host, and port number information from header that is added by the WebSphere proxy.
    com.ibm.bpm.endpoint.impl.strategies.XForwardedHeaderStrategy This strategy attempts to extract the protocol, host, and port number information from the XForwarded header entry.

  3. Connect to the wsadmin client by entering the following command:
    wsadmin.bat -conntype NONE -lang jython wsadmin.sh -conntype NONE -lang jython

  4. For each deployment environment that requires changes to the default scenarios, perform the following actions.

    Remember: Because the default scenario objects always exist in each deployment environment configuration, you never need to create them.

    1. Get and display the deployment environment object. Substituting your cell name for cell_name, complete the following actions.

      • If you have only one deployment environment, enter the following commands at the wsadmin prompt:
        dePath='/Cell:cell_name/BPMCellConfigExtension:/BPMDeploymentEnvironment:/'
        de=AdminConfig.getid(dePath)
        de 

      • If you have multiple deployment environments, and you want to modify the endpoints for the deployment environment named deployment_env_name, enter the following commands at the wsadmin prompt:
        dePath='/Cell:cell_name/BPMCellConfigExtension:/BPMDeploymentEnvironment:deployment_env_name/'
        de=AdminConfig.getid(dePath)
        de 

    2. Create a BPMVirtualHostInfo object for the deployment environment deployment_env_name, and keep a wsadmin variable pointer to it for any scenarios that must point to it.
      default_vh=AdminConfig.create('BPMVirtualHostInfo',de,
                                  [['name','vh_deployment_env_name'],
                                   ['transportProtocol','https'],
                                   ['hostname','example.com'],
                                   ['port','443'],
                                   ['uriPrefix','']],
                                   'virtualHosts')

    3. Set the default virtual host attribute (defaultVH) for the deployment environment to point to the new BPMVirtualHostInfo object, that is pointed to by the wsadmin variable default_vh.

        AdminConfig.modify(de,[['defaultVH',default_vh]])

    4. For each default scenario to modify for the deployment environment deployment_env_name:

      1. Identify the scenario to modify by typing one of the following commands:

        • scenario='EXTERNAL_CLIENT'
        • scenario='INTERNAL_CLIENT'
        • scenario='RELATIVE'

        Remember: Because the default scenarios listed in Table 1 are always defined, you do not need to create them.

      2. Get and display the BPMURL object for the scenario, scenario, by entering the following commands:
        dePath='path_to_deployment_environment'
        bpmurlsid=AdminConfig.getid(dePath+'BPMURLS:/')
        bpmurllist=AdminConfig.list("BPMURL", bpmurlsid).split()
        for item in bpmurllist :
         if AdminConfig.showAttribute(item,'scenario')==scenario : bpmurl=item
        
        bpmurl
        In this command, the value for scenario is defined in the previous step. For example, if you entered the scenario='INTERNAL_CLIENT' command, then, in this command scenario is 'INTERNAL_CLIENT'. The bpmurl command prints out the variable content so that you can verify the results.

        Because Jython relies on indentation to identify the contents of a loop, the space character before the if statement is required, and pressing enter twice is necessary to execute the loop. For example:

        dePath='/Cell:PCCell1/BPMCellConfigExtension:/BPMDeploymentEnvironment:/'
        bpmurlsid=AdminConfig.getid(dePath+'BPMURLS:/')
        bpmurllist=AdminConfig.list("BPMURL", bpmurlsid).split()
        for item in bpmurllist :
         if AdminConfig.showAttribute(item,'scenario')==scenario : bpmurl=item
        
        bpmurl

      3. Set the scenario by performing one of the following actions:

        1. If you decided to use a virtual host object, modify the BPMURL object for the scenario, scenario to set the virtualHost pointer to the new BPMVirtualHostInfo object, default_vh.

            AdminConfig.modify(bpmurl,[['virtualHost',default_vh]])

          If it is not appropriate to use the default virtual host information, create a new one, and set the pointer to that one. For example:

          internal_vh=AdminConfig.create('BPMVirtualHostInfo',de,
                                       [['name','vh_deployment_env_name'],
                                        ['transportProtocol','https'],
                                        ['hostname','internal.example.com'],
                                        ['port','443'],
                                        ['uriPrefix','']],
                                        'virtualHosts')
          
          AdminConfig.modify(bpmurl,[['virtualHost',internal_vh]])

        2. If you decided to use a fixed URL, set the url attribute on the BPMURL object for the scenario, scenario. For example, to set the URL https://webserver.example.com:443, enter the following command:

            AdminConfig.modify(bpmurl,[['url','https://webserver.example.com:443']])

        3. If you decided to use dynamic predefined strategies to extract the host information, modify the BPMURL object for the scenario, scenario to set the strategies property. For example, to set the bpmurl object to use the WebsphereProxyHeaderStrategy, XForwardedHeaderStrategy, and HttpProtocolHostStrategy' strategies, enter the following command:
          AdminConfig.modify(bpmurl,
                    [['strategies',
                      'com.ibm.bpm.endpoint.impl.strategies.WebsphereProxyHeaderStrategy,
                       com.ibm.bpm.endpoint.impl.strategies.XForwardedHeaderStrategy,
                       com.ibm.bpm.endpoint.impl.strategies.HttpProtocolHostStrategy']])

        Save changes.

          AdminConfig.save()

  5. If you have a complex topology or multiple deployment environments, you might need to create scenario objects for specific types of generated URLs.

    1. Optional: Test BPM clients, generated links, and functionality that you suspect might not work correctly with the default scenario settings in the topology.

    2. For each deployment environment, use Table 3 to identify any scenarios for types of generated URLs that cannot be handled correctly by the default scenarios. Focus on any clients or types of links that do not work correctly. For example, because there is one remote artifact loader per deployment environment, you must define the REMOTE_AL scenario for each deployment environment to direct appropriately to https://hostname:port/RemoteAL/, where RemoteAL is specified as a uriPrefix. For each scenario key, decide whether the scenario will use a fixed URL, a fixed virtual host object, or a list of dynamic strategies to resolve the endpoint information.

      Optional scenario keys for generated URLs

      Optional BPMURL scenario keys Which default scenario objects is used if the optional scenario object is not set (EXTERNAL_CLIENT, INTERNAL_CLIENT, or RELATIVE) Notes
      AE_BPM_REST_SERVICE_CR_PREFIX EXTERNAL_CLIENT Configures the URLs that are used in the Process Designer authoring environment to contact the BPM REST API service.
      AE_IMAGES_PREFIX EXTERNAL_CLIENT Configures the URLs that are used in the Process Designer authoring environment to get images.
      AE_PORTAL_PREFIX EXTERNAL_CLIENT Configures the URLs that are used in the Process Designer authoring environment to reach Process Portal.
      AE_REPOSITORY_PREFIX EXTERNAL_CLIENT Configures the URLs that are used in the Process Designer authoring environment to reach the repository.
      AE_SERVLET_PREFIX EXTERNAL_CLIENT Configures the URLs that are used in the Process Designer. This scenario must specify an absolute URL by setting the url property.

      The purpose of this scenario key is so that you can add your own target to the whitelist of targets to which Process Portal can redirect browsers to access dashboards. For security reasons, redirection to arbitrary targets is not allowed. BPM enforces the following whitelist for allowable redirect targets.

      • localhost
      • 127.0.0.1
      • The host identified by the AE_SERVLET_PREFIX scenario's url attribute, which must be specified as an absolute URL.
      • The host identified by the PROCESS_PORTAL_DASHBOARD_REDIRECT_ADDITIONAL_WHITELISTED scenario.

      AE_WEBAPI_PREFIX EXTERNAL_CLIENT Configures the URLs that are used in the Process Designer authoring environment to reach the web API.
      AE_SOCIALBUS_WEBAPP_PREFIX EXTERNAL_CLIENT Configures the URLs that are used in the Process Designer authoring environment to reach the social bus web application.
      BPM_HELP RELATIVE and EXTERNAL_CLIENT Configures the URLs generated to access the product help information in the BPMHelp.war file. If there is an active user, for example using a browser, the RELATIVE default is used, otherwise, if there is no active user, such as for a link in an email, the EXTERNAL_CLIENT default is used.
      BPM_REST RELATIVE Configures the URLs generated to access the REST APIs.
      COMMON_COACH_DESIGNER_XSL_URL EXTERNAL_CLIENT  
      COMMON_PORTAL_PREFIX EXTERNAL_CLIENT  
      COMMON_PROCESS_ADMIN_PREFIX EXTERNAL_CLIENT  
      COMMON_TEAMWORKS_WEBAPP_PREFIX EXTERNAL_CLIENT Is used to point to the BPMVirtualHostInfo object used by the TeamworksWebappPrefixLegacyStrategy strategy. For more information about this strategy, see Table 2.
      COMMON_WEBSERVICES_BASE_URL EXTERNAL_CLIENT  
      EXPOSED_ITEMS EXTERNAL_CLIENT Configures generated URLS for items that are exposed, such as favorites. By default it uses the XForwardedHeaderStrategy strategy.
      HEARTBEAT_DESIGNATED_DEPLOYMENT_ENDPOINT INTERNAL_CLIENT Configures the URL used by Process Center to deploy applications to Process Server. The endpoint must resolve to the teamworks.war web module in the IBM_BPM_Teamworks application.
      IBM_BPM_DOCUMENTSTORE_CMIS_WEBSERVICE INTERNAL_CLIENT Configures how the EmbeddedECM finds the CMIS web service.
      LSW_SERVLET EXTERNAL_CLIENT Used by the LSW servlet. By default, it uses the following strategies: WCCMConfigStrategy, XForwardedHeaderStrategy, and HttpProtocolHostStrategy.
      NAVIGATION_UTILITY_TO_TEAMWORKS_HTML RELATIVE Configures the navigation URLs that are generated in the utility module. These URLs are used by Process Portal.
      NAVIGATION_UTILITY_TO_TEAMWORKS_JSON RELATIVE Configures the URLs in the navigation tree of the Server Admin tab of the Process Admin Console.
      PROCESS_CENTER EXTERNAL_CLIENT Configures URLs to Process Center.
      PROCESS_CENTER_RELATIVE RELATIVE Configures URLs that are relative to the Process Center.
      PROCESS_PORTAL RELATIVE and EXTERNAL_CLIENT Configures URLs to Process Portal. If there is an active user, for example using a browser, the RELATIVE default is used, otherwise, if there is no active user, such as for a link in an email, the EXTERNAL_CLIENT default is used.
      PROCESS_PORTAL_DASHBOARD_REDIRECT_ADDITIONAL_WHITELISTED EXTERNAL_CLIENT

      The purpose of this scenario key is so that you can add your own target to the whitelist of targets to which Process Portal can redirect browsers to access dashboards. For security reasons, redirection to arbitrary targets is not allowed. BPM enforces the following whitelist for allowable redirect targets.

      • localhost
      • 127.0.0.1
      • The host identified by the AE_SERVLET_PREFIX scenario's url attribute, which must be specified as an absolute URL.
      • The host identified by the PROCESS_PORTAL_DASHBOARD_REDIRECT_ADDITIONAL_WHITELISTED scenario.

      PROCESS_PORTAL_JS RELATIVE Configures URLs to Process Portal. You must set this scenario key in the following cases:

      • Tivoli Access Manager WebSEAL is configured in the BPM topology.

      • If Lotus Sametime is configured in the BPM topology, set this scenario to use the com.ibm.bpm.endpoint.impl.strategies.WCCMConfigStrategystrategy and set the virtualHost property to point to the virtual host information object for the Process Portal server.

      • If the PROCESS_PORTAL scenario key is configured for some other environment that is not related to WebSEAL or Sametime, then the PROCESS_PORTAL_JS scenario key must match the setting for the PROCESS_PORTAL scenario key.

      PROCESS_PORTAL_SUPPORT RELATIVE and EXTERNAL_CLIENT Configures URLs to Process Portal support. If there is an active user, for example using a browser, the RELATIVE default is used, otherwise, if there is no active user, such as for a link in an email, the EXTERNAL_CLIENT default is used.
      PROCESS_PORTAL_SUPPORT_TO_BPM_HELP   Configures URLs that are from Process Portal support to BPM help.
      PROCESS_PORTAL_SUPPORT_TO_PROCESS_PORTAL   Configures URLs that are from Process Portal support to Process Portal.
      PROCESS_PORTAL_SUPPORT_TO_TEAMWORKS and PROCESS_PORTAL_SUPPORT_TO_TEAMWORKS_JS   Configures URLs that are from Process Portal support to the Teamworks web archive WAR file.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_BPM_HELP and PROCESS_PORTAL_TO_BPM_HELP_JS RELATIVE Configures the links in Process Portal that point to the product help information in the BPM_HELP.war file.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_BPM_REST and PROCESS_PORTAL_TO_BPM_REST_JS RELATIVE Configures URLs that are from Process Portal to the BPM REST API.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_BUSINESS_SPACE and PROCESS_PORTAL_TO_BUSINESS_SPACE_JS RELATIVE Configures URLs that are from Process Portal to Business Space.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_BUSINESS_SPACE_HELP and PROCESS_PORTAL_TO_BUSINESS_SPACE_HELP_JS RELATIVE Configures URLs that are from Process Portal to Business Space help.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_MASHUPS_RUNTIME and PROCESS_PORTAL_TO_MASHUPS_RUNTIME_JS RELATIVE Configures URLs that are from Process Portal to mashups run time.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_PROCESS_PORTAL_SUPPORT and PROCESS_PORTAL_TO_PROCESS_PORTAL_SUPPORT_JS RELATIVE Configures URLs that are from Process Portal to Process Portal support.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_SOCIAL_BUS_WEB and PROCESS_PORTAL_TO_SOCIAL_BUS_WEB_JS RELATIVE Configures URLs that are from Process Portal to social bus web.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_TEAMWORKS and PROCESS_PORTAL_TO_TEAMWORKS_JS RELATIVE Configures URLs that are from Process Portal targeting the Teamworks web archive WAR file.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_WEBAPI and PROCESS_PORTAL_TO_WEBAPI_JS RELATIVE Configures URLs that are from Process Portal to the web API.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      PROCESS_PORTAL_TO_WEBVIEWER and PROCESS_PORTAL_TO_WEBVIEWER_JS RELATIVE Configures URLs that are from Process Portal to the web viewer.

      If you use Tivoli Access Manager WebSEAL, the scenario key ending with _JS must be configured to include the WebSEAL junction name so that URLs that are generated in JavaScript are handled correctly. If you do not use Tivoli Access Manager WebSEAL, both scenario keys must be set identically.

      REMOTE_AL   Configures URLs to the remote artifact loader's Remote_AL_WEB.war file. There is one remote artifact loader per deployment environment, so if you have multiple deployment environments, you must define the REMOTE_AL scenario for each deployment environment to direct appropriately to https://hostname:port/RemoteAL/, where RemoteAL is specified as a required uriPrefix.
      SERVER_ACTIVITY_STREAM_IMAGE_LINK EXTERNAL_CLIENT Configures the URL for the activity stream image, for example, https://sureshb13:9443/ProcessPortal. The path /com/ibm/bpm/social/img/Bpm_connections_48x48.png is appended to the value specified.
      SERVER_EMAIL_GADGET_LINK EXTERNAL_CLIENT Configures the URL for the gadget XML file, for example https://sureshb13:9443/ProcessPortal. The path /gadgets/OpenSocial/BPMOpenSocialGadget.xml is appended to the value specified.
      SERVER_EMAIL_PORTAL_LINK EXTERNAL_CLIENT Configures the URLs for links to Process Portal that are included in emails.
      SERVER_EMAIL_PORTAL_PROCESS_INFO_LINK EXTERNAL_CLIENT Configures the URL for links to process information that are included in emails, for example https://sureshb13:9443/ProcessPortal. The path /dashboards/TWP/Process+Performance?tw.local.selectedInstanceId={6} is appended to the value specified.
      SERVER_EMAIL_PORTAL_RUN_TASK_LINK EXTERNAL_CLIENT Configures the URLs for links (to run tasks) that are included in emails, for example https://sureshb13:9443/ProcessPortal. The path /dashboards/TWP/BPM_WORK?tw.local.view=taskcompletion&tw.local.taskid={2} is appended to the value specified.
      SERVER_EMAIL_TEMPLATE_CLIENT_LINK EXTERNAL_CLIENT Configures the URLs for links (to the client template) that are included in emails.
      SERVER_TASK_NOTIFICATION_GADGET_LINK EXTERNAL_CLIENT  
      SERVER_WEBIMAGES_PREFIX EXTERNAL_CLIENT  
      SOCIAL_BUS_WEB   Configures URLs to social bus web.
      TASK_REST_API EXTERNAL_CLIENT Configures URLs used by the task REST API. By default it invokes the following strategies: WCCMConfigStrategy, WebsphereProxyHeaderStrategy, XForwardedHeaderStrategy, and HttpProtocolHostStrategy.
      TASK_TEMPLATE_REST_API EXTERNAL_CLIENT Configures URLs used by the task template REST API. By default it invokes the following strategies: WCCMConfigStrategy, WebsphereProxyHeaderStrategy, XForwardedHeaderStrategy, and HttpProtocolHostStrategy.
      TEAMWORKS RELATIVE Configures URLs to Teamworks.
      TEAMWORKS_TO_BUSINESSSPACE RELATIVE Configures URLs in Teamworks to Business Space.
      TEAMWORKS_TO_MASHUPS_RUNTIME RELATIVE Configures URLs in Teamworks to get data from mashups run time.
      TEAMWORKS_TO_PROCESS_PORTAL_SUPPORT RELATIVE Configures URLs in Teamworks to Process Portal support.
      TEAMWORKS_TO_PROCESSADMIN RELATIVE Configures URLs in Teamworks to get back to the Process Admin Console. For example, on the Process Admin welcome page this scenario key is used to generate the URL to the Process Status Summary widget.
      WEBVIEWER RELATIVE and EXTERNAL_CLIENT Configures URLs to the web viewer. If there is an active user, for example using a browser, the RELATIVE default is used, otherwise, if there is no active user, such as for a link in an email, the EXTERNAL_CLIENT default is used.

    3. If you identified any optional scenarios in Table 3 that must be configured, complete the following actions:

      Remember: Because the optional scenario objects do not always exist in each deployment environment configuration, you might need to create them.

      1. For each deployment environment that requires changes to the optional scenarios, perform the following actions.

        1. Get and display the deployment environment object. Substituting your cell name for cell_name, complete the following actions.

          • If you have only one deployment environment, enter the following commands at the wsadmin prompt:
            dePath='/Cell:cell_name/BPMCellConfigExtension:/BPMDeploymentEnvironment:/'
            de=AdminConfig.getid(dePath)
            de 

          • If you have multiple deployment environments, and you want to modify the endpoints for the deployment environment named deployment_env_name, enter the following commands at the wsadmin prompt:
            dePath='/Cell:cell_name/BPMCellConfigExtension:/BPMDeploymentEnvironment:deployment_env_name/'
            de=AdminConfig.getid(dePath)
            de 

        2. For each optional scenario, SCENARIO_KEYthat you want to modify:

          1. Identify the scenario by entering the following command:

              scenario='SCENARIO_KEY'

            Remember: Replace SCENARIO_KEY with the appropriate scenario key value from Table 3.

          2. If you cannot use the default virtual host information object, default_vh, for the deployment environment create a new virtual host object, vh_N. For example, if the virtual host is https://webserver.example.com:443, with no URI prefix, enter the following command:
            vh_N=AdminConfig.create('BPMVirtualHostInfo',de,
                                                  [['name','vh_N'],
                                                   ['transportProtocol','https'],
                                                   ['hostname','webserver.example.com'],
                                                   ['port','443'],
                                                   ['uriPrefix','']],
                                                  'virtualHosts')
          3. Check whether the BPMURL object for the scenario is already defined, by entering the following commands:
            dePath='path_to_deployment_environment'
            bpmurlsid=AdminConfig.getid(dePath+'BPMURLS:/')
            bpmurllist=AdminConfig.list("BPMURL", bpmurlsid).split()
            for item in bpmurllist :
             if AdminConfig.showAttribute(item,'scenario')==scenario : bpmurl=item
            
            bpmurl
            In this command, the value for scenario is defined in a previous step. The bpmurl command prints out the variable content so that you can verify the results.

            Because Jython relies on indentation to identify the contents of a loop, the space character before the if statement is required, and pressing enter twice is necessary to execute the loop. For example:

            dePath='/Cell:PCCell1/BPMCellConfigExtension:/BPMDeploymentEnvironment:/'
            bpmurlsid=AdminConfig.getid(dePath+'BPMURLS:/')
            bpmurllist=AdminConfig.list("BPMURL", bpmurlsid).split()
            for item in bpmurllist :
             if AdminConfig.showAttribute(item,'scenario')==scenario : bpmurl=item
            
            bpmurl

            1. If a BPMURL object for the scenario does not exist, create it and set the necessary properties. For example, by entering something similar to the following:
              bpmurlsPath=dePath+'BPMURLS:/'
              bpmurlsid=AdminConfig.getid(bpmurlsPath)
              bpmurl=AdminConfig.create('BPMURL',bpmurlsid,
                         [['scenario',scenario],
                         ['virtualHost',vh_N],
                         ['strategies','com.ibm.bpm.endpoint.impl.strategies.XForwardedHeaderStrategy,
                                        com.ibm.bpm.endpoint.impl.strategies.WCCMConfigStrategy'],
                         ['url','https://example.com:9444']])

              If you set values for virtualHost and url, as is shown in the previous example, the url setting is used, and the virtualHost setting is ignored.

            2. If a BPMURL object for the scenario is already defined in the deployment environment, modify the existing object by completing one of the following actions:

              1. If you decided to use a virtual host object, modify the BPMURL object for the scenario, scenario to set the virtualHost pointer to the appropriate BPMVirtualHostInfo object. For example, if you created a suitable object that is pointed to by the wsadmin variable vh_N, enter the following command:

                  AdminConfig.modify(bpmurl,[['virtualHost',vh_N]])

                If values are set for virtualHost and url, the url setting is used and the virtualHost setting is ignored.

              2. If you decided to use a fixed URL, set the url attribute on the BPMURL object for the scenario, scenario. For example, to set the URL https://webserver.example.com:443, enter the following command:

                  AdminConfig.modify(bpmurl,[['url','https://webserver.example.com:443']])

              3. If you decided to use dynamic predefined strategies to extract the host information, modify the BPMURL object for the scenario, scenario to set the strategies property. For example, to set the bpmurl object to use the WebsphereProxyHeaderStrategy, XForwardedHeaderStrategy, and HttpProtocolHostStrategy' strategies, enter the following command:
                AdminConfig.modify(bpmurl,
                          [['strategies',
                            'com.ibm.bpm.endpoint.impl.strategies.WebsphereProxyHeaderStrategy,
                             com.ibm.bpm.endpoint.impl.strategies.XForwardedHeaderStrategy,
                             com.ibm.bpm.endpoint.impl.strategies.HttpProtocolHostStrategy']])

        Save any changes.

          AdminConfig.save()

  6. Activate the new settings by performing a ripple start of your clusters.

  7. Optional: Verify the endpoints that you configured work as expected. Depending on which endpoints you configured, check the clients that are affected by the endpoint changes are working correctly. For example, any changes to a scenario with a key that starts with the string PROCESS_PORTAL can be tested by using Process Portal from a browser. If there are any problems, check and correct the endpoint settings for URLs that are not working.

All URLs that are generated by BPM work correctly in the topology.


Configure third-party authentication products

To use a third-party authentication product, you must customize various configuration settings.

Ensure that all your IBM Business Process Manager servers and clients are at V8.5.0.1 or later.

  1. Configure your third-party authentication product so that it does not intercept URLs that BPM uses for server to server communication. For information about how to configure your third-party authentication product, see the documentation for that product.

    1. Configure your third-party authentication product to allow basic access authentication for the context roots listed in the following table.

      Context roots that require basic authentication for technical user IDs

      Context roots that require basic authentication Description
      /ProcessCenterInternal/* Process Server uses this context root on Process Center to register or unregister with Process Center.
      /ProcessServerInternal/* Process Center uses this context root on Process Server for online deployment.

    2. Configure your third-party authentication product so that it does not intercept communications with the web services listed in the following table.

      Web service context roots that must not be intercepted by third-party authentication products

      Web service context roots that must not be intercepted Associated service
      /bpmjaxws/* BPM JAX-WS Web Services API
      /fncmis/* The embedded Enterprise Content Management Content Management Interoperability Service (ECM CMIS) web service provider
      /RemoteALWeb/* Remote artifact loader
      /teamworks/webservices/* Teamworks web services
      /webapi/* BPM legacy web service API

  2. Ensure that your third-party authentication product allows URLs to contain all characters that BPM uses. The default configuration of your third-party authentication product might not allow the characters"<" and ">", which Process Inspector uses. For information about such restrictions and how you can configure the product to allow these characters, see the documentation for your third-party authentication product.

  3. If your third-party authentication product requires that all logout actions in clients are redirected to special URLs, change the configuration settings for each BPM client that you use.

    1. Identify the BPM clients that you use. For the list of clients, see the following table, noting that AppCluster is the name of your application cluster and SupportCluster is the name of your support cluster.

      IBM Business Process Manager client logout page configuration paths and attribute names

      BPM client AdminConfig command configuration object containment path Attribute name for the custom logout page URL Notes
      Business Process Archive Explorer /ServerCluster:SupportCluster/BPMClusterConfigExtension:/BPMBPCArchiveExplorer:/ customLogoutPage This client is available only in BPM Advanced.
      Business Process Choreographer Explorer /ServerCluster:SupportCluster/BPMClusterConfigExtension:/BPMBPCExplorer:/ customLogoutPage This client is available only in BPM Advanced.
      Business Rules Manager /ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMBusinessRules:/ customLogoutPage  
      Performance Data Warehouse Performance Admin Console /ServerCluster:SupportCluster/BPMClusterConfigExtension:/BPMPerformanceDataWarehouse:/ customLogoutPage  
      Process Admin Console

      On Process Center:

      /ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMProcessCenter:/

      On Process Server:

      /ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMProcessServer:/
      processAdminCustomLogout

      If you use Process Inspector in the Process Admin Console, when you log out of Process Inspector you are redirected to the custom logout page specified for the Process Admin Console.

      Process Center Console /ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMProcessCenter:/ customLogoutPage  
      Process Portal /ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMPortal:/ customLogoutPage  
      REST API Tester

      On Process Center:

      /ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMProcessCenter:/

      On Process Server:

      /ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMProcessServer:/
      restApiTesterCustomLogout  

    2. For each BPM client that you use, identify the URL of the custom logout page that you want logout actions to be redirected to.

      The URLs of the custom logout pages might be misinterpreted if they include the following characters.

      • Spaces
      • Percent signs (%) that are not part of a character coding, such as %25
      • Ampersand characters (&) that are not part of a predefined entity, such as &amp;
      • Other special characters

      To ensure that each URL is parsed correctly, you must replace special characters with a suitable encoding, such as %20 for spaces, %25 for percent signs, and %26 for ampersands. Substituting the predefined symbol &amp; for ampersands might not work for all clients. If a URL is difficult to convert, you can submit it to an online URL encoder to convert it to a suitable string.

    3. If any of the URLs of the custom logout pages are not on the same host as the BPM server or do not belong to the same domain, you must set one of the com.ibm.websphere.security.allowAnyLogoutExitPageHost or com.ibm.websphere.security.logoutExitPageDomainList global security custom properties.

      For more information about these custom properties, see Security custom properties.

    4. For each BPM client that you use, run the necessary administrative commands to set the appropriate custom logout page property to point to the custom logout page. For example, to set the custom logout page URL for the Process Center Console to https://security.example.com/pclogout.html on a Windows platform, enter the following commands.

      1. Connect to the wsadmin client:
        D:\IBM\bpm8500\WAS\AppServer\profiles\AdPCDmgr0Profile\bin>wsadmin.bat -conntype NONE -lang jython
        WASX7357I: By request, this scripting client is not connected to any server process. Certain configuration and application operations will be available in local mode.
        WASX7031I: For help, enter: "print Help.help()"

      2. Use the appropriate path from Table 3, get the Process Center object and display its value:
        wsadmin>path='/ServerCluster:AppCluster/BPMClusterConfigExtension:/BPMProcessCenter:/'
        wsadmin>object=AdminConfig.getid(path)
        wsadmin>object
        '(cells/PCCell1/clusters/AppCluster|cluster-bpm.xml#BPMProcessCenter_1374114772846)'

      3. Use the appropriate attribute name for the custom logout page URL from Table 3, display the current value of the custom logout page URL attribute:
        wsadmin>clp='customLogoutPage'
        wsadmin>print AdminConfig.showAttribute(object,clp)
        None 

      4. Set the value of the custom logout page URL attribute:
        wsadmin>AdminConfig.modify(object,[[clp,'https://security.example.com/pclogout.html']])
        ''
      5. Display the new value to verify that it is correct:
        wsadmin>print AdminConfig.showAttribute(object,clp)
        https://security.example.com/pclogout.html

        Save the changes.

        wsadmin>AdminConfig.save()
        ''

  4. If you use a third-party Trust Association Interceptor (TAI), complete the following actions:

    1. If you do not use dedicated security domains, complete the following actions on the global security level:

      1. Enable trust association.

        1. Use the administrative console, navigate to Security > Global Security > Web and SIP Security > Trust Association.

        2. Select Enable trust association.

        3. Click Interceptors, then click New and enter the name of the TAI Java class name for your third-party authentication product. For example, for CA SiteMinder, the Java class name is com.netegrity.siteminder.websphere.auth.SmTrustAssociationInterceptor.

          For information about the TAI Java class name for other third-party authentication products, see the documentation for those products.

      2. Optional: To ensure that TAI is invoked before Single Sign-On (SSO), set the custom property InvokeTAIbeforeSSO. Using the administrative console, navigate to Security > Global Security > Custom properties and click New. Enter the custom property name com.ibm.websphere.security.InvokeTAIbeforeSSO, and the name of the TAI Java class for your third-party authentication provider.

    2. If you use dedicated security domains, complete the following actions at the security domain level:

      1. Enable trust association for each security domain. For each security domain, security_domain_name, complete the following actions in the administrative console:

        1. Navigate to Security > Security domains > security_domain_name > Trust Association.

        2. Select Customize for this domain.

        3. Select Enable trust association.

        4. Click Interceptors, then click New and enter the name of the TAI Java class name for your third-party authentication product. For example, for CA SiteMinder, the Java class name is com.netegrity.siteminder.websphere.auth.SmTrustAssociationInterceptor.

          For information about the TAI Java class name for other third-party authentication products, see the documentation for those products.

      2. Optional: To ensure that TAI is invoked before Single Sign-On (SSO), set the custom property InvokeTAIbeforeSSO. Use the administrative console to set the custom property for each security domain, security_domain_name. Navigate to Security > Security domains > security_domain_name > Custom properties and click New. Enter the custom property name com.ibm.websphere.security.InvokeTAIbeforeSSO, and the name of the TAI Java class for your third-party authentication provider.

  5. Complete the actions that are described in Configure the propagation of HTTP headers and cookies for a third-party authentication environment.

  6. Complete the actions that are described in Configure BPM endpoints to match the topology.

  7. Verify that BPM works correctly with your third-party authentication product. For each BPM client that you use, verify that you can log on, the client is fully functional, and that logging out redirects correctly. The following table describes some possible problems and how to solve them.

    Diagnosing possible problems with third-party authentication products

    Problem Possible causes Solutions
    When you are logged on to a Process Center, Process Server is not visible. If you have separate web servers for internal and external traffic, Process Server might not be accessible from the Process Center Check and adapt the endpoints to suit your setup as described in Modify Process Server connection properties.
    Clients do not display all IBM Business Process Manager data correctly.

    • Calls to the remote artifact loader are being intercepted.

    • If you have multiple deployment environments, each one has its own remote artifact loader, and the endpoints might not be configured to reflect the topology.

    • Make sure that your third-party authentication product is not intercepting calls to the RAL context root /RemoteALWeb.
    • You might need to configure the REMOTE_AL endpoint for each deployment environment, as described in Configure BPM endpoints to match the topology.

    Process Designer does not work properly. Your third-party authentication product might use a login form that Process Designer cannot process. Either make sure that your third-party authentication product is not intercepting calls to the Process Center URL used by Process Designer or implement an authenticator plug-in to handle the login form.

    For more information about creating a plug-in for the Process Designer login authenticator extension point, see Configure a custom authenticator plug-in.

    Process Designer normally uses a mixture of RMI and JMS calls, but you can configure it to use only HTTP calls by completing the actions that are described in Configure the httpProtocolOnly property for Process Designer. Using this setting might simplify how your third-party authentication product must be configured.

IBM Business Process Manager and its clients work correctly with your third-party authentication product.


Configure a custom authenticator plug-in

IBM Business Process Manager Process Center supports the use of a custom authenticator plug-in to work with your third-party authentication single sign-on environment.

You define a login authenticator in Process Designer to declare an extension for client side login logic to address special authentication requirements from the server side. When authentication is triggered, Process Designer retrieves the authenticator application programming interface (API) and starts the login logic. The authenticator extension point is an API provided in the Eclipse plug-in format.

The authenticator API can return two sets of security tokens. The first set of security tokens is shared among all connections using Java HTTP clients triggered by user Create, Read, Update and Delete (CRUD) activities within one Process Designer. This set supports inactivity timeout on user interaction requests. The second set of security tokens is shared during Process Designer and Process Center communication, CometD initialization, and embedded browsers. This set does not provide inactivity timeout support. If the authenticator API returns only one set of security tokens, it is shared among all HTTP clients within Process Designer. Active polling will disable inactivity timeout. The authenticator API uses the same set of security tokens for polling and inactivity timeout. If you are using a custom plug-in and want to support inactivity timeout, the environment must support two security tokens.

  1. Define the login authenticator extension. The Process Designer login authenticator extension point requires that:

    • The class is extended from the abstract Authenticator class.
    • You specify the contributor class name in the extension details.
    • The class must implement the abstract method for the custom login logic.

    • You can set the isCustom flag to true in the extension details. If not set, it defaults to true.

    The abstract authenticator class is in the com.ibm.bpm.client.ae.security.authentication package. The subclass must implement the login API:

    public abstract ILoginResult login(String userId, String url, int returnCode,
                Map<String, List<String>> responseHeaders, InputStream responseBody)
                throws Exception;

    The parameters of the login API:

    userId - the userId returned by previous login, null if it is first time to login.
    url - url for the protected resource or url after redirect has been followed returnCode - HTTP return code from the URL responseHeaders - Map<String, List<String>>, keys are header names and values are list of header values.
    responseBody - InputStream: caller will close the InputStream
    LoginResult - need to return a valid result, not null.
    
    exception: if login failed, throw Exception with localized message.

    The extension point for custom login behavior:

    <!ELEMENT extension (Authenticator)
    <!ATTLIST extension   point  CDATA #REQUIRED
      id     CDATA #IMPLIED
      name   CDATA #IMPLIED
    
    <!ELEMENT Authenticator EMPTY>
    <!ATTLIST Authenticator
      isCustom  (true | false)
      class     CDATA #REQUIRED

    The login API returns the following result cases in the ILoginResult interface, which is contained in the com.ibm.bpm.client.ae.security.authentication package:

    • LoginNotRequired

      • Description: Returned if the HTTP response code, HTTP headers, and HTTP body response parameters do not indicate that an authentication request was issued by the server. The authenticator does not guarantee that no login is required, only the response is not an authentication request that it can process.
      • API: The authenticator returns the ILoginResult object with null values for requestTokens, pollingTokens, and userId.

    • LoginRequiredAndSuccessful

      • Description: The Authenticator detected an authentication request and successfully handled the authentication. The SSO tokens and the user ID can be retrieved using the ILoginResult instance.
      • API: The authenticator returns non null values for requestTokens and userId. The user Id that is returned must match the user Id that is passed to Authenticator.login. The plug-in does not allow the user to change the user ID during a Process Designer session. If the user ID that is returned is different from the previous login user ID, Process Designer will treat it as an error and display a message. It will prompt the user to either retry the request or exit Process Designer.

    • LoginRequiredAndUnSuccessful

      • Description: The authenticator uses this case if a login is not possible due to technical reasons. For example: network connection issues, faulty configuration, coding errors, server not available, and so on. The authenticator may or may not interact with the user as needed before resulting in this case.
      • API: The authenticator throws a java.lang.Exception exception or a subclass the exception, which must contain a short description of the problem as a message. The Exception created by the plug-in must be localized when returned from the Exception.getMessage() method.

    • LoginRequiredAndCancelledByUser

      • Description: The authenticator throws the org.eclipse.core.runtime.OperationCanceledException exception.

    To implement the login API:

    IBM Business Process Manager includes a BPM_GENERIC_HEADER in the response. If HTTP return code is less than 400, for example 302, and the BPM_GENERIC_HEADER header is not in the response, Process Designer call the custom plug-in. In addition, if one of the following conditions are true, Process Designer call the custom plug-in:

    • If the HTTP return code is 401

    • If the HTTP return code is 407

    public Collection<String> getRequestTokens();
    Obtains the security tokens for normal user interactions if login was needed null otherwise.
    The items in collection are the external format of the cookies, such as:
         SMTRYNO=; expires=Fri, 11 Jan 2013 13:54:32 GMT; path=/;
         domain=ibm.com; HTTPOnly
    
    return Collection<String> - The security cookies for normal PD activities, or null if login is not required 
    public Collection<String> getPollingTokens();
    Obtains polling tokens if inactive session timeout is required.
    The items in collection are the external format of the cookies, such as:
     SMTRYNO=; expires=Fri, 11 Jan 2013 13:54:32 GMT; path=/;
          domain=ibm.com; HTTPOnly
         
    return Collection<String> - The security cookies for polling if needed, or null
    public String getProxyAuthorizationHeader();
    Obtains the proxy authorization header if a forward proxy is configured with PD. Such as:
          NTLM TlRMTVNTUAADAAAAGAAYAHIAAAAYABgAigAAABIAEgBIAAAABgAGAFoAA
    
    return String - proxy authorization header if the returnCode passed to Authenticator.login method is 407, otherwise return null
    public String getUserId();
    Return the userId of the person logged in.
    
    return String
  2. Deploy the custom login authenticator plug-in to Eclipse. The plug-in is exported as individual jar files.

    1. Place the custom authenticator plug-in jar files in to the BPM\Lombardi\tools\designer\dropins folder.
    2. Download Process Designer from the Process Center. Process Center discovers new files in the dropins folder and includes them in the downloaded Process Designer.zip file.

  3. To install a new version of the custom plug-in:

    1. Add the new plug-in jar files to the BPM\Lombardi\tools\designer\dropins folder.
    2. Uninstall Process Designer.
    3. Download Process Designer from Process Center.


Configure the httpProtocolOnly property for Process Designer

Modify the httpProtocolOnly property to configure Process Designer to use the HTTP or HTTPS protocol instead of RMI with JMS.

Use the WebSphere command-line administration tool (wsadmin) AdminConfig commands to access and modify the httpProtocolOnly property of the BPMProcessCenter or BPMProcessServer configuration objects. The term configuration object refers to an object that is accessed by using the wsadmin AdminConfig commands. See Commands for the AdminConfig object using wsadmin scripting.

  1. Start the wsadmin scripting tool:
    Dmgr_HOME\bin>wsadmin -conntype NONE -lang jython WASX7357I: By request, this scripting client is not connected to any server proc ess. Certain configuration and application operations will be available in local  mode.
    WASX7031I: For help, enter: "print Help.help()"

  2. Modify the httpProtocolOnly property:
    wsadmin>b=AdminConfig.getid("/Cell:/ServerCluster:application_cluster_name/BPMClusterConfigExtension:/BPMProcessCenter:/") # You must use BPMProcessCenter or BPMProcessServer depending on the deployment environment wsadmin>b
    '(cells/PCCell1/clusters/AppCluster|cluster-bpm.xml#BPMProcessCenter_13763630618
    45)'
    wsadmin>print AdminConfig.showAttribute(b,'httpProtocolOnly')
    false
    wsadmin>AdminConfig.modify(b,[['httpProtocolOnly','true']])
    ''
    wsadmin>print AdminConfig.showAttribute(b,'httpProtocolOnly')
    true
    wsadmin>AdminConfig.save()
    ''

    If you change the value of the httpProtocolOnly property to false, the user ID specified for the J2C security alias that maps to the BPMAuthor role on the Process Server must exist on the Process Center, and the passwords must be the same.

  3. Run the AdminConfig.save command each time the property is modified for the configuration changes to be saved.


Configure the propagation of HTTP headers and cookies for a third-party authentication environment

If you use a third-party authentication product, configure the web Process Inspector façade and federated REST API façade to ensure the HTTP headers and cookies are propagated from the incoming request of a transaction through to the outgoing BPM REST request.

You can specify a list of headers and cookies the Process Inspector must propagate. You can also specify a URL prefix for outgoing requests from the façade to the BPM REST service. If you use BPM Advanced, also specify a list of headers and cookies the federated REST API must propagate.

  1. If you use Process Inspector on the Inspector tab of the Process Admin Console, complete the following actions.

    1. For each application cluster member in the deployment environment, edit 100Custom.xml.

      For information about the 100Custom.xml configuration file, including its location, see The 99Local.xml and 100Custom.xml..

    2. Add the names of the headers and cookies that are to be propagated. Use the <propagate> tag in the <process-inspector> section, as illustrated in the following example for CA SiteMinder:
      <server merge="mergeChildren">
          <process-inspector merge="mergeChildren">
               <propagate merge="append">
                  <header name="SM_TRANSACTIONID"/>
                  <header name="SM_SDOMAIN"/>
                  <header name="SM_AUTHTYPE"/>
                  <header name="SM_USER"/>
                  <header name="SM_USERDN"/>
                  <header name="SM_SERVERSESSIONID"/>
                  <header name="SM_SERVERSESSIONSPEC"/>
                  <header name="SM_TIMETOEXPIRE"/>
                  <header name="SM_SERVERIDENTITYSPEC"/>
                  <cookie name="SMSESSION"/>
              </propagate>
          </process-inspector>
      </server>
      For information about the header and cookie names that are used by other third-party authentication products, see the documentation for those products.

      The LTPA token and LtpaToken2 cookies are propagated by default.

      Save changes.

  2. If you use BPM Advanced, configure the header and cookie propagation settings for the federated REST API. For all headers and cookies to be forwarded, you can skip this step because that is the default behavior.

    The deny and allow rules are defined by Java™ regular expressions. The strings "" and ".*" match all headers and cookies. The semantics of the forwarding rules for headers and cookies are the deny rule is evaluated before the allow rule. These semantics mean that headers and cookies that match both the deny rule and the allow rule are forwarded.

    1. Connect to the wsadmin client:

        wsadmin.bat -conntype NONE -lang jython

        wsadmin.sh -conntype NONE -lang jython

    2. Get and display the BPMDispatchConfiguration object:
      wsadmin>path='/Cell:%s/BPMFederationConfiguration:/BPMApiFederation:/BPMApiDomain:default/BPMDispatchConfiguration:/' % cellName wsadmin>dc=AdminConfig.getid(path)
      wsadmin>dc

    3. Set the values of the denyForwardHttpHeader and denyForwardHttpCookie attributes to deny the forwarding of all headers and cookies:
      wsadmin>AdminConfig.modify(dc,[['denyForwardHttpHeader','.*']])
      wsadmin>AdminConfig.modify(dc,[['denyForwardHttpCookie','.*']])
      wsadmin>AdminConfig.save()

    4. Set the value of the allowForwardHttpHeader and allowForwardHttpCookie attributes to forward only the specified headers and cookies. For example, if you use CA SiteMinder, enter the following commands:
      wsadmin>AdminConfig.modify(dc,[['allowForwardHttpHeader',
         'SM_TRANSACTIONID|SM_SDOMAIN|SM_AUTHTYPE|SM_USER|SM_USERDN|
          SM_SERVERSESSIONID|SM_SERVERSESSIONSPEC|SM_TIMETOEXPIRE|
          SM_SERVERIDENTITYSPEC']])
      wsadmin>AdminConfig.modify(dc,[['allowForwardHttpCookie','SMSESSION']])
      wsadmin>AdminConfig.save()
      For information about the header and cookie names that are used by other third-party authentication products, see the documentation for those products.

  3. If you modified any 100Custom.xml configuration files, restart the server to activate the changes.



Security configuration properties

Use the WebSphere command-line administration tool (wsadmin) AdminConfig commands to access and modify IBM Business Process Manager security properties as configuration objects.

The term configuration object refers to an object that is accessed by using the wsadmin AdminConfig commands. See Commands for the AdminConfig object using wsadmin scripting. Configuration objects may be nested, meaning a configuration object may contain other configuration objects. For example, the BPMServerSecurity configuration object is located below two other configuration objects: BPMDeploymentTargetConfigExtension.BPMProcessServer.BPMServerSecurity.

The properties listed below are no longer configurable using the 99local.xml and 100custom.xml configuration files.

Refer to the following examples:

All of the properties listed below can be modified by replacing the previous values except for properties that are contained in the BPMActionPolicy and BPMConsoleSection configuration objects. For BPMActionPolicy, you do not modify existing values, you add and remove roles. For BPMConsoleSection, you do not modify existing values, you add and remove constraints.

IBM Business Process Manager configuration objects and security properties

Configuration object ConfigObject containment path (All editions except IBM Business Process Manager Express ) Property name Description Default value
BPMAuthAliasRoleType /Cell:<cellName>/BPMCellConfigExtension:/BPMDeploymentEnvironment:<DeName>/BPMAuthAliasRoleType:/ BPCUser, BPMAuthor, BPMUser, BPMWebserviceUser, CEIDbUser, CEIUser, CellAdmin, DeAdmin, EmbeddedECMTechnicalUser, EventManagerUser, PerformanceDWUser, ProcessCenterUser, ProcessServerUser, RALUser, SCAUser, SCADeploymentUser Refer to IBM Business Process Manager security roles for role descriptions.  
BPMActionPolicy /ServerCluster:clusterName/BPMClusterConfigExtension:/BPMPortal:/BPMActionPolicy:/BPMPolicyAction:/ ACTION_ABORT_INSTANCE, ACTION_SUSPEND_INSTANCE, ACTION_RESUME_INSTANCE, ACTION_ADD_COMMENT, ACTION_ADD_HELP_REQUEST, ACTION_RESPOND_HELP_REQUEST, ACTION_ASSIGN_TASK, ACTION_ASSIGN_AND_RUN_TASK, ACTION_REASSIGN_TASK, ACTION_REASSIGN_TASK_USER_ROLE, ACTION_CHANGE_TASK_DUEDATE, ACTION_CHANGE_INSTANCE_DUEDATE, ACTION_CHANGE_TASK_PRIORITY, ACTION_MOVE_TOKEN, ACTION_DELETE_TOKEN, ACTION_INJECT_TOKEN, ACTION_VIEW_PROCESS_DIAGRAM, ACTION_VIEW_PROCESS_AUDIT, ACTION_CHANGE_CRITICAL_PATH, ACTION_ADD_DOCUMENT, ACTION_UPDATE_DOCUMENT, ACTION_DELETE_DOCUMENT, ACTION_DELETE_INSTANCE, ACTION_FIRE_TIMER, ACTION_RETRY_INSTANCE, ACTION_SEND_EVENT Refer to Configuration properties for Process Portal action policies for property descriptions.  
BPMServerSecurity /ServerCluster:clusterName/BPMClusterConfigExtension:/BPMProcessServer:/BPMServerSecurity:/ deploySnapshotUsingHttps Used to force Process Center Server to use https to deploy ProcessApps and Toolkits to Process Servers.

This setting is ignored for Process Server runtimes 8.5.0.1 or later.

false
wildcardProcessingOptimized Used for enabling searches for user registries with/without wildcards. When set to true, optimizes searches. false
externalUserQueryLimit The maximum number of users in Process Admin Console or Process Center to be specified for any "add-user" or "look up user" activity. 100
BPMServerSecurityUsers /ServerCluster:clusterName/BPMClusterConfigExtension:/BPMProcessServer:/BPMServerSecurity:/BPMServerSecurityUsers:/ notifyError If an Event Manager task fails, a task is created for the failing task. For example, UCA execution. This property defines one or more user IDs to receive the task. Each user ID is separated from the others by a semicolon. User in DeAdmin role
userToCreateTask The user ID that is set in the task's receivedFrom field. This user must be assigned to the DeAdmin role. User in DeAdmin role
userToCloseTask The user ID that is set in a task that is cancelled by the system. This user must be assigned to the DeAdmin role. User in DeAdmin role
BPMServerSecurityGroups /ServerCluster:clusterName/BPMClusterConfigExtension:/BPMProcessServer:/BPMServerSecurity:/BPMServerSecurityGroups:/ processHelpAccess Used to request help from other process participants on a process instance or its related tasks. tw_admins
debug Specifies the role membership that users must have in order to access debugging functionality. Only one debug role can be defined. Debug
bpmAdminGroup Members of this group have full access to all interfaces, assets, servers, and security. Must have at least one user tw_admins
processCenterInstall A user must be a member of process-center-install-group in addition to having the default access. For example, to install to a process server in a production environment, a user must have administrative access to the process application that is being installed and must also be a member of process-center-install-group. None
offlineInstall Used to limit the offline installation to specific groups. None
bpmAuthorGroup Members of this group have access to the Designer and other interfaces in the Process Designer, including the Process Center console. From the Process Center console, members of this group can process applications and toolkits and control access to projects. Access to other process applications and toolkits (projects) and the assets they contain is controlled by Process Center repository administrators. tw_authors
BPMVirtualHostInfo /ServerCluster:clusterName/BPMClusterConfigExtension:/BPMProcessServer:/BPMVirtualHostInfo:/ hostname, port, transportProtocol A configuration object used with the wsadmin command to specify the host name, port number, and transport protocol of a proxy server for Process Center or Process Server configuration. The BPMVirtualHostInfo object has three properties:

  • hostname
  • port
  • transportProtocol

An example of how to specify the BPMVirtualHostInfo object with the wsadmin command is shown below in the section Modify security properties using the AdminConfig object commands.

The BPMVirtualHostInfo object replaces the base-url property that was used in the 99local.xml configuration file to specify the host name and port number of a proxy server in earlier releases of BPM.

hostname: None

port: -1

transportProtocol: https

BPMPerformanceDataWarehouse /ServerCluster:%s/BPMClusterConfigExtension:/BPMPerformanceDataWarehouse:/BPMViewManager:/BPMSystem:/ viewUser Used to create a prefix for the views that Performance Data Warehouse creates for tracking groups. Used like a schema name.  

IBM Business Process Manager Process Admin Console configuration objects and security properties

Configuration object Configuration object location Properties Description Default value
BPMConsoleSection /BPMConsoleElement:/ console.manage.caches Property to configure access to the Manage Caches link in BPM Admin section in the Server Admin area of process admin console tw_admins
console.task.cleanup Property to configure access to the Task Cleanup link in BPM Admin section in the Server Admin area of process admin console tw_admins
console.user.management Property to configure access to the User Management link in the User Management section in the Server Admin area of the process admin console tw_admins
console.group.management Property to configure access to the Group Management link in the User Management section in the Server Admin area of the process admin console tw_admins
console.bulk.user.attribute.assignment Property to configure access to the Bulk User Attribute Assignment link in the User Management section in the Server Admin area of the process admin console tw_admins
console.user.synchronization Property to configure access to the User Synchronization link in the User Management section in the Server Admin area of the process admin console

Some IBM Business Process Manager functionality requires current data from your external security provider in order to function properly. If you see unexpected results with routing of activities, team data in dashboards, or other aspects of BPM that could be caused by a lag between BPM and your external security provider, you can use the Synchronization option in the Process Admin Console to resolve those issues.

  1. Log in to the Process Admin Console.

  2. In the Server Admin area of the Process Admin Console, click the indicator next to User Management to list the available management options.

  3. Click User Synchronization.

  4. In the User Management > Synchronize window, choose one of the following options:

    • Full Synchronize

      Synchronizes BPM with all user accounts in your configured external provider.

    • Add

      Click Add, then enter a user name, and repeat this action to create a list of user names. Then click Synchronize to synchronize only the user accounts in the created list.

tw_admins
console.instrumentation Property to configure access to the Instrumentation link in the Monitoring section in the Server Admin area of the process admin console tw_admins
console.process.monitor Property to configure access to the Process Monitor link in the Monitoring section in the Server Admin area of the process admin console tw_admins
console.monitor Property to configure access to the Process Monitor link in the Event Manager section in the Server Admin area of the process admin console tw_admins, tw_authors
console.blackout.periods Property to configure access to the Blackout Periods link in the Event Manager section in the Server Admin area of the process admin console tw_admins, tw_authors
console.synchronous.queues Property to configure access to the Synchronous Queue link in the Event Manager section in the Server Admin area of the process admin console tw_admins, tw_authors
console.em.jms.error.queue Property to configure access to the EM JMS Error Queue link in the Event Manager section in the Server Admin area of the process admin console tw_admins, tw_authors
console.manage.epvs Property to configure access to the Manage EPVs link in the Admin Tools section in the Server Admin area of the process admin console tw_admins, tw_authors


Modify security properties using the AdminConfig object commands

You can use the wsadmin AdminConfig object commands to access and modify security properties. For a complete list of list of AdminConfig commands provided by WebSphere Application Server, see Commands for the AdminConfig object using wsadmin scripting.


Modify security properties in single deployment environments and IBM Business Process Manager Express


Modify security properties in multiple deployment environments

For multiple deployment environments, each cluster can be set up with different capabilities and the properties defined for a cluster are based on these capabilities. You must locate the correct cluster before accessing and modifying properties.


Access and modifying security properties using Jython scripts

The following examples are shown using Jython scripts to do get and set methods on objects and to add and remove values for the properties.

The Jython scripts work for the most commonly used scenarios, for example, -g|get and -s|set methods. For more advanced scenarios, see Commands for the AdminConfig object using wsadmin scripting.

Usage: Use this script to get/modify the configured security properties.
          -E|--de DE_name -option')
                          -g|--get property_name')
                          -s|--set property_name , new_value')
                          -a|--add console_property_name , constraint_value')
                                |action_policy_name , role to be added')
                          -r|--remove console_property_name , constraint_value')
                                |action_policy_name , role to be removed')
The property values can be accessed using the -g|get option and can be modified to have a different value by using the -s|set option. For the console properties, constraints can be added or removed to restrict access to console sections and these have their own -a|--addConstraint and -r|--removeConstraint options as shown above.


WebSphere Common Configuration Model


Configuration properties for Process Portal action policies

Action policies for Process Portal restrict actions on business processes and tasks to certain user groups. Some of these policies have default groups assigned to them. You can change the default values to fit the needs of the Process Portal users.

The configuration properties for the action policies are contained in the BPMActionPolicy configuration object. You can use the AdminConfig object commands in the wsadmin tool to change the default security group for an action policy. See Commands for the AdminConfig object using wsadmin scripting.


Prerequisites

The following conditions must be met:


Location

Start the wsadmin scripting client from the deployment_manager_profile/bin directory.


List of action policies

The following table lists the action policies and the default security group that is assigned to them. The BPMActionPolicy configuration object is an array of pairs that match each action type with the roles that can perform the action.

Process Portal action policies

Action policy Description Default security group
ACTION_ABORT_INSTANCE Permanently terminate a process instance. tw_admins
ACTION_SUSPEND_INSTANCE Temporarily deactivate a process instance. tw_admins
ACTION_RESUME_INSTANCE Resume a suspended process instance. tw_admins
ACTION_ADD_COMMENT Add comments to a process instance. None; available to all users by default
ACTION_ADD_HELP_REQUEST Request help from other process participants on a process instance or its related tasks. None; available to all users by default
ACTION_RESPOND_HELP_REQUEST Respond to help requests from other process participants. None; available to all users by default
ACTION_ASSIGN_TASK Assign a task to yourself so that only you can run the task. None; available to all users by default
ACTION_ASSIGN_AND_RUN_TASK Run a task that is assigned to a group of which you are a member. The task is automatically assigned to you. None; available to all users by default
ACTION_REASSIGN_TASK Assign a task to the group to which the task was previously assigned. None; available to all users by default

In addition, this policy is always available to members of a team of managers.

ACTION_REASSIGN_TASK_USER_ROLE Assign a task to a different user or a group. None; available to all users by default

In addition, this policy is always available to members of a team of managers.

ACTION_CHANGE_TASK_DUEDATE Change the due date of a task. tw_admins

In addition, this policy is always available to members of a team of managers.

ACTION_CHANGE_INSTANCE_DUEDATE Change the due date of a process instance. tw_admins
ACTION_CHANGE_TASK_PRIORITY Change the priority of a task as needed to escalate or de-escalate the task. tw_admins

In addition, this policy is always available to members of a team of managers.

ACTION_MOVE_TOKEN Move the token to any step in the business process definition. tw_admins
ACTION_DELETE_TOKEN Delete a token at any step in the business process definition. Required to delete ad hoc events. tw_admins
ACTION_INJECT_TOKEN Create a new token at any step in the business process definition. Required to initiate ad hoc events. tw_admins
ACTION_VIEW_PROCESS_DIAGRAM View a process diagram in the Process Performance instance dashboard. None; available to all users who have access to the process instance
ACTION_VIEW_PROCESS_AUDIT View historical data about process variables. tw_admins
ACTION_VIEW_CRITICAL_PATH Use the Process Performance instance dashboard to view the projected path of a running process instance.

The Allow Projected Path Management option must be enabled for the business process in Process Designer.

None; available to all users who have access to the process instance
ACTION_CHANGE_CRITICAL_PATH Use the Process Performance instance dashboard to change the projected path of a running process instance, and adjust the due dates of tasks in a process instance.

The Allow Projected Path Management option must be enabled for the business process in Process Designer. In addition, the user must also belong to the security group assigned to the ACTION_VIEW_CRITICAL_PATH action policy.

tw_process_owners
ACTION_ADD_DOCUMENT Add a document to a process instance. None; available to all users by default
ACTION_UPDATE_DOCUMENT Update a document that belongs to a process instance. None; available to all users by default
ACTION_DELETE_DOCUMENT Delete a document from a process instance. None; available to all users by default
ACTION_DELETE_INSTANCE Delete a process instance. tw_admins
ACTION_FIRE_TIMER Manually fire a timer. tw_admins


Modify the action policies contained in the BPMActionPolicy configuration object

The following examples are shown using Jython scripts.

  1. Start the wsadmin scripting tool:
    deployment_manager_profile\bin>wsadmin -lang jython -conntype none WASX7357I: By request, this scripting client is not connected to any server proc ess. Certain configuration and application operations will be available in local  mode.
    WASX7031I: For help, enter: "print Help.help()"
  2. Show defaults:
    wsadmin>print AdminConfig.defaults('BPMPolicyAction')
    Attribute                       Type                            Default type                            String
    roles                           String
  3. Show the BPMActionPolicy configuration ID:
    wsadmin>print AdminConfig.list('BPMPolicyAction')
    (cells/Cell1/clusters/SingleCluster|
    cluster-bpm.xml#BPMPolicyAction_1365527262431)
    (cells/Cell1/clusters/SingleCluster|
    cluster-bpm.xml#BPMPolicyAction_1365527262432)
    (cells/Cell1/clusters/SingleCluster|
    cluster-bpm.xml#BPMPolicyAction_1365527262433)
    (cells/Cell1/clusters/SingleCluster|
    cluster-bpm.xml#BPMPolicyAction_1365527262434)
    (cells/Cell1/clusters/SingleCluster|
    .
    .
  4. Determine the index for the attribute to modify:
    wsadmin>def getBPMPolicyAction(type):
    wsadmin>  policyActions = AdminUtilities.convertToList(AdminConfig.list('BPMPolicyAction'))
    wsadmin>  for policyAction in policyActions:
    wsadmin>   if AdminConfig.showAttribute(policyAction, "type") == type:
    wsadmin>      return policyAction
    wsadmin>
    wsadmin>print getBPMPolicyAction("ACTION_ABORT_INSTANCE")
    (cells/N1Cell/clusters/cluster1|cluster-bpm.xml#BPMPolicyAction_1363274323595)
    wsadmin>print AdminConfig.showAttribute(getBPMPolicyAction("ACTION_ABORT_INSTANCE"), "roles")
    tw_admins
    wsadmin>AdminConfig.modify(getBPMPolicyAction("ACTION_ABORT_INSTANCE"), [["roles", "newrole"]])
    ''
    wsadmin>print AdminConfig.showAttribute(getBPMPolicyAction("ACTION_ABORT_INSTANCE"), "roles")
    tw_admins;newrole
    wsadmin>AdminConfig.modify(getBPMPolicyAction("ACTION_ABORT_INSTANCE"), [["roles", []]])
    ''
    wsadmin>print AdminConfig.showAttribute(getBPMPolicyAction("ACTION_ABORT_INSTANCE"), "roles")
    []
    wsadmin>AdminConfig.modify(getBPMPolicyAction("ACTION_ABORT_INSTANCE"), [["roles", "tw_admin"]])
    ''
    wsadmin>print AdminConfig.showAttribute(getBPMPolicyAction("ACTION_ABORT_INSTANCE"), "roles")
    tw_admin

To save your changes, you run the AdminConfig.save command each time you modify a property.


Sample python script

Refer to the sample python script BPMSecurityConfig_sample.py for more examples on modifying the BPMActionPolicy configuration object. The sample script is located at install_home/util/Security/BPMSecurityConfig_sample.py.



Add servers to the trusted server list

Add IBM WebSphere Portal, IBM Connections, and email servers to the trusted server list so that Coaches are displayed properly.

  1. Open the administrative console and click Resources > Resource Environment > Resource Environment Provider.

  2. On the Resource environment providers page, click Mashups_ConfigService.

  3. Under Additional Properties, click Custom properties. The list of custom properties opens.

  4. Click postMessageWhiteList, add domains (including protocol, host, and port) separated by commas for the servers that to add in the Value field, and then click OK.

    For example, add the servers in the following format: https://myportal1.ibm.com:10039,https://myportal2.ibm.com,http://myportal3.ibm.com:10038,http://myportal4.ibm.com.

    Save changes to the master configuration.

  5. Synchronize nodes and restart the application server instance.



10. Configure SSL for BPM

You can enable SSL communication for BPM. This process enables secure https communication between the Process Center and the Process Server.

IBM Business Process Manager generates a default signer certificate during profile creation and uses it to sign personal certificates for all of the Java virtual machines in the cell. If you do not want to use the default signer certificate, create a personal certificate request to obtain a certificate that is signed by a certificate authority (CA). Refer to Create a certificate authority request.

To import an SSL security certificate into Integration Designer, see Import an SSL security certificate into Integration Designer.



Configure SSL communication in a network deployment environment

If you are using IBM Business Process Manager V8.5.0.0, the following steps are required to make the communication between the Process Center and the Process Server work with HTTPS in a network deployment environment.

If you are using IBM Business Process Manager V8.5.0.1, HTTPS is set as the default for communication from Process Center to Process Server.

To change to insecure HTTP, see Change to insecure HTTP communication between Process Center and Process Server.

  1. Import the Process Server WebSphere Application Server root SSL certificate into Process Center.

    1. In the Process Center WebSphere Application Server administrative console, click...

        Security | SSL certificate and key management | Key stores and certificates

      > CellDefaultTrustStore > Signer certificates > Retrieve from port.

    2. Enter the Host name, secure Port of the Process Server profile (WC_defaulthost_secure), and Alias, and click Retrieve signer information. You can retrieve the signer information for any of the servers listed.

      The WC_defaulthost_secure profile is located in the WebSphere Application Server administrative console. Navigate to Servers > Server Types > WebSphere Application Servers > SERVER_NAME > Ports.

    3. Click Apply and save your changes.

  2. Import the Process Center root SSL certificate into Process Server.

    1. In the Process Server WebSphere Application Server administrative console, click...

        Security | SSL certificate and key management | Key stores and certificates

      > CellDefaultTrustStore > Signer certificates > Retrieve from port.

    2. Enter the Host name, secure Port of the Process Center profile (WC_defaulthost_secure), and Alias, and click Retrieve signer information. You can retrieve the signer information for any of the servers listed.

      The WC_defaulthost_secure profile is located in the WebSphere Application Server administrative console. Navigate to Servers > Server Types > WebSphere Application Servers > SERVER_NAME > Ports.

    3. Click Apply and save your changes.

  3. Open WAS_HOME\bin and run the following commands on both the Process Center and the Process Server to change internal links to use HTTPS and secured port.

    You only need to run this command if you have upgraded from a version prior to 8.5.0.1.

    For example:

    wsadmin -conntype NONE -lang jython wsadmin> ps = AdminConfig.getid("/Cell:/ServerCluster:application_cluster_name/BPMClusterConfigExtension:/BPMProcessServer:/") # You must use BPMProcessCenter or BPMProcessServer depending on the environment wsadmin> print ps # See how many process servers you listed
    wsadmin> print AdminConfig.show(ps) #look at useHTTPSURLPrefixes to see the current value
    wsadmin> AdminConfig.modify(ps, [['useHTTPSURLPrefixes', 'true']])
    wsadmin> print AdminConfig.show(ps) #verify your change wsadmin> AdminConfig.save()
    wsadmin> exit 

  4. Optional: Disable all unsecured ports on all Process Center and Process Server servers.

    1. Log in to the WebSphere Application Server administrative console and navigate to Servers > Server Types > WebSphere Application Servers.

    2. For each server, click the server link, then go to Container Settings > Web Container Settings > Web container transport chains.

    3. Click each link for the unsecured port, for example, HttpQueueInboundDefault, and clear the Enabled check box.
    4. Repeat these steps for all WebSphere Application Server cluster members on all nodes. For example, if the xxx.AppTarget cluster has members on Node1 and Node2, these steps must be performed on both nodes.

  5. Optional: In the Process Center WebSphere Application Server administrative console, click Security > Global security > Web and SIP security > Single sign-on (SSO) and check the Requires SSL check box.

  6. Optional: In the Process Server WebSphere Application Server administrative console, click Security > Global security > Web and SIP security > Single sign-on (SSO) and check the Requires SSL check box.

  7. Specify HTTPS URLs and ports for all REST services for the environment by using the REST service administrative console page.

    1. Click Services > REST services > REST service providers.

    2. Select all from the Scope selection pull-down menu.

    3. Click on the REST service provider in Provider Application field and specify the Host name or virtual host in a load-balanced environment and the Port.

      For a REST Services Gateway deployment manager, use the deployment manager host name and port; do not use the IHS host name and port.

    4. Click Apply and save your changes.

  8. To make sure that Process Server connects to Process Center using SSL, specify an HTTPS URL for the processCenterUrl variable, as described in Modify Process Server connection properties .

    Note: If you are using BPM V8.5.0.1, this step is not required if you have already provided the intended processCenterUrl value when running BPMConfig.

  9. Set the deploySnapshotUsingHttps property to true to make sure the Process Center connects to the Process Server using SSL for online deployment. Run the following commands on both the Process Center and the Process Server.
    wsadmin -conntype NONE -lang jython wsadmin> ps = AdminConfig.getid("/Cell:/ServerCluster:application_cluster_name/BPMClusterConfigExtension:/BPMProcessCenter:/BPMServerSecurity:/") # You must use BPMProcessCenter or BPMProcessServer depending on the environment wsadmin> print AdminConfig.show(ps) #look at deploySnapshotUsingHttps to see the current value wsadmin> AdminConfig.modify(ps, [['deploySnapshotUsingHttps', 'true']]) # default value is false wsadmin> print AdminConfig.show(ps) #verify your change
    wsadmin> AdminConfig.save()
    wsadmin> exit 

    See below for details on the version support differences:

    • IBM Business Process Manager V8.5.0.1 and later Process Centers will use the deploySnapshotUsingHttps property setting for BPM V8.5.0.0 Process Servers.
    • IBM Business Process Manager V8.5.0.1 and later Process Centers will not use the deploySnapshotUsingHttps property setting for BPM V8.5.0.1 Process Servers. They will use the full URL, including protocol, as it was sent by the Process Server.
    • IBM Business Process Manager V8.5.0.0 Process Centers will use the deploySnapshotUsingHttps property setting for BPM V8.5.0.0 Process Servers.

  10. Restart the Process Server and Process Center servers.

    1. Use the WebSphere Application Server administrative console to stop the clusters.
    2. Stop the node agent and deployment manager.
    3. Re-start the node agent.
    4. Re-start the deployment manager.

    5. Use the WebSphere Application Server administrative console to start the clusters.

  11. Verify your configuration.

    1. Log in to the Process Center console using an https connection.

    2. From the Server tab, click runtime server > configure server and confirm that it is opened in a secure browser with https.


Change to insecure HTTP communication between Process Center and Process Server

If you are using IBM Business Process Manager V8.5.0.1, HTTPS is set as the default for communication between the Process Center and the Process Server in both Typical and Custom installations. Follow the procedure below to configure the environment to use insecure HTTP.



Configure Process Designer to access Process Center using Secure Socket Layer (SSL)

The following steps are required to make the communication between Process Designer and Process Center work using SSL.

  1. Navigate to the Process Designer installation location, for example: C:\IBM\ProcessDesigner\v8.5.0.

  2. Open the eclipse.ini file.

  3. Locate -Dcom.ibm.bpm.processcenter.url and modify it to specify the correct Process Center URL. For example, Dcom.ibm.bpm.processcenter.url=http://localhost:9080.
  4. Change http://PC_hostname:non_secured_port to https://PC_hostname:secured-port.

    Save and close the eclipse.ini file.

  5. Navigate to the sas.client.props file. For example: C:\IBM\ProcessDesigner\resources.

  6. Modify the following section to specify SSL client support.
    # Does this client support/require SSL connections? 
    com.ibm.CSI.performTransportAssocSSLTLSRequired=true
    com.ibm.CSI.performTransportAssocSSLTLSSupported=true

  7. Modify the security configuration properties using wsadmin AdminConfig. See Security configuration properties.

  8. In the WAS administrative console, click Security > Global security > RMI/IIOP Security > CSIv2 inbound communications.

  9. Verify the Propagate security attributes option is selected.

  10. Verify that Supported is selected in the Client certificate authentication drop-down menu.

  11. Verify that SSL-required is selected in the Transport drop-down menu.

  12. Add the IBM HTTP Server signer certificate to the truststore specified for the Process Designer in the eclipse.ini file:

    1. Export the IHS signer certificate from the default browser.
    2. Import the IHS signer certificate to ./etc/trust.p12 by invoking PD_HOME\AppClient\java\jre\bin\ikeyman.

    3. Navigate to the Process Designer installation location, for example: C:\IBM\ProcessDesigner\v8.5.0.

    4. Open the eclipse.ini file.

    5. Add the following line: -Djavax.net.ssl.trustStore=./etc/trust.p12.

      Save and close the eclipse.ini file.

  13. Launch Process Designer and verify access to the Process Center using SSL.

  14. If you have created and configured your own truststore, you must modify one of the following configuration files to point to the correct location for your truststore:

    • Standalone configuration: NodeDefaultTrustStore
    • Network deployment configuration: CellDefaultTrustStore

    When Process Designer is downloaded, by default a trust.p12 file will be included with the compressed file. The trust.p12 file that is included reflects what is specified for the NodeDefaultTrustStore (stand-alone server) or CellDefaultTrustStore (network deployment environment) found in the Administrator console under Global Security > SSL certificate and key management > Key stores and certificates. The information in the trust.p12 file with the password WebAS is included in the compressed file. If you have a custom truststore with a different password or have multiple truststores, the information from the custom truststore is included in the Process Designer compressed file, instead of the default truststore.

  15. Verify your configuration.

    1. Log in to the Process Designer.
    2. Right-click the Process Apps tab and select Properties.
    3. Confirm the Address: (URL) section contains the https://PC hostname:secured port secure address.


Troubleshooting and support for BPM


Configure SSL for a reverse proxy

Procedure

If you are using a reverse proxy, perform one of the following steps to import the SSL certificate for the reverse proxy:

  1. Create a trust store named trust.p12 which has the SSL certificate from the reverse proxy and put it in the BPM\Lombardi\tools\designer folder under the Process Center installation tree. The trust store must be named trust.p12, trust store must be of type PKCS12 and the trust store password must be set to WebAS.
  2. Alternatively, import the SSL certificate from the reverse proxy server into WAS (where Process Center and Process Server run). The reverse proxy certificate will be automatically included in the Process Designer download package.

    1. In the WAS administrative console, click Global Security > SSL certificate and key management >Key stores and certificates >CellTrustStore

    2. Enter the hostname and port of the reverse proxy server and click Retrieve from port.

    When Process Designer is downloaded, by default a trust.p12 file will be included with the compressed file. The trust.p12 file that is included reflects what is specified for the NodeDefaultTrustStore (stand-alone server) or CellDefaultTrustStore (network deployment environment) found in the Administrator console under Global Security > SSL certificate and key management > Key stores and certificates. The information in the trust.p12 file with the password WebAS is included in the compressed file. If you have a custom truststore with a different password or have multiple truststores, the information from the custom truststore is included in the Process Designer compressed file, instead of the default truststore.

  3. If Process Designer was installed before step 1 or 2, download Process Designer and reinstall.

11. Enable a NIST SP800-131a compliant environment

If you are using BPM V8.5.0.1+, you can configure IBM Business Process Manager to support the National Institute of Standards and Technology (NIST) SP800-131a security standard. SP800-131a requires longer key lengths and stronger cryptography than other standards, such as FIPS 140-2. SP800-131a requires Transport Layer Security (TLS) V1.2.

Your browser must support the TLS 1.2 protocol. You can use Microsoft Internet Explorer version 9 and up, Google Chrome version 31, or Opera version 12.

Opera versions 15, 16, and 17 are based on Google Chromium and do not support TLS 1.2.

  1. Generate or import certificates and activate SSL on the directory server. This step varies depending on the LDAP server you are using.

  2. Add the signer certificate of your LDAP server to the truststore of your application server.

  3. Enable the SP 800-131a standard for BPM. For updates to the administrative console, see Transitioning WAS to the SP800-131 security standard.

    In a clustered environment, before you run the syncNode.bat or syncNode.sh command, change to strict mode and update the ssl.client.props configuration file, which is at ProcessDesignerInstallation Path/resources/ssl.client.props. You are prompted to accept the self-signed certificate into the truststore before the changes can be propagated. For background information and details, refer to https://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.was_v8/was/8.0.0.3/Security/WASV8003_SecurityCryptoSignatureAlgorithm.pdf.

  4. Enable TLS V1.2 for all clients. Set the SSL protocol to be used for client applications, such as the wsadmin command or the Process Designer. For the wsadmin command, see Transitioning WAS to the SP800-131 security standard. For the Process Designer, update the ssl.client.props configuration file, which is at ProcessDesignerInstallation Path/resources/ssl.client.props.

  5. Configure SSL communication for Process Center and Process Server. See Configure SSL communication in a network deployment environment.

    After you convert the certificates to the NIST SP 800-131a standard in a clustered environment that includes a Process Center cluster and a Process Server cluster, add the Process Server signer to the Process Center truststore and add the Process Center signer to the Process Server truststore.

  6. Specify that SSL is used for EJB method calls.

    1. In the administrative console, click Security > Global security > RMI/IIOP Security > CSIv2 inbound communications.

    2. Select SSL-required in the Transport pull-down menu.

    3. In the administrative console, click Security > Global security > RMI/IIOP Security > CSIv2 outbound communications.

    4. Select SSL-required in the Transport pull-down menu.

  7. Specify HTTPS for Business Space. See Designating HTTP or HTTPS settings for Business Space.
  8. Switch the DB2 data sources to SSL.

    1. Create a CMS keystore for DB2. To create the keystore, log in to the administrative console and do the following steps:

      1. Navigate to Security > SSL certificate and key management..

      2. Click Key stores and certificates under Related Items.

      3. On the Key stores and certificates page, click Newto create a new keystore.

      4. On the New Keystore page, enter the following values and click OK to create that keystore:

        Field Value Notes
        Name DB2KeyStore  
        Path C:/SQLLIB/DB2/CertStores/DB2KeyStore.kdb Verify the directory exists.
        Password WebAS Choose an appropriate password.
        Confirm password WebAS  
        Type CMSKS Select CMSKS from the drop-down list.

      5. Add a personal certificate to the DB2 keystore.

        After the DB2 keystore is created, navigate to the DB2KeyStore page and click Personal Certificates under Additional Properties to create a personal certificate for this keystore.

      6. From the DB2 keystore's Personal Certificates page, click Create a self-signed certificate.

      7. On the configuration page for the new certificate, enter the following values and click OK.

        Field Value Notes
        Alias default  
        Common Name DB2  
        Validity period 2000 Change from 364 days to a larger number to avoid dealing with expiring certificates.
        Organization IBM  

    2. Create the SSLconfig.ini file. The database requires SSL-specific information to use SSL. For example, the keystore. This information is contained in the SSLconfig.ini file, which is located under the home directory of the instance. For example, create the SSLconfig.ini file in the C:/SQLLIB/DB2 directory and set its contents to
      DB2_SSL_KEYSTORE_FILE=C:/SQLLIB/DB2/CertStores/DB2KeyStore.kdb
      DB2_SSL_LISTENER=50443
      DB2_SSL_KEYSTORE_PW=WebAS
      DB2_SSL_KEYSTORE_LABEL=default

      The keystore is the one that you created in the previous step and the label corresponds to the alias of the self-signed certificate you created earlier. Also, the listener port is the one the database uses for SSL communication, so you must select a port that is not in use on the machine.

    3. Set the database communication protocol to SSL. To configure the database instance to use SSL, configure the DB2COMM registry variable. For example, run on the instance named DB2.

        db2set -i DB2 DB2COMM=SSL

      To configure the database to accept SSL and non-SSL connections, run:

        db2set -i DB2 DB2COMM=SSL,TCPIP

    4. Update the system path to include gsk8. DB2 uses gsk8 to provide SSL support and requires that its library is included in the system path. For example, add C:\Program Files\IBM\gsk8\lib to the Windows system path by right-clicking on My Computer and navigating to Properties > Advanced > Environmnent Variables.

    5. Restart the database to use the updated communication protocol.
      db2stop or use db2 control center.
       db2start or use db2 control center 
    6. Import the signer certificate for the database into the WebSphere Application Server truststore. Before the JDBC driver can use SSL to communicate with the database, the truststore that it uses requires the database's signer certificate. To get the signer certificate into the appropriate truststores:

      1. Navigate to Security-> > SSL certificate and key management. and click Key stores and certificates under Related Items.

      2. Click NodeDefaultTrustStore to go to the application server's default trust store.

      3. Click Signer certificates under Additional properties.

      4. On the Signer Certificates page, click Retrieve from port to retrieve the DB2's signer certificate.

      5. On the Retrieve from port page, enter the following values:

        Field Value Notes
        Host localhost Host where DB2 is running
        Port 50443 Port on which DB2 is listening for SSL communication.
        Alias db2sslSigner Alias to set for DB2's signer in this truststore.

      6. Click Retrieve signer information

    7. Set up the data source to use SSL:

      • Set the SSL port to 50443 if using the sslconfig.ini file.

      • Add the sslConnection custom property of type Boolean to the data source and set its value to true. To add this custom property, from your data source page, click Custom properties in the Additional Properties section. On the Custom properties page, click New to create the sslConnection property.

      This step assumes the sslConnection property is not already in the list of custom properties. If it is, update it and set the value to true.

  9. Switch the distribution and consistency services (DCS) transport link to SSL.

    1. In the WAS administrative console, click Servers > Core Groups > Core group settings.

    2. Click DefaultCoreGroup.

    3. Select DCS-Secure from the Channel framework pull-down menu.

      Save changes and restart the server.

  10. Disable unencrypted ports.

    1. In the WAS administrative console, click System administration > Deployment manager > Configuration > Ports.

    2. Click each instance of View associated transports.

    3. Disable each transport chain that shows Enabled in the SSL Enabled column.

      1. Click the name of the transport chain and clear the Enabled checkbox.

      2. Click OK.

      3. Click System administration > Nodes.

      4. Click each node and select the Local Topology tab.

      5. Expand the node name and expand Servers.

      6. Click the managed node and select the Configuration tab.

      7. Click Ports and click each instance of View associated transports.

      8. Disable each Transport Chain that shows Enabled in the SSL Enabled column.

      9. Click Save directly to master configuration.
      10. Stop the nodes, node agents, and deployment manager.

      11. Restart the deployment manager.
      12. Synchronize the configuration changes across each of the federated nodes by clicking System administration > Nodes. Select all the nodes and then click Full Resynchronize.

      13. Restart the node agents and nodes.



12. Configure cross-cell security for IBM Process Center

Before registering a Process Center with another Process Center in a different cell, complete security configuration. Once the security configuration between the cells is completed, a Process Center in one cell can register a Process Center in another cell with HTTPS protocol over SSL.

Before you configure a cross-cell setup, install and configure IBM Business Process Manager Advanced or IBM Business Process Manager Standard in another cell. This topic applies to the following products:

In simple proof-of-concept scenarios where you want to demonstrate Process Center registration and sharing capabilities without setting up security trust, HTTP protocol can be specified during the Process Center registration step. This type of setup assumes the same set of users exists in the user registry of both Process Centers. For proof of concept scenarios, the primary username and password should be the same on both Process Centers.

This document describes the minimum security setup required to establish trust among the cells participating in Process Center sharing. The setup in a production environment can be as simple as described here or can be more complex based on the specific security guidelines for the environment.

The security realms of the participating cells must be same. For example, they have the same set of users and groups.

  1. Configure SSL by exchanging the server SSL certificates.

    Extract the root SSL certificate from Process Center server B. Perform the following actions using the administrative console on Process Center server A.

    1. Click Security > SSL certificate and key management > Key stores and certificates > DefaultTrustStore > Signer certificates.

    2. Click Retrieve from port.

    3. Set the host name and secure socket layer port (for example, the admin host secure port) of the remote Process Center server.

    4. Specify an alias name you want to use for the root signer.

    5. Click Retrieve signer information and verify the retrieved signer information is correct.

    6. Click OK to save the root signer in the local truststore.
    7. Repeat steps 1.a through 1.f on Process Center server B to retrieve the root signer of Process Center server A.

    Alternately, Process Center administrators can extract the root signer to a file, copy the file to the file system of the other Process Center, and import the signer certificate from the file.

    If you are using a remote host to access the administrative console, the extracted certificate will be saved on the standalone server or deployment manager server, not the remote host.

  2. Share the LTPA keys.

    The following steps describe how to export the LTPA key from Process Center server B and importing it in to the keystore of Process Center server A.

    When there are multiple cells involved, one set of LTPA keys are shared among them. Because of this, administrators must:

    • Plan which set of LTPA keys to use in the organization.

    • Ensure the automatic LTPA key generation is turned off. Otherwise, the cells can fall out of synchronization for the keys if new set is generated.
    • Ensure set the "Maximum number of keys referenced" value large enough to keep the historic keys for as long as the longest lasting process instance is active. The default setting is to hold one historic LTPA key only. You can find this setting in the administrative console by navigating to Security > SSL certificate and key management > Key sets > CellLTPAKeyPair.

    See Configure LTPA and working with keys.

    1. In the administrative console of the remote Process Center server, click Security > Global Security.

    2. In the Authentication section, click LTPA.

    3. In the Cross-cell single sign-on section, enter a new Password and a Fully qualified key file name.

    4. Click Export keys then OK.
    5. Transfer the exported key file in binary mode to the file system of the local Process Center cell.

      1. In the administrative console of the remote Process Center server, click Security > Global Security.

      2. In the Authentication section, click LTPA.

      3. In the Cross-cell single sign-on section, enter a new Password and a Fully qualified key file name.

      4. Click Import keys then OK.

    6. If your setup includes additional cells, repeat the previous steps for each additional cell.

    Process Centers A and B now share the same LTPA keys.



13. Configure administrative and application security

The first step in securing your IBM Business Process Manager environment and applications is to make sure that administrative security is enabled. In WebSphere Application Server version 7.0, administrative security is enabled by default. If you have disabled administrative security, use the following instructions to enable it again.

Application security is required by IBM Business Process Manager and must not be turned off in the administrative console. Using the administrative console, you can enable administrative security, application security, and Java™ 2 security.

  1. Open the administrative security page in the administrative console.

    Expand Security and click Global security.

  2. Confirm that Enable administrative security is selected. If not, select this option.
  3. Confirm that Enable application security is selected. If not, select this option.

  4. Optional: Enable Java 2 security, if required.

    Although Java 2 security is supported, it is disabled by default. Select Use Java 2 security to restrict application access to local resources to enforce Java 2 security permission checking.

    When you enable Java 2 security, an application that requires more Java 2 security permissions than are granted in the default policy might fail to run properly until the required permissions are granted in either the app.policy file or the was.policy file of the application. Access Control exceptions are generated by applications that do not have all the required permissions. For more information about Java 2 security, see on Configuring Java 2 security policy files in the WebSphere Application Server Information Center. A related link is provided.

    Updates to the app.policy file apply only to the enterprise applications on the node to which the app.policy file belongs.

    1. Optional: Select Warn if applications are granted custom permissions. The filter.policy file contains a list of permissions that an application should not have according to the Java 2 Platform, Enterprise Edition 1.4 Specification. If an application is installed with a permission specified in this policy file and this option is enabled, a warning is issued. The default is enabled.

    2. Optional: Select Restrict access to resource authentication data. Enable this option to restrict application access to sensitive Java Connector Architecture (JCA) mapping authentication data.

  5. If you made changes to the security settings, perform these additional steps.

    1. Click Apply.

    2. Click Save.

    3. If necessary, stop and restart the server.


You must confirm that administrative security is enabled for each profile that you create.



Related concepts:

Getting started with security


Related tasks:

Configure application security

Java 2 security

Configure Java 2 security policy files


Configure administrative security

During installation, all components default to the primary administrative credentials that you provide. These default values provide basic security, but to enhance the security of the installation, configure the various components of IBM Business Process Manager with appropriate security identities. When you create an IBM Business Process Manager profile and keep Enable administrative security selected, you are prompted for a user name. This identity is used as a default for all underlying components. Configure these identities after you create profiles to further enhance your security

When you configure IBM Business Process Manager, you augment the default profile. Part of this profile augmentation process involves providing a user name and password at various portions of the response file. The user names and passwords that you provide must correspond to an identity in the user registry chosen for this profile. The user names and passwords you supply are required when you enable administrative security.

Several components of IBM Business Process Manager use authentication aliases. These aliases are used to authenticate the runtime component for access to database, and messaging engines. You can modify these aliases on the Business Integration Security page of the administrative console.

Several components of IBM Business Process Manager use authentication aliases. These aliases are used to authenticate the runtime component for access to database, and messaging engines. The profile augmentation process collects a valid user name and password used to create these aliases.



Start and stop the server

When administrative security is enabled, you must provide the appropriate user name and password to stop the server. The server will start without authentication, however, that authentication is required to access the administrative console.

Administrative security must be enabled.

Avoid trouble: If User Account Control (UAC) is enabled on some levels, the application server must be started with Administrator privileges if you are using a command prompt. Start the application server from a command prompt window that is launched by performing the following actions:

  1. Start the server.

    The following table describes the options for starting the server.

    Start the server Details
    From the First Steps user interface Click Start the server.
    From a command line Enter:

    • On Windows platforms: startserver servername
    • On Linux and UNIX platforms: startserver.sh servername

    You are not required to provide a user name and password to start the server. However, authenticate yourself if you try to launch the administrative console or perform any other administrative task. The server starts or an error message is returned.

  2. Start the server. At the command prompt in the install_dir/AppServer/bin directory, type the following text from a command line: startServer.sh servername.

    You are not required to provide a user name and password to start the server. However, authenticate yourself if you try to launch the administrative console or perform any other administrative task. The server starts or an error message is returned.

  3. Stop the server.

    The following table describes the options for stopping the server.

    Stop the server Details
    From the First Steps user interface Click Stop the server and provide a valid user name and password when prompted. The user name you provide must be in either the operator or administrator role.
    From a command line Enter:

    • On Windows platforms: stopserver servername -profileName ProfileName -username username -password password
    • On Linux and UNIX platforms: stopserver.sh servername -profileName ProfileName -username username -password password

    You are required to provide a user name and password to stop the server. If the user name and password you provide are members of the operator or administrator roles, the server will stop.

  4. Stop the server. At the command prompt in the install_dir/AppServer/bin directory, type the following text: stopServer.sh servername -username username -password password

    You are required to provide a user name and password to stop the server. If the user name and password you provide are members of the operator or administrator roles, the server will stop.

  5. Check the server stopped successfully

    The following table describes the options for verifying the server stopped correctly.

    Check the server stopped successfully Details
    From the user interface The First Steps output window details the results of your request.
    From a command line The outcome of your request is displayed in the command window from which the request was made.

  6. Check the server stopped successfully

    The outcome of your request is displayed in the command window from which the request was made.



Administrative security roles

Several administrative security roles are provided as part of the BPM installation.

There are eight roles provided as part of the administrative console. These roles grant permission to ranges of functionality on the administrative console. When administrative security is enabled, a user must be mapped to one of these roles in order to access the administrative console.

The first user to log in to the server after installation is added to the administrator role.

Administrative security roles

Administrative security role Description
Monitor A member of the monitor role can view the BPM configuration and the current state of the server.
Configurator A member of the configurator role can edit the BPM configuration.
Operator A member of the operator role has monitor privileges, plus the ability to modify the runtime state (that is, start and stop the server).
Administrator The administrator role is a combination of configurator and operator roles plus additional privileges granted solely to the administrator role. Examples include:

  • Modify the server user ID and password
  • Mapping users and groups to the administrator role

The administrator also has the permission required to access sensitive information, such as:

  • LTPA passwords
  • Keys

ISC Admins This role is available only for administrative console users and not for wsadmin users. Users who are granted this role have administrator privileges for managing users and groups in the federated repositories. For example, a user of the ISC Admins role can complete the following tasks:

  • Create, update, or delete users in the federated repositories configuration

  • Create, update, or delete groups in the federated repositories configuration

Deployer Users who are granted this role can perform both configuration actions and runtime operations on applications.
Admin Security Manager Only users who are granted this role can map users to administrative roles. Also, when fine-grained administrative security is used, only users who are granted this role can manage authorization groups.
Auditor Users who are granted this role can view and modify the configuration settings for the security auditing subsystem.

The auditor role includes the monitor role. This allows the auditor to view but not change the rest of the security configuration.

See Administrative roles in the WebSphere Application Server information center for more information.

The server ID specified when you enable administrative security is automatically mapped to the administrator role. Users or groups can be added to and removed from the administrative roles at any time through the BPM administrative console. However, a server restart is required for the changes to take effect.

Map a group or groups, rather than specific users, to administrative roles because it is more flexible and easier to administer. By mapping a group to an administrative role, adding or removing users to or from the group occurs outside of IBM Business Process Manager and does not require a server restart for the change to take effect.

The failed event manager can be operated by any user granted either the administrator or the operator role.

Selectors can be configured by any user granted either the administrator or the configurator role

In addition to mapping users or groups, a special-subject can also be mapped to the administrative roles. A special-subject is a generalization of a particular class of users.



Related concepts:

Install process application snapshots


Related tasks:

Install snapshots on a connected process server


Configure application security

Applications deployed to your IBM Business Process Manager instance require security to be built into them which will later be applied at run time. The applications that you host in your IBM Business Process Manager environment perform many business critical functions that require security. Some applications will access, transfer, or alter sensitive information ( payroll information or credit card details). Others will perform billing or inventory management. The security of these applications is vitally important.

Application security is required by IBM Business Process Manager and must not be turned off in the administrative console.

  1. Ensure that administrative security is enabled.
  2. Ensure that application security is enabled.

    1. On the administrative console, expand Security and click Global security.

    2. Select Enable application security so that IBM Business Process Manager will require authentication from users who try to access a secured application.

  3. Develop applications in Integration Designer using all appropriate security features.
  4. Deploy applications to your IBM Business Process Manager environment, assigning users or groups to appropriate security roles.
  5. Maintain the security of your IBM Business Process Manager environment.



Related tasks:

Configure administrative and application security


Enable security for additional components

When a profile is created, default values are used for security credentials. After the profile is created, the security settings can be configured using the administrative console.

The credentials that you provide must exist in the user account repository that you are using. When you create a profile, the following components of IBM Business Process Manager take the administrator user identity as a default:

The identities associated with these components are used to create authentication aliases required when security is enabled. It is important to change these identities to appropriate users from your account repository.

To create and configure the security settings for a profile, use the administrative console to complete the following steps.

  1. Display the Business Integration Security page. Expand Security, and then click Business Integration Security.

  2. For each of the component authentication aliases, provide an appropriate user name and password that is to be used as the authentication alias for this component.

    1. To select the alias to change, click its name in the Alias column. In some cases, the Alias column might not provide a link, in which case you select the check box in the Select column corresponding to the alias to edit, and click Edit.

    2. On the next page, provide the user name and password that is to be used as the authentication alias for this component.

      The credentials that you provide must exist in the user account repository that you are using.

    3. Click OK.



Related tasks:

Modify authentication aliases


14. Securing access to timetables in the Business Calendars widget

The Security Roles widget provides you with the ability to secure access to individual timetables in the Business Calendars widget. You use the Security Roles widget to assign roles to the members of an organization. It is these roles that determine the level of access to the timetables.

The Security Roles widget, which you use to administer role-based access control for the Business Calendars widget, is located in Business Space powered by WebSphere .

This role-based access is based on XACML (eXtensible Access Control Markup Language), an open standard.

What are the advantages of using the Security Roles widget role-based access control in the Business Calendars widget?

Use the Security Roles widget, you can assign a user or group to the system roles. You can also assign a user or group to the component roles associated with timetables.



Related concepts:

Getting started with security

Access control


Roles associated with a timetable

When a timetable is installed, three roles are created for that timetable-Owner, Writer, and Reader. These roles are known as component-specific roles.

How would these roles be used? Consider the case of a holiday timetable used in an organization. You want all employees to have access to the timetable, but you want to limit the number of employees who can update the timetable.

When the Holiday timetable is installed, the following roles are created:

You might assign the HolidayOwner role to the Human Resources manager, the HolidayWriter role to the Human Resources Specialists group, and the HolidayReader role to the employee group.

Figure 1. Example of roles assigned to a timetable

When you deploy a timetable, the three roles-Owner, Writer, and Reader-are created. Permission for all roles is set initially to All Authenticated. Make sure that you change this designation to assign the members of the organization to the correct roles.

You can change the membership of a role ( you can remove a member from the reader role), but you cannot change the name of a role, add or delete a role, or change the permissions associated with a role. The permissions are set as follows:

In the Security Roles widget, these timetable-related roles are also known as module roles.



System roles for the Security Roles widget

The BPMAdmin and BPMRoleManager roles are automatically created when you enable security after installing IBM Business Process Manager.



Assigning component roles

Each timetable in the Business Calendars widget has three component roles-Owner, Writer, and Reader-associated with it. You use the Security Roles widget to assign users or groups to these roles.

Verify the Security Roles widget is displayed.

The BPMRoleManager can assign users or groups to component roles.

The Owner of a timetable can also assign users or groups to the Owner, Writer, or Reader role for that timetable.

  1. To assign individual members to a module role:

    1. From the Module list, select a timetable.

    2. For a role ( the Writer role for the timetable), click the name of the role.

    3. On the right side of the page, click Add.
    4. name (or part of a name) in the Users or groups to search for field.
    5. To restrict the number of users or groups returned based on the search criteria, change the value in the Maximum result field. Set this value to 0 to return the entire result set.

    6. Click Search.

    7. From the list that is displayed, select one or more users or groups and click OK.
    8. When you have assigned all members, click Save.

  2. To assign all members to a module role:

    1. From the Module list, select a timetable.

    2. For a role ( the Reader role for the timetable), click the name of the role.

    3. Select All authenticated.

    4. Click Save.



15. Set up security for the Business Space component and Process Portal

If you are using Process Portal with the environment, you must consider security options for the Business Space component. To turn on security, set up application security and designate a user repository. To define administrators, assign a Business Space superuser role. For best results, enable security before you configure the Business Space component. If you enable security later, use the administrative console Global security administration page, to enable both administrative security and application security. On the same administrative console page, you also can designate a user account repository, including changing from the default federated repositories option to another user repository. To designate which users can perform administrator actions in Process Portal, assign the Business Space superuser role. Other security configuration might be needed for your specific environment.

Restriction: The Business Space component does not support fine-grained access control in Java 2 security.

By default, the Ajax proxy configuration used with widgets does not restrict access to any IP addresses. For convenience, the Ajax proxy is configured by default to be open, which is not secure for production scenarios. To configure the Ajax proxy so that it displays only content from selected sites or blocks content from selected sites, follow the steps at Blocking IP addresses using the Business Space Ajax proxy.


Enable security for the Business Space component

If you expect to use a secured environment, enable security before you configure Process Portal. However, if needed, you can enable security manually later. To turn on security for Process Portal enable both application security and administrative security for the Business Space component.

Before you complete this task, you must have completed the following tasks:

The Business Space component is preconfigured to ensure authentication and authorization of access. Users are prompted to authenticate when accessing Process Portal URLs. Unauthenticated users are redirected to a login page.

The Business Space component is configured to be accessed by HTTPS by default. If you prefer HTTP because Process Portal is already behind a firewall, you can switch to HTTP by running the configBSpaceTransport.py script. The configBSpaceTransport.py script has parameters to switch to either HTTP or HTTPS to change from a previous setting. See Designating HTTP or HTTPS settings for Process Portal.

To enable authenticated access to Process Portal, you must have a user registry configured and application security enabled. Authorization to spaces and page content is handled internally as part of managing spaces.

  1. For complete instructions on security, see the security documentation for BPM.

  2. For the Business Space application, on the Global security administrative console page, select both Enable administrative security and Enable application security.

  3. To enable or remove security after configuring the Business Space component with your IBM Business Process Manager profile, you must modify the noSecurityAdminInternalUserOnly property in the ConfigServices.properties file.

    The noSecurityAdminInternalUserOnly property specifies the administrator ID for Process Portal when security is disabled. By default, Business Space configuration sets the property to BPMAdministrator if security is disabled. When security is enabled, by default this property is set to the application server admin ID. To enable or remove security after configuring the Business Space component, use the application server admin ID.

    1. Modify the ConfigServices.properties file noSecurityAdminInternalUserOnly property to set it to the application server admin ID. The ConfigServices.properties file is located at profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties for a stand-alone server or deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties for a cluster.

    2. Run the updatePropertyConfig command using the wsadmin scripting client.

      For Windows, the value for the propertyFileName parameter must be the full path to the file, and all backslashes must be double, for example: AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name -propertyFileName "profile_root\\BusinessSpace\\node_name\\server_name\\mm.runtime.prof\\config\\ConfigService.properties" -prefix "Mashups_"]').

      • For a stand-alone server:

        The following example uses Jython:

        AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name
        -propertyFileName "profile_root\BusinessSpace\node_name\server_name
        \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"]')
        AdminConfig.save()

        The following example uses Jacl:

        $AdminTask updatePropertyConfig {-serverName server_name -nodeName node_name  -propertyFileName "profile_root\BusinessSpace\node_name\server_name
        \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"}
        $AdminConfig save 

      • For a cluster:

        The following example uses Jython:

        AdminTask.updatePropertyConfig('[-clusterName cluster_name -propertyFileName
         "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
        config\ConfigService.properties" -prefix "Mashups_"]')
        AdminConfig.save()

        The following example uses Jacl:

        $AdminTask updatePropertyConfig {-clusterName cluster_name -propertyFileName
         "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
        config\ConfigService.properties" -prefix "Mashups_"}
        $AdminConfig save 

    3. Restart the server.
    4. Log in to Process Portal, and reassign the owners of the default spaces to the new administrator ID.




Related tasks:

Assigning the superuser role

WAS security documentation

Selecting a registry or repository


Selecting the user repository for Process Portal

The federated repositories option is the default user account repository option for profiles. You can change the type of user account repository if needed for the environment.

Before you complete this task, you must have completed the following tasks:

To enable authenticated access to Process Portal, you must have a user registry configured and application security enabled. For information about application security, see Enable security for the Business Space component.

Considerations for using a user account registry with Process Portal:

  1. On the Global security administrative console page, under User account repository, designate either Federated repositories, Local Operating System, Standalone LDAP registry, or Standalone custom registry.

  2. Restart the server.

  3. To change the default user repository from the default Federated repositories, modify the MashupAdminForOOBSpace property in the ConfigServices.properties to designate the correct user ID (the UID property for your user repository) as the valid administrator ID.

    1. Copy the modified file into an empty folder on your system. The ConfigServices.properties file is located at profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties for a stand-alone server or deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties for a cluster. The ConfigServices.properties file is located at deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties for a cluster.

    2. Run the updatePropertyConfig command using the wsadmin scripting client.

      For Windows, the value for the propertyFileName parameter must be the full path to the file, and all backslashes must be double, for example: AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name -propertyFileName "profile_root\\BusinessSpace\\node_name\\server_name\\mm.runtime.prof\\config\\ConfigService.properties" -prefix "Mashups_"]').

      • For a stand-alone server:

        The following example uses Jython:

        AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name
        -propertyFileName "profile_root\BusinessSpace\node_name\server_name
        \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"]')
        AdminConfig.save()

        The following example uses Jacl:

        $AdminTask updatePropertyConfig {-serverName server_name -nodeName node_name  -propertyFileName "profile_root\BusinessSpace\node_name\server_name
        \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"}
        $AdminConfig save 

      • For a cluster:

        The following example uses Jython:

        AdminTask.updatePropertyConfig('[-clusterName cluster_name -propertyFileName
         "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
        config\ConfigService.properties" -prefix "Mashups_"]')
        AdminConfig.save()

        The following example uses Jacl:

        $AdminTask updatePropertyConfig {-clusterName cluster_name -propertyFileName
         "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
        config\ConfigService.properties" -prefix "Mashups_"}
        $AdminConfig save 

    3. Log into Process Portal, and reassign the owners of the default spaces to the new administrator ID.

  4. If you are using an LDAP repository with a unique LDAP field, such as mail (email address) for the login property instead of uid (user ID), modify the userIdKey property in the ConfigServices.properties file in order for searching to work in Business Space.

    1. Locate the ConfigServices.properties file at profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties for a stand-alone server or deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties for a cluster. Locate the ConfigServices.properties file at deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties for a cluster.
    2. Change the userIdKey attribute from uid to match the login property for your LDAP user repository, for example, mail.
    3. Copy the modified file into an empty folder on your system.

    4. Run the updatePropertyConfig command using the wsadmin scripting client.

      For Windows, the value for the propertyFileName parameter must be the full path to the file, and all backslashes must be double, for example: AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name -propertyFileName "profile_root\\BusinessSpace\\node_name\\server_name\\mm.runtime.prof\\config\\ConfigService.properties" -prefix "Mashups_"]').

      • For a stand-alone server:

        The following example uses Jython:

        AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name
        -propertyFileName "profile_root\BusinessSpace\node_name\server_name
        \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"]')
        AdminConfig.save()

        The following example uses Jacl:

        $AdminTask updatePropertyConfig {-serverName server_name -nodeName node_name  -propertyFileName "profile_root\BusinessSpace\node_name\server_name
        \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"}
        $AdminConfig save 

      • For a cluster:

        The following example uses Jython:

        AdminTask.updatePropertyConfig('[-clusterName cluster_name -propertyFileName
         "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
        config\ConfigService.properties" -prefix "Mashups_"]')
        AdminConfig.save()

        The following example uses Jacl:

        $AdminTask updatePropertyConfig {-clusterName cluster_name -propertyFileName
         "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
        config\ConfigService.properties" -prefix "Mashups_"}
        $AdminConfig save 

  5. To restrict logging in to Process Portal to a subset of users and groups, you can change the mapping of the Business Space Java™ EE security role.

    1. Update the user/group mapping for two enterprise applications: BSpaceEAR_node_server and mm.was_node_server (for a stand-alone server environment) or BSpaceEAR_cluster and mm.was_cluster (for a network deployment environment).
    2. Update the user/group mapping for two enterprise applications: BSpaceEAR_cluster and mm.was_cluster (for a network deployment environment).

    3. Click Applications > Application Types > WebSphere enterprise applications and select the two applications.

    4. In the right panel, under Detail Properties, select Security role to user/group mapping.
    5. Remap the businessspaceusers and Allauthenticated roles from the two applications by first removing the special subject.

    6. Click Map Special Subjects and select None.

    7. Click Map Users or Map Groups and assign each role to your selected users or groups.

    Changing the Java EE security role mapping does not affect the user/group search function in Business Space.

  6. Restart the server.
  7. Log in to Process Portal, and reassign the owners of the default spaces to the new administrator ID.


If you find the following errors in the SystemOut.log file, you might have extra attributes in your user registry that cannot be processed:

00000046 SystemErr R Caused by: com.ibm.websphere.wim.exception.WIMSystemException: CWWIM1013E 
    The value of the property secretary is not valid for entity uid=xxx,c=us,ou=yyy,o=ibm.com.
00000046 SystemErr R at com.ibm.ws.wim.adapter.ldap.LdapAdapter.setPropertyValue(LdapAdapter.java:3338)

Set the following attributes in the ConfigServices.properties file to bypass those attributes:

com.ibm.mashups.user.userProfile = LIMITED
com.ibm.mashups.user.groupProfile = LIMITED

The ConfigServices.properties file is located at profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties for a stand-alone server or deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties for a cluster.The ConfigServices.properties file is located at deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties for a cluster. After modifying the ConfigServices.properties file, run the updatePropertyConfig command using the wsadmin scripting client by following the instructions in step 4.d.

If you have Java EE security enabled in a cluster, consider tightening the entry in the server policy applied to the Business Space help location.

The Business Space help location policy is:

grant codeBase "file:${was.install.root}/profiles/profile_name/temp/node_name/-" {

permission java.security.AllPermission;

};

Tighten the policy by changing it to:

grant codeBase "file:${was.install.root}/profiles/profile_name/temp/node_name/server_name/BSpaceHelpEAR_node_name_server_name/BSpaceHelp.war/-" {

permission java.security.AllPermission;

};



Set up SSO and SSL for Process Portal

For remote environments where Process Portal, and BPM server are in different cells, set up single-sign-on (SSO) and Secure Sockets Layer (SSL) configuration manually.

Before you complete this task, you must have completed the following tasks:

If you have separate cells configured, make sure that SSO considerations are taken into account (including that LTPA keys are in sync, shared user names/realm names are in sync, and certificates are imported as appropriate). In some cases, with BPM, there might be multiple repositories in the realm, which might result in a realm-mismatch error. See Manage the realm in a federated repository configuration in the WAS documentation.

  1. If Process Portal is remote from where BPM is running, and if the node where Process Portal is running and the node where BPM is running are not in the same cell, complete manual steps to make sure that SSO is enabled. For example, if you are using more than one product, the servers are on different nodes, and you want them all to be able to work with the Business Space server, you must manually configure SSO. To enable SSO:

    1. On the administrative console for each server, open the Global security page by clicking Security > Global security. Expand Web and SIP security and click single sign-on to make sure the Enabled check box is selected.

    2. Make sure that all the nodes use the same User account repository information.
    3. Follow the steps in Import and export keys .

  2. If you are using HTTPS in the endpoints file, the endpoint location is on a different node than Process Portal, and the SSL certificate is a self-signed SSL certificate, import it.

    Verify the signers are configured in the appropriate truststores for the Process Portal server and the BPM server. See Secure communications using SSL in the WAS information center.

    For more information about SSO and SSL, see the WebSphere Application Server information center.



Designating HTTP or HTTPS settings for Process Portal

The Business Space component is configured to be accessed by HTTPS by default. You can change the protocol from the default or back to the default by running a script. When only HTTPS connections are allowed, any HTTP requests are redirected to HTTPS. This task describes how to change the protocol by running the configBSpaceTransport.py script.

  1. Locate the install_root\BusinessSpace\scripts\configBSpaceTransport.py script.

  2. If you have a stand-alone server, run one of the following commands from the dmgr_profile/bin/wsadmin.sh or dmgr_profile/bin/wsadmin.bat directory on the server:

    • To allow only HTTPS connections to Process Portal, enter the following command:
      wsadmin -lang jython -user user_name -password password
              -f configBSpaceTransport.py -httpsonly
    • To allow HTTP connections to Process Portal, enter the following command:
      wsadmin -lang jython -user user_name -password password
              -f configBSpaceTransport.py -allowhttp

    By default, the command applies to the current server and node. To specify a different location, use the optional -serverName and -nodeName parameters.

  3. If you have a network deployment environment, then depending on the locations of the BSpaceEAR and IBM_BPM_Portal applications, you run the configBSpaceTransport.py script from the dmgr_profile/bin/wsadmin.sh or dmgr_profile/bin/wsadmin.bat directory on the server one or two times:

    1. Run one of the following commands on the deployment manager profile to update the cluster where the BSpaceEAR application is deployed.

      • To allow only HTTPS connections to Process Portal, enter the following command:
        wsadmin -lang jython -user user_name -password password
                -f configBSpaceTransport.py -httpsonly
                -clusterName bspace_cluster
      • To allow HTTP connections to Process Portal, enter the following command:
        wsadmin -lang jython -user user_name -password password
                -f configBSpaceTransport.py -allowhttp
                -clusterName bspace_cluster

      Where bspace_cluster is the cluster where the Business Space application is deployed.

    2. If the IBM_BPM_Portal application is not deployed to the same cluster as the BSpaceEAR application, also run one of the following commands on the deployment manager profile to update the cluster where the IBM_BPM_Portal application is deployed.

      • To allow only HTTPS connections to Process Portal, enter the following command:
        wsadmin -lang jython -user user_name -password password
                -f configBSpaceTransport.py -httpsonly
                -clusterName application_cluster
                -bspaceClusterName bspace_cluster
      • To allow HTTP connections to Process Portal, enter the following command:
        wsadmin -lang jython -user user_name -password password
                -f configBSpaceTransport.py -allowhttp
                -clusterName application_cluster
                -bspaceClusterName bspace_cluster

      Where application_cluster is the cluster where the Process Portal application (IBM_BPM_Portal) is deployed and bspace_cluster is the cluster where the BSpaceEAR application is deployed.

The required connection protocol for Process Portal is selected.



Set up security for system REST services

To set up security for the data in the widgets based on users and groups, you must modify the users mapped to the REST services gateway application.

Before you complete this task, you must have completed the following tasks:

How you map users to a REST service provider application affects all the services for the provider.

To see the affected services, select Services > REST services > REST service providers, and select the matching provider application in the list of providers.

  1. On the administrative console, select one of the following options:

    • For a server environment, select Applications > Application types > WebSphere enterprise applications > REST Services Gateway
    • In addition, for a network deployment environment, select Applications > Application types > WebSphere enterprise applications > REST Services Gateway Dmgr

  2. In the right panel, under Detail Properties, select Security role to user/group mapping.
  3. To control access to the data in all the REST services widgets, add users and groups to the RestServicesUser role.



IBM Business Process Manager widget security considerations

Depending on the widgets you use in Process Portal for BPM, you might assign either administrative user group roles to control access to data in a widget, or you might assign an additional layer of role-based access for your widget.

As described in the following sections, the following widgets require you to consider security roles:


Administrative group roles and widgets

You control access to data in widgets with administrative group roles and the users who are assigned to the administrative group roles. To see who is assigned to these roles, open the administrative console, select Users and groups > Administrative group roles, and select a group. The Roles list is displayed.

The Business Rules widget might require changes to the administrative group roles.

For the System Health widget, the following administrative roles all have monitoring permissions, allow access to the administrative console and, therefore, allow users assigned to those roles to access data in the System Health widget:

Users who are mapped to those administrative group roles have access to the data in the System Health widget. Users who are not mapped to those roles cannot access the data in the System Health widget.


Widget role-based access

Some widgets have role-based access for their artifacts that business users created. In the Security Roles widget, you can assign users and groups to system roles or module roles that determine the level of access that members have for timetables in the Business Calendars widget. For more information about the Security Roles widget, see Security Roles widget in the BPM documentation.



Assigning the superuser role

You can assign users to be superusers (or Process Portal administrators). A superuser can view, edit, and delete all spaces and pages, can manage and create templates, and can change ownership of a space by changing the owner ID.

Before you complete this task, you must have completed the following tasks:

Assign the superuser role by using the following application server security role: Admin. Using this method gives you flexibility in assigning the role to any number of your organization's existing groups and users. It doesn't require the creation of an administrators group in the user registry for the sole purpose of acting as the focal point for the superuser.

If you already have a Business Space superuser assigned from an earlier version than V7.5, you can modify the superuser by user group instead. See Assigning the superuser by user group.



Related tasks:

Enable security for the Business Space component


Assigning the superuser by user group

You can assign users to be superusers (or Process Portal administrators) based on user groups.

Before you complete this task, you must have completed the following tasks:

If you previously used user groups to assign the Business Space superuser role, you can switch to the simpler way to assign Business Space superusers by role. See Assigning the superuser role.

A superuser can view, edit, and delete all spaces and pages, can manage and create templates, and can change ownership of a space by changing the owner ID.

If administrative security is enabled when you configure IBM Business Process Manager, consider the following information about groups and superusers:

If administrative security is not enabled when you configure IBM Business Process Manager, only the special user ID BPMAdministrator has the superuser role.

If you have a network deployment environment, you run the createSuperUser.py script to assign the superuser role: to create the user group and add members. Before you run the script:

  1. Locate the script install_root\BusinessSpace\scripts\createSuperUser.py for assigning the superuser role to a user.

  2. Open a command prompt, and change directories to the following directory: profile_root\bin, where profile_root represents the directory for the profile where BPM is installed.
  3. Type the following command: wsadmin -lang jython -f install_root\BusinessSpace\scripts\createSuperUser.py user_short_name password where user_short_name is the unique identifier for a user in Virtual Member Manager (VMM), and password is the VMM password for that user. If that user exists in VMM, the user is added to the administrator group.

    When the path contains a space, for example, if install_root is My install dir, enclose the path names in quotation marks. For example, type the following command: wsadmin -lang jython -f "\My install dir\BusinessSpace\scripts\createSuperUser.py" user_short_name_in_VMM.


To open the Business Space component, use the following URL: http://host:port/BusinessSpace, where host is the name of the host where your server is running and port is the port number for your server.

You can change the default special user group named adminstrators. Perform the following steps to check the current group name or change it to other name.

Inspect the value for the metric com.ibm.mashups.adminGroupName in the configuration file:

For Windows, when you run the updatePropertyConfig command, the value for the propertyFileName parameter must be the full path to the file, and all backslashes must be double, for example: AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name -propertyFileName "profile_root\\BusinessSpace\\node_name\\server_name\\mm.runtime.prof\\config\\ConfigService.properties" -prefix "Mashups_"]').

To change an administrative group.on a stand-alone server:

  1. Verify the group exists in the user repository.

  2. Modify the metric com.ibm.mashups.adminGroupName in the configuration file profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties.

  3. Run the command updatePropertyConfig in the wsadmin environment of the profile:$AdminTask updatePropertyConfig {-serverName server_name -nodeName node_name -propertyFileName "profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"} and run $AdminConfig save.

  4. Restart the server.

To change an administrative group.on a cluster:

  1. Verify the group exists in the user repository.

  2. Modify the metric com.ibm.mashups.adminGroupName in the configuration file deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties.

  3. Run the command updatePropertyConfig in the wsadmin environment of the deployment environment profile:$AdminTask updatePropertyConfig {-clusterName cluster_name -propertyFileName "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"} and run $AdminConfig save.

  4. Restart the deployment manager.

To change the superuser when security is not enabled.on a stand-alone server:

  1. Modify the metric noSecurityAdminInternalUserOnly in the configuration file profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties.

  2. Run the command updatePropertyConfig in the wsadmin environment of the profile:$AdminTask updatePropertyConfig {-serverName server_name -nodeName node_name -propertyFileName "profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"} and run $AdminConfig save.

  3. Restart the server.

To change the superuser when security is not enabled.on a cluster:

  1. Modify the metric noSecurityAdminInternalUserOnly in the configuration file deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties.

  2. Run the command updatePropertyConfig in the wsadmin environment of the deployment environment profile:$AdminTask updatePropertyConfig {-clusterName cluster_name -propertyFileName "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"} and run $AdminConfig save.

  3. Restart the deployment manager.



Preventing users from creating spaces

You can customize IBM Business Process Manager so that only users logging in with a superuser role can create spaces. By default, all users can create spaces. However, you can lock down Process Portal so that only people who log in using a superuser ID can create or import spaces.

The lock-down procedure described in this topic applies only to Process Portal spaces. It does not restrict other access to Process Portal.

These superusers (or Process Portal administrators) can create a space and transfer ownership to other users. The users who are assigned ownership of spaces can then administer the spaces as if they had created them. For example, they can set who can view and edit the space and its properties and they can add pages. Other than the superuser role, you cannot define groups or individual users who are allowed to create spaces.

To limit creating spaces to superusers only.

  1. Change the com.ibm.mashups.lockeddown setting to true in the configuration file:

    • For a stand-alone server: profile_root\BusinessSpace\node_name\server_name\mm.runtime.prof\config\ConfigService.properties

    • For a cluster: deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\config\ConfigService.properties

    The default value of false means that all users can create spaces. When the value is true, only superusers can create spaces.

  2. Run the updatePropertyConfig command in the wsadmin environment of the profile:

    • For a stand-alone server:

      The following example uses Jython:

      AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name
      -propertyFileName "profile_root\BusinessSpace\node_name\server_name
      \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"]')
      AdminConfig.save()

      For Windows, the value for the propertyFileName parameter must be the full path to the file, and all backslashes must be double, for example: AdminTask.updatePropertyConfig('[-serverName server_name -nodeName node_name -propertyFileName "profile_root\\BusinessSpace\\node_name\\server_name\\mm.runtime.prof\\config\\ConfigService.properties" -prefix "Mashups_"]').

      The following example uses Jacl:

      $AdminTask updatePropertyConfig {-serverName server_name -nodeName node_name  -propertyFileName "profile_root\BusinessSpace\node_name\server_name
      \mm.runtime.prof\config\ConfigService.properties" -prefix "Mashups_"}
      $AdminConfig save 

    • For a cluster:

      The following example uses Jython:

      AdminTask.updatePropertyConfig('[-clusterName cluster_name -propertyFileName
       "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
      config\ConfigService.properties" -prefix "Mashups_"]')
      AdminConfig.save()

      The following example uses Jacl:

      $AdminTask updatePropertyConfig {-clusterName cluster_name -propertyFileName
       "deployment_manager_profile_root\BusinessSpace\cluster_name\mm.runtime.prof\
      config\ConfigService.properties" -prefix "Mashups_"}
      $AdminConfig save 

The next time that users log in to a Process Portal space, they will not be able to create a space unless they log in using a superuser ID.



Enable searches for user registries without wildcards

If your user registry is set up to not use wildcards, complete additional configuration steps so that searches work properly in Process Portal, and for widgets that search the user registry.

Before you complete this task, you must have completed the following tasks:

By default, when a Process Portal user searches for users or groups by typing one or more characters, Process Portal automatically adds wildcard characters. For example, if the user registry is an LDAP server and the user types smit, Process Portal converts this into a *smit* query so the return includes names like Smith, Smithers, and Psmith. However, if you do not want the automatic wildcards because, for example, your user registry does not permit them, you can disable this functionality.

To turn off the automatic wildcard searches for the environment.



16. Security in human tasks and BPEL processes

There are a number of roles associated with human tasks and BPEL processes. These roles are unique to tasks and processes that run in Business Process Choreographer.

Human tasks, by definition, require human intervention to complete them. Some business processes might also require human intervention. These human tasks and business processes are developed using Integration Designer and are invoked using Business Process Choreographer. When you develop the task or process, assign roles to users or groups involved in the human tasks and BPEL processes.

The Human Task Manager uses the roles to determine the users' capabilities on a production system.



Authorization roles for BPEL processes

A role is a set of people who share the same level of authorization. Actions that you can take on BPEL processes depend on your authorization role. This role can be a Java EE role or an instance-based role.


Related concepts:

Authorization roles for human tasks

People resolution


Java EE roles for BPEL processes

Java EE roles are set up when Business Process Choreographer is configured. For Java EE role-based authorization, you must have a user registry configured and application security enabled.

The following Java™ Platform, Enterprise Edition (Java EE) roles are supported for processes:

You can use the administrative console to change the assignment of users and groups to these roles.

You can use Security Authorization Facility (SAF)-based authorization ( using the RACF EJBROLE profile) to control access by a client to Java EE roles in EJB and enterprise applications, including the process container.


Administrative security roles

Commands to implement roles and user assignments


Instance-based authorization roles for BPEL processes and activities

A set of predefined authorization roles is provided for BPEL processes and activities. You can assign these roles when you model the process. The association of users to instance-based roles is determined at run time using people resolution.


Authorization roles for actions on BPEL processes

The people assigned to process roles are authorized to perform the following actions:

Role Authorized actions
Process starter View the properties of the associated process instance, and its input and output messages.
Process reader View the properties of the associated process instance, and its input and output messages. Members of this role also automatically become the reader for activities, and the inline to-do tasks (including the subtasks, follow-on tasks, and escalations) that are associated with human task activities.
Process administrator Administer process instances, intervene in a process that has been initiated, create, delete, and transfer work items, change the navigation of the process at run time, for example, by skipping activities. Members of this role also automatically become the administrator for activities, and the inline to-do tasks (including the subtasks, follow-on tasks, and escalations) that are associated with human task activities.
Process activity administrator Repair activities in a process.
Scope reader View the properties of the activities and variables in the scope. Members of this role also automatically become the reader for the properties of activities, and the inline to-do tasks (including the subtasks, follow-on tasks, and escalations) that are associated with human task activities in the scope.
Scope administrator Administer the activities in the scope, including updating variables for activities, skipping activities, and canceling skip requests. Members of this role also automatically become the administrator for activities, and the inline to-do tasks (including the subtasks, follow-on tasks, and escalations) that are associated with human task activities in the scope.

The process starter is a role used by Business Flow Manager for process navigation and the invocation of external services. If a process instance still exists in the database, do not delete the user ID of the process starter from your user registry so the navigation of the process can continue, unless you have transferred the process ownership to another user.

Users are assigned to these roles using human tasks.

Role People assignment
Process starter The process starter can be specified by assigning an inline human task to the initiating receive or pick (receive choice) activity of a process.
Process reader The process reader is specified by setting the reader role on the administration task that is associated with the process. This role is inherited by all of the activities in the process.
Process administrator The process administrator is defined by an administration task that is assigned to the process. This role is inherited by all of the activities in the process.
Process activity administrator The process activity administrator is defined by an administration task that is associated with the process. The administrator role defined on this task is also used as the process activity administrator.

This administration task is different from the one used to determine the process administrator.

The activity administration task defined on the process level is the default administration task for activities that do not have an administration task defined.

Scope reader The scope reader is specified by setting the reader role on the administration task that is associated with the scope. This role is inherited by all of the activities in the scope.
Scope administrator The scope administrator is defined by an administration task that is assigned to the scope. This role is inherited by all of the activities in the scope.

If process administration is restricted to system administrators, then instance-based administration is disabled. This means that administrative actions on processes, scopes, and activities are limited to users in the BPESystemAdministrator role. In addition, reading, viewing, and monitoring a process instance or parts of it can only be performed by users in the BPESystemAdministrator or BPESystemMonitor roles. For more information about this administration mode, see Alternative administration modes for BPEL processes.


Authorization roles for actions on activities

When you model a human task, and include it as a human task activity in a BPEL process, the owner of the task automatically becomes the activity owner. Members of roles that are defined for a human task inherit the same role on the corresponding human task activity. Business Flow Manager uses the activity roles for navigation and authorization. The potential starters of an inline invocation task are the potential starters of the associated receive or pick (receive choice) activity, or the event handler.

The instance-based roles for activities are authorized to perform the following actions:

Role Authorized actions
Activity reader View the properties of the associated activity instance, and its input and output messages.
Activity editor Actions that are authorized for the activity reader, and write access to messages and other data associated with the activity.
Potential activity starter Actions that are authorized for the activity reader. Members of this role can send messages to receive or pick activities.
Potential activity owner Actions that are authorized for the activity reader. Members of this role can claim the activity.
Activity owner Work on and complete an activity. Members of this role can transfer their work items to an administrator or a potential owner.
Activity administrator Repair activities that are stopped due to unexpected errors, and force complete long-running activities.


Default people assignments for process roles

Default people assignments are performed if you do not define people assignment criteria for certain roles, or if people resolution fails or returns no result. The following table shows which defaults apply.

Roles for BPEL processes If the role is not defined in the process model ...
Process administrator Process starter becomes process administrator
Process reader No reader

In addition, if you do not define an invocation task to create and start the BPEL process, the default people assignment criteria, Everybody, is used for the potential starters of the process.



Authorization for creating and starting BPEL processes

The set of users that are allowed to create and start a BPEL process is determined by the invocation task that is associated with the receive or pick (receive choice) activity used to create and start a new process instance, and also by the administration task that is associated with the process. The process inherits the roles that you assign to these tasks.

In addition, when the process is called by a Service Component Architecture (SCA) client, you can restrict the set of users allowed to start the process by setting specific SCA security qualifiers when you install the process.

You can use human tasks in the following ways to create and start BPEL processes:

If an administration task is assigned to the process, the administrator role of the administration task is inherited by the process. A process administrator can perform various actions on the process, including creating and starting a process instance.



Related concepts:

Authorization for interacting with a BPEL process


Authorization for interacting with a BPEL process

A long-running BPEL process can have multiple receive activities, pick (receive choice) activities, and event handlers. These are served by submitting a request to the appropriate operation of the corresponding process instance. The process instance is identified implicitly by providing a unique correlation set instance in the request according to the correlation set defined in the process model.

A receive or pick activity can be used to create a process instance. So, interacting with an existing process instance by submitting a request to a process is similar to starting a new process instance.

The set of users that are authorized to submit a request to a process instance is determined by the invocation task that is associated with the receive or pick activity, or the event handlers, and by the administration task that is associated with the process.

You can use human tasks in the following ways to interact with a process instance:

If a process uses the same operation in different receive, pick (receive choice) activities, or event handlers, and the receiving process instance is currently not expecting a request, because the corresponding receive or pick (receive choice) activity is not yet waiting or the event handler is not yet active, then the user sending the request must be authorized to send a request to all of these activities and event handlers, otherwise the request will be rejected.



Related concepts:

Authorization for creating and starting BPEL processes


Authorization for administering BPEL processes

You can use administration tasks to authorize a user, or group of users, to perform administrative actions on BPEL processes and their associated activities

If you are using one of the alternative process administration modes, administration tasks might not be created. In addition, administrative actions on processes, scopes, and activities might be limited to users in the BPESystemAdministrator role. For more information about alternative administration modes, see Alternative administration modes for BPEL processes.


Process administration

To define which users are allowed to perform administrative actions and to read the process data, you can specify an administration task as part of a long-running BPEL process. The administrator and reader roles for the administration task determine who is the process administrator and the process reader. The process administrator can, for example, terminate the process instance.

An administration task is associated with every BPEL process. If an administration task is not modeled for the process, a default administration task is created at run time. This default task defines the process starter as the process administrator, and does not assign any readers to the process.


Scope administration

You can model an administration task for the scope that defines scope readers and scope administrators. A scope reader is allowed to view local variables. Scope administrators are allowed to repair activity instances in the scope, and to view and update local variables. If the scope is enclosed in another scope, the scope reader and administration rights are inherited by the enclosing scope. Scope readers and administrators also become readers and administrators of the activities in the scope.


Activity administration

The administrator role for an activity administration task determines who is allowed to administer the corresponding activity. The activity administrator can, for example, restart the activity. The administration task is created as soon as administrative actions, that is, restart or complete, can be performed on the activity instance. Reader and administrator roles of the process, and reader and administrator roles of the enclosing scopes are automatically propagated to the activities.

In addition, you can model administration tasks for activities in the following ways:



Authorization roles for human tasks

Actions that you can take on human tasks depend on your authorization role. This role can be a system-level Java EE role or an instance-based role. Role-based authorization requires that administration and application security is enabled for the application server.


Related concepts:

Authorization roles for BPEL processes


Java EE authorization roles for human tasks

System-level Java EE roles are set up when Human Task Manager is configured.

The following Java™ Platform, Enterprise Edition (Java EE) roles are supported:

You can use the administrative console to change the assignment of users and groups to these roles.

You can use Security Authorization Facility (SAF)-based authorization ( using the RACF EJBROLE profile) to control access by a client to Java EE roles in EJB and web applications, including the task container.


Administrative security roles

Commands to implement roles and user assignments


Instance-based authorization roles for human tasks

A task instance or an escalation instance is not assigned directly to a person, instead it is associated with predefined roles to which people are assigned. Anyone that is assigned to an instance-based role can perform the actions for that role. The association of users to instance-based roles is determined either by people assignment, or as the result of task actions.

People are assigned to the following roles at run time by people assignment based on the user and user group information that is stored in a people directory: potential creator, potential starter, potential owner, reader, editor, administrator, and escalation receiver. The following roles are associated with only one user and are assigned as the result of a task action: originator, starter, owner.

These roles are authorized to perform the following actions:

Role Authorized actions
Potential creator Members of this role can create an instance of the task. If a potential instance creator is not defined for the task template, then all users are considered to be a member of this role.
Originator The person with this role has administrative rights until the task starts. When the task starts, the originator has the authority of a reader and can perform some administrative actions, such as suspending and resuming tasks, and transferring work items.
Potential starter Members of this role can start an existing task instance. If a potential starter is not specified for stand-alone tasks, the originator becomes the potential starter. For inline invocation tasks without a potential starter, the default is everybody.
Starter The person with this role has the authority of a reader and can perform some administrative actions, such as transferring work items.
Potential owner Members of this role can claim a task. If a potential owner is specified, then all users are considered to be members of this role. If people resolution fails for this role, then the administrators are assigned as the potential owners.
Owner The person with this role works on and completes a task.
Reader Members of this role can view the properties of all of the task objects, but cannot work on them.
Editor Members of this role can work with the content of a task, but cannot claim or complete it.
Administrator Members of this role can administer tasks, task templates, and escalations.
Escalation receiver Members of this role have the authority of a reader for the escalation and the escalated task.

If process administration is restricted to system administrators, then instance-based administration is disabled. This means that administrative actions on processes, scopes, and activities are limited to users in the BPESystemAdministrator role. In addition, reading, viewing, and monitoring a process instance or parts of it can only be performed by users in the BPESystemAdministrator or BPESystemMonitor roles. For more information about this administration mode, see Alternative administration modes for BPEL processes.



Related reference:

Predefined people assignment criteria

Customizing people assignment criteria in Integration Designer


Instance-based authorization roles for work baskets and business categories

A work basket instance or business category instance is not assigned directly to a person, instead it is associated with predefined roles to which people are assigned. Anyone that is assigned to an instance-based role can perform the actions for that role. The association of users to instance-based roles is determined by people assignment.

In addition, when a work basket is defined in Business Space, task roles can also be defined for the tasks that are assigned to the work basket.


Instance-based roles for work baskets

These roles are authorized to perform the following actions. There is no default people assignment for any of these roles.

Instance-based authorization roles for work baskets

Role Authorized actions
Reader Members of this role can view the work basket settings.
Opener Members of this role can open the work basket and view its tasks.
Distributor Members of this role can distribute tasks from this work basket to one of its defined distribution targets.
Transfer initiator Members of this role can transfer tasks out of the work basket.
Appender Members of this role can add tasks to the work basket.

In addition to these roles, you can define custom roles for work baskets in Business Space that can be leveraged by your enterprise applications.

The following task roles can also be specified for a work basket. These roles extend any roles that are defined for the tasks in IBM Integration Designer. All the tasks in the work basket inherit these roles.

Instance-based authorization roles for tasks in work baskets

Work basket role Extends this task role Authorized actions
Task reader Reader Members of this role can view the properties of the tasks in the work basket, but they cannot work on them.
Task editor Editor Members of this role can work with the content of a task, but cannot claim or complete it.
Task potential owner Potential owner Members of this role can claim a task. If a potential owner is specified, then all users are considered to be members of this role.
Task administrator Administrator Members of this role can administer the tasks in the work basket.


Instance-base role for business categories

This role is authorized to perform the following actions. There is no default people assignment for this role.

Instance-based authorization role for business categories

Role Authorized actions
Reader Members of this role can view the business category settings.



Task kinds and instance-based authorization roles

Instance-based authorization roles are associated with human tasks and escalations when the task is modeled. The task kind determines whether a specific authorization role is available for a task.

Role To-do tasks Invocation tasks Collaboration tasks Administration tasks Comments
Potential instance creator X X X People who are allowed to create task instances
Originator X X X The person who created the task
Potential owner X X People who can claim and work with tasks
Owner X X The person who claimed the task
Potential starter X People who are allowed to start the task
Starter X The person who started the task
Administrator X X X X1 People who are allowed to administer a task
Editor X X People who are allowed to edit task data
Reader X X X X2 People who are allowed to see task data
Escalation receiver X3 X3 X3 X3 People who receive an escalation

Notes:

  1. This role also has authorization for administrative actions on the administered process, scope, or activity
  2. This role also has authorization for read operations on the administered process, scope, or activity
  3. This role has authorization for read operations on the corresponding task

If you are using one of the alternative process administration modes, administration tasks might not be created. In addition, administrative actions on processes, scopes, and activities might be limited to users in the BPESystemAdministrator role. For more information about alternative administration modes, see Alternative administration modes for BPEL processes. For more information about this administration mode, see Alternative administration modes for BPEL processes.



+

Search Tips   |   Advanced Search