WebSphere Process Server Change The User Registry From Standalone LDAP To Virtual Member Manager. A step by step guide

Size: px

Start display at page:

Download "WebSphere Process Server Change The User Registry From Standalone LDAP To Virtual Member Manager. A step by step guide"

Piers Ellis
5 years ago
Views:

1 WebSphere Process Server Change The User Registry From Standalone LDAP To Virtual Member Manager A step by step guide May 2009 IBM Corporation,

2 Disclaimer This document is subject to change without notification and will not comprehensively cover the issues encountered in all customer situations. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. For updates or newer releases please contact the service team. The Author This document is produced by the Business Process Choreographer team in Böblingen Germany. Torsten Wilms IBM Software Group, Application and Integration Middleware Software BPM Suite Integration Quality Assurance Bernd Breier IBM Software Group, Application and Integration Middleware Software BPM Suite Integration Quality Assurance 2

3 Introduction This document describes how to move the WebSphere Process Server User Registry from standalone LDAP (in this case Tivoli Directory Server) to Virtual Member Manager (VMM). Following scenario is described in this document: As-Is situation: standalone WebSphere Process Server is configured with a standalone LDAP (Tivoli Directory Server) as User Registry Staff Plugin Provider (People Resolution) is configured for standalone LDAP long-running process instances and participating human tasks are in state running The standalone WebSphere Process Server will be migrated to WebSphere Process Server The WebSphere Process Server User Registry will be moved from standalone LDAP to Virtual Member Manager People Resolution for running Human Task instances will stay on standalone LDAP Detailed information for WebSphere Process Server Version migration can be found in the Information Center: topic=/com.ibm.websphere.wps.612.doc/doc/welcome_wps_mig.html 3

4 Users and groups used in this scenario The LDAP contains the following groups, users and object classes: Group Users Object class cn=approvers,ou=groups,dc=ib m,dc=com uid=approver1,ou=people,dc=ibm,dc=com groupofuniquenames uid=approver2,ou=people,dc=ibm,dc=com groupofuniquenames cn=users,ou=groups,dc=ibm,dc =com uid=user1,ou=people,dc=ibm,dc=com uid=user2,ou=people,dc=ibm,dc=com inetorgperson inetorgperson cn=wpsadmin,ou=groups,dc=ib m,dc=com uid=wpsadmin,ou=people,dc=ibm,dc=com inetorgperson Sample application As a sample application a simple SCA Module with a long-running BPEL process and two Human Tasks (one invocation task and one participating task) is used. This application is deployed on the server and process instances and Human Tasks are running. 4

5 Settings for the invocation task: Potential Starter Staff Group: Group Potential Starter Parameters: GroupID: cn=users,ou=groups,dc=ibm,dc=com JNDI name of staff plugin configuration: bpe/staff/sampleldapconfiguration 5

6 Settings for the participating task: Potential Starter Staff Group: Group Potential Starter Parameters: GroupID: cn=approvers,ou=groups,dc=ibm,dc=com JNDI name of staff plugin configuration: bpe/staff/sampleldapconfiguration 6

7 WebSphere Process Server server configuration Before moving from standalone LDAP to Virtual Member Manager, this chapter describes the as-is configuration of the WebSphere Process Server server in a high-level manner. Following relevant configuration parameters are set: Global Security is enabled Active user registry: LDAP user registry 7

8 The LDAP User Registry settings are displayed in the figure below: 8

9 The LDAP User Registry Advanced settings are displayed in the figure below: 9

10 The Staff Plugin Provider is configured as shown below: 10

11 WebSphere Process Server System Status Following Human Tasks are is state Ready or Claimed: 11

12 Migrate to WebSphere Process Server Version Follow the Information Center to migrate to WebSphere Process Server topic=/com.ibm.websphere.wps.612.doc/doc/welcome_wps_mig.html Configure Virtual Member Manager after migration (WebSphere Process Server 6.1.2) In the Integrated Solution Console click Security->Secure administration, applications, and infrastructure The Available realm definitions is set to Standalone LDAP registry 12

name and select as the Server user identy Automatically.

13 Change the Available realm definitions to Federated repositories and click Configure Enter the Realm name, the Primary administrative user name and select as the Server user identy Automatically. Automatically is the recommended setting since Websphere Application Server Version

14 Click Add Base entry to Realm to add the LDAP as repository. Click Add Repository 14

15 1. Enter a Repository identifier. 2. Select IBM Directory Server Version 6 as the Directory type 3. Enter the Primary host name 4. Verfiy the login property is set to the correct value (in this case uid) 5. Click Apply 15

16 Under Additional Properties click Group attribute definition 1. For performance reasons it is recommended to set the Name of the group membership attribute (to ibm-allgroups, if you use Tivoli Directory Server) 2. Select All - Contains all direct, nested, and dynamic members 3. Click Apply 4. Click Member attributes 16

Refer to chapter Users and groups used in this scenario). 2. Click OK. 1.

17 1. Verify that the LDAP member attributes match the LDAP configuration and optional add a new entry (e.g uniquemember with the object class groupofuniquenames, which is the object class we used in our LDAP. Refer to chapter Users and groups used in this scenario). 2. Click OK. 1. Navigate to Secure administration, applications, and infrastructure > Federated repositories > <yourrepository> 2. Click Group attribute definition 17

18 1. Navigate back to Secure administration, applications, and infrastructure > Federated repositories > Repository reference 2. Enter the DN for the base entry. Click Apply and save. 18

19 1. Navigate back to Secure administration, applications, and infrastructure > Federated repositories > Repository reference 2. Enter the Distinguished name of a base entry that uniquely identifies this set of entries in the realm 3. Enter the Distinguished name of a base entry in this repository 4. Click Apply and save. What you have actually done here is define a mapping between a LDAP subtree root and a virtual realm root (base) entry, so that all objects from the LDAP under that subtree appear to be in the logical realm under the defined base entry. 19

20 Navigate to Secure administration, applications, and infrastructure > Federated repositories and click Supported entity types 20

21 Review the settings to verify that they match your ldap configuration On the Secure administration, applications, and infrastructure page make sure the Available realm definitions is set to Federated repositories and click Set as current. 21

Post Migration Note: If you have written a client that uses Business Process Choreographer APIs without first authenticating the user, you should modify the client to perform a login before using

x behavior of not requiring a login when application security is enabled.

22 Post Migration Note: If you have written a client that uses Business Process Choreographer APIs without first authenticating the user, you should modify the client to perform a login before using the APIs. After migration, the J2EE roles BPEAPIUser and TaskAPIUser are set to the value Everyone, which maintains backward compatibility by maintaining the 6.0.x behavior of not requiring a login when application security is enabled. After you have fixed your client, you must change these roles to the value AllAuthenticated to prevent unauthenticated users accessing the APIs. For new installations these roles default to the value AllAuthenticated. Refer to topic=/com.ibm.websphere.wps.612.doc/doc/cmig_vtv_bpc_cons.html 22

Conclusion The running Human Tasks in this scenario still use the LDAP people directory provider, even if Virtual Member Manager has been set as WebSphere Application Server security provider.

23 Conclusion The running Human Tasks in this scenario still use the LDAP people directory provider, even if Virtual Member Manager has been set as WebSphere Application Server security provider. Note that the specification of a people directory provider is a Business Process Container level setting which is defined as part of the task template. If you want to use Virtual Member Manager as the people directory provider for a task, you have to define Virtual Member Manager as people directory provider on the task template at design time in WebSphere Integration Developer. In addition, Virtual Member Manager (Federated Repositories)has to be set as WebSphere Application Server security provider using the WebSphere Application Server Integrated Solution Console. To verfiy the settings click on People directory provider > LDAP People Directory Provider > People directory configuration > LDAP People Directory Configuration sample > Custom properties 23

IBM WebSphere Developer Technical Journal: Expand your user registry options with a federated repository in WebSphere Application Server V6.

IBM WebSphere Developer Technical Journal: Expand your user registry options with a federated repository in WebSphere Application Server V6.1 Using the Virtual Member Manager Skill Level: Intermediate