Managing roles when utilizing LDAP Registry with Strict Access Controls in the Rational solution for Collaborative Lifecycle Management

Sudarsha Wijenayake, IBM Rational Software
Last updated: March 14, 2013
Build basis: Rational Solution for Collaborative Lifecycle Management (CLM)

Rational solution for Collaborative Lifecycle Management (CLM) applications such as Jazz Team Server (JTS), Rational Team Concert (RTC), Rational Quality Manager (RQM) and Rational Requirement Composer (RRC) make use of the following five identifiers which represent groups of permissions called roles: JazzAdmins, JazzDWAdmins, JazzUsers, JazzGuests and JazzProjectAdmins. These roles represent predefined sets of permissions for performing operations within the CLM applications. A user who is assigned these roles inherits the permissions associated with that particular role.

The CLM applications allow utilizing an external LDAP registry for managing users. In this scenario, LDAP group definitions are typically associated with each role. If a user is a member of the LDAP group associated with a role, then the user will inherit the permissions for that role. Usually, a dedicated group is created in the LDAP registry for each role and then that group is associated with the role. The users in the LDAP registry requiring a given role in the CLM applications are then added as members to the corresponding LDAP group.

Having a dedicated LDAP group per each role may not be feasible in certain situations. Furthermore, with a large centrally managed LDAP registry, only a subset of users may require using the CLM applications. In addition, only a handful of users may be administrators of the CLM applications. With a centrally managed LDAP registry, the registry is typically governed with strict access controls which can make it difficult or impossible to create a new LDAP group for each role. Managing the roles for CLM applications by frequently altering the memberships of the associated LDAP groups may also be difficult or impossible. This document illustrates a technique that one may utilize to configure a CLM environment without requiring an LDAP group to be created for and associated with each role. The particular technique minimizes the amount of administration necessary in the LDAP registry while allowing a subset of all LDAP users to access the CLM applications.

The following is a visual representation of this technique.

Procedure

1. Imagine your LDAP registry contains a hierarchy of groups as shown below.

Four group definitions exist in the LDAP registry mentioned above. While the Group-1 contains all users in the registry, the Group-4 only contains the users who require utilizing the CLM applications (CLM users). Ideally, a group solely containing CLM users (similar to Group-4) should be created in the LDAP registry. In a situation where creating and maintaining such a group is not feasible, an existing group definition containing all CLM users and the smallest number of other users (similar to Group-3) must be chosen for this purpose. In this example, it is assumed that creating the Group-4 is not feasible and therefore, the Group-3 is chosen instead.

2. Enable LDAP as the user registry on the application server. In other words, the application server should be configured to utilize the LDAP registry for managing its users. Please refer to the user manual of the application server for the instructions.

3. Install the CLM applications such as Jazz Team Server (JTS), Rational Team Concert (RTC), Rational Quality Manager (RQM) and/or Rational Requirement Composer (RRC) on the application server.

4. Deploy the CLM applications on the application server.

5. Configure the roles (which is referred to as the security roles in the manuals of most applications servers) of the deployed CLM applications as described below: (the applications are: jts_war, ccm_war and qm_war).

The role JazzUsers should be mapped to the group in the LDAP registry mentioned in step 1 which contains all CLM users and the smallest number of other users in the LDAP registry. In this example, an LDAP group named Group-3 is considered to be this group as stated above. The LDAP users Cid I. Oreo, Deon T. Adminio and John Doe are members of the LDAP group Group-3.
A handful of LDAP users should be granted (at least one user must be granted) the following administrative roles by mapping each individual user to the particular security roles: JazzAdmins, JazzDWAdmins and JazzProjectAdmins. These users are referred to as CLM administrators in this document and are responsible for performing the following administrative duties in the CLM applications
- completing the application setup
- creating projects
- installing licenses
- importing users from the LDAP registry
- archiving old users
- assigning licenses to users …etc.
In this example, the LDAP user Cid I. Oreo (uid=cio) is considered a CLM administrator and mapped to the following security roles: JazzAdmins, JazzDWAdmins and JazzProjectAdmins.
Please note that the project administrators are not defined here. At this point, they are simply expected to be members of the Group-3. The project administrators are defined in the administrative console of the CLM applications instead.
Neither LDAP groups nor users need to be mapped to the role JazzGuests as it merely represents guest users.

The screen capture below demonstrates how the security roles of the deployed CLM applications are configured via the administrative console of the Websphere Application Server (also known as WAS Admin Console) for the applications jts_war, ccm_war and qm_war.

In this configuration, individual LDAP users are associated with the CLM administrative roles while a LDAP group containing a large number of users (Group-3) is associated with the JazzUsers role.

6. Start the CLM applications on the application server. In this example, the CLM applications are started on the WAS server.

7. Complete the setup of the CLM applications (also known as JTS setup) by a CLM administrator. In other words, complete the application setup as a user with the JazzAdmins role. In this example, the application setup is completed by the LDAP user Cid I. Oreo.

8. Select “Custom Setup” in the “Welcome” page, as shown below

9. Select “LDAP” as User Registry Type in the “Setup User Registry” page of the application setup, as shown below

Enter details about the LDAP registry such as LDAP Registry Location, Base User DN, Base Group DN and others in the “Setup User Registry” page. In this example, the following information about the LDAP registry is provided.

LDAP Registry Location: ldap://vottfvtwin2k8m3.ottawa.ibm.com:389
User Name: CN=Cid I. Oreo,OU=swg,DC=jke,DC=ibm,DC=com
Password: **********
Base User DN: DC=jke,DC=ibm,DC=com
User Property Names Mapping: userId=sAMAccountName,name=cn,emailAddress=mail
Base Group DN: OU=swg,DC=jke,DC=ibm,DC=com
Group Name Property: cn
Group Member Property: member

Enter the following for the Jazz to LDAP Group Mapping: JazzAdmins=Group-3, JazzUsers=Group-3, JazzDWAdmins=Group-3, JazzProjectAdmins=Group-3, JazzGuests=Group-3

In the above mentioned Jazz to LDAP group mapping, all roles (also known as Jazz groups) are mapped to the LDAP group Group-3. Even though this group mapping is incorrect, it is temporarily kept this way in order to allow the provided LDAP information to be validated via the test connection button.

10. Continuing in the “Setup User Registry” page, click on the “Test Connection” button to validate the LDAP information entered above. The “Validate LDAP User” dialog may be presented as shown below.

11. If the “Validate LDAP User” dialog appears, click the “Skip” button to prevent the validation of the user from being carried out. A confirmation should be given as shown below indicating that a connection between the CLM applications and the LDAP registry has been successfully established.

12. Still continuing in the “Setup User Registry” page, update the Jazz to LDAP Group Mapping to the following: JazzAdmins=EmptyGroup, JazzUsers=Group-3, JazzDWAdmins=EmptyGroup, JazzProjectAdmins=EmptyGroup, JazzGuests=EmptyGroup

In the above mentioned Jazz to LDAP group mapping, the role JazzUsers is mapped to the LDAP group Group-3. The remaining roles such as JazzAdmins, JazzDWAdmins, JazzProjectAdmins and JazzGuests are mapped to a non-existent LDAP group named EmptyGroup. Ensure that a group with the particular name does not exist in the LDAP registry. If such a group exists, update the Jazz to LDAP group mapping appropriately, so that the following roles are mapped to a non-existent LDAP group instead: JazzAdmins, JazzDWAdmins, JazzProjectAdmins and JazzGuests.

The use of a non-existent LDAP group for the Jazz administrative roles poses a minor risk where someone, at some point, may create a LDAP group with the same name by causing the CLM applications to display incorrect user role information. The user synchronization may also be impacted in this scenario. This risk however becomes irrelevant if creating groups in the LDAP registry is prohibited.

If a warning is given as shown below after updating the group mapping, ignore the particular warning and proceed with completing the remainder of the application setup.

The Jazz to LDAP group mapping is utilized by the CLM applications for user synchronization and for the purposes of displaying the user roles in the graphical user interface.

13. Assign trial licenses to the CLM administrator completing the application setup as appropriate

14. The remaining steps of the application setup should be completed according to the system configuration. You may refer to the following document for information: Running the setup wizard (Custom setup)

15. Upon completion of the application setup, the properties of the LDAP user who had completed the setup should be inspected in the JTS Administrative Console. The particular user should possess the roles assigned to it in step 5. In this example, the LDAP user Cid I. Oreo is who completed the application setup. The properties page of the particular user confirms that he possesses the following roles by reflecting the settings made in step 5: JazzAdmins, JazzDWAdmins, JazzProjectAdmins and JazzUsers. In addition, the user properties page should confirm that the CLM application is connected to an external user registry and the roles of the particular user is read only. Please refer to the screen capture below for details.

16. In the JTS Administrative Console, the LDAP nightly synchronization is enabled by default. Therefore, the users in the LDAP registry, which are visible to JTS according to the provided LDAP registry information and credentials, are automatically imported into the CLM applications during the nightly synchronization. In step 5, the JazzUsers role was mapped to a top level group of the LDAP registry (Group-3). This group may contain a large number of LDAP users. Only a subset of such LDAP users may require utilizing the CLM applications. If the LDAP nightly synchronization is left enabled, all the users in the Group-3 will be automatically imported into the CLM applications and each such user will possess the JazzUsers role. Having a large number of LDAP users available in the CLM applications with the JazzUsers role may not be appropriate if only a small subset of these users require the use of the particular applications. Therefore, consider disabling the LDAP nightly synchronization in the “Advanced Properties” page of the JTS Administrative Console as show below to prevent JTS from automatically importing all the users from Group-3 into the CLM applications.

Please note that it is also possible to use a single LDAP group definition which only contains the users who require utilizing the CLM applications. The LDAP group Group-4 mentioned in step 1 is an example. If such a LDAP group was mapped to the JazzUsers role in step 5, leave the synchronization enabled.

The LDAP nightly synchronization must be disabled by a CLM administrator. You may refer to the following document for information: Disabling LDAP Nightly Synchronization.

In this example, this task is performed by the LDAP user Cid I. Oreo.

Once the LDAP nightly synchronization has been disabled, the LDAP users will not be automatically brought into the CLM applications. The CLM administrators may now decide which LDAP users have a valid business need for utilizing the CLM applications and only import them as appropriate.

Please note that disabling the LDAP nightly synchronization prevents the changes made to the name and email address of a LDAP user from propagating to the CLM applications. Such a user can be re-imported into the CLM applications via the Repository Tools as described in step 17 to force the CLM applications to obtain the updated user information.

17. The LDAP users having a valid business need should be registered in the CLM applications. The following three approaches (17.1, 17.2 and 17.3) can be adopted to accomplish this task. In the first two approaches (17.1 and 17.2), a CLM administrator must perform the registration process. The last approach (17.3) on the other hand allows a LDAP user to register him/her in the CLM applications by eliminating the need for a CLM administrator to be involved in the process.

17.1. In the JTS Administrative Console, the LDAP users can be imported into the CLM applications and appropriate licenses can be granted according to their roles and responsibilities by a CLM administrator. You may refer to the following document for information: Importing users from an external user registry

In this example, the following 2 LDAP users are imported into the CLM applications via the JTS Administrative Console by Cid I. Oreo

cn=Deon T. Adminio, uid=tooladminus, mail: tooladminus@jke.ibm.com
cn=John Doe, uid=jdoe, mail: jdoe@jke.ibm.com

Please refer to the screen capture below for details.

In addition, the following Client Access Licenses (CALs) are granted to each user via the JTS Administrative Console by Cid I. Oreo: RTC-Developer, RQM-Quality Professional and RRC-Analyst. You may refer to the following document for information: Assigning client access licenses to users

17.2. LDAP users can also be imported into the CLM applications from command-prompt.

An individual LDAP user can be imported into the CLM applications as shown below. This operation must be performed by a CLM administrator.

repotools-jts.bat -createUser userid="{id of user}" name="{name of user}" emailAddress="{email of user}" adminUserId="{id of CLM administrator}" adminPassword="{password of CLM administrator}" licenseId="[{comma separated list of license ids}]"

For example,

repotools-jts.bat -createUser userid="tooladminus" name="Deon T. Adminio" emailAddress="tooladminus@jke.ibm.com" adminUserId="cio" adminPassword="*****" licenseId="[com.ibm.team.rrc.author;com.ibm.team.rtc.developer;com.ibm.rqm.tester]"

In the above example, the LDAP user Deon T. Adminio is imported into the CLM applications while assigning the following licenses to him by Cid I. Oreo: RRC-Analyst, RTC-Developer and RQM-Quality Professional.

The Repository Tools command createUser can also be utilized for updating information of an existing LDAP user in the CLM applications.

Please refer to the following document for details: Importing a user via Repository Tools

A set of LDAP users can also be imported into the CLM applications from command-line as shown below. This operation must also be performed by a CLM administrator.

repotools-jts.bat -importUsers fromFile="{path to a CSV file containing users to be imported}" adminUserId="{id of CLM administrator}" adminPassword="{password of CLM administrator}"

The CSV file used with this command must contain a comma separated list of the following information of each LDAP user to be imported into the CLM applications: user id, name, e-mail address and license id(s).

{id of user 1},{name of user 1},{email of user 1},[{comma separated list of license ids for user 1}],,0{id of user 2},{name of user 2},{email of user 2},[{comma separated list of license ids for user 2}],,0 ... {id of user n},{name of user n},{email of user n},[{comma separated list of license ids for user n}],,0

For example,

repotools-jts.bat -importUsers fromFile="users.csv" adminUserId="cio" adminPassword="*****"

Content of provided CSV file (users.csv)

tooladminus,Deon T. Adminio,Unknown,[com.ibm.team.rrc.author;com.ibm.team.rtc.developer;com.ibm.rqm.tester],,0jdoe,John Doe, jdoe@jke.ibm.com,[com.ibm.team.rrc.author;com.ibm.team.rtc.developer;com.ibm.rqm.tester],,0

In the above example, the LDAP users Deon T. Adminio and John Doe are imported into the CLM applications while assigning the following licenses to them by Cid I. Oreo: RRC-Analyst, RTC-Developer and RQM-Quality Professional.

The Repository Tools command importUsers can also be utilized for updating information of a set of existing LDAP users in the CLM applications.

Please refer to the following document for details: Importing a set of users from a CSV file via Repository Tools

17.3. The CLM applications can be configured to allow a LDAP user to automatically register him/her by eliminating the need for a CLM administrator to be involved in the process. This feature must be enabled by a CLM Administrator as described in the following document: Allowing users to register themselves

In this example, the user-self-registration feature is enabled by the LDAP user Cid I. Oreo.

The CLM applications can also be configured to automatically assign a set of licenses to a new user by eliminating the need for a CLM administrator to be involved in the process. This feature must be enabled by a CLM Administrator as described in the following document: Assigning default licenses to new users

In this example, the CLM applications are configured to automatically assign the following Token licenses to a new user by the LDAP user Cid I. Oreo: Rational Quality Manager – Quality Professional, Rational Requirement Composer – Analyst and Rational Team Concert – Developer.

Once the user-self-registration feature and the default-license-assignment feature have been enabled, a new LDAP user may register him/her by simply logging on the CLM applications. A new account will be automatically created in the CLM applications for the LDAP user. In addition, the default set of licenses will be automatically assigned to the newly created account. Therefore, neither the user registration nor the license assignment in this approach requires the involvement of a CLM administrator.

18. Projects should be created in each CLM application via the Lifecycle Project Administrator (LPA) or via the administrative console of the CLM application by a CLM administrator. In other words, projects should be created by a user with the JazzProjectAdmins role. In this example, a lifecycle project named “JKE Bank” with template “Quality Professional, Analyst, Developer” is created via LPA by Cid I. Oreo.

19. The project administrators should be assigned to each newly created project via the administrative console of the corresponding CLM application by a CLM administrator. The project administrators must possess the JazzUsers role. In other words, they must be members of the LDAP group Group-3. The project administrators are responsible for performing the administrative duties within the corresponding project such as

assigning and removing project administrators and members to/from the project
managing process roles (project level roles) of members
linking project with other projects
defining and managing permissions, access-control, artifact types, categories, timelines, iteration types, releases, mail templates, process description and other project properties
associating the project with social network communities …etc.

Project administrators can neither import users from the LDAP registry into the CLM applications nor assign client access licenses to the existing users. The CLM administrators are responsible for performing these duties instead. The project administrators are rather permitted to assign the existing users (LDAP users which the CLM administrators have already imported into the CLM applications) to the corresponding projects.

In this example, the LDAP user Deon T. Adminio is assigned as a project administrator to the “JKE Bank” project via the administrative console of RTC, RQM and RRC by Cid I. Oreo as shown below.

20. Members should be assigned to each newly created project via the Lifecycle Project Administrator (LPA) or via the administrative console of the CLM application by a project administrator. In this example, the following users are assigned to the “JKE Bank” project via LPA by Deon T. Adminio as shown below: John Doe and Deon T. Adminio.

21. Process roles (project level roles) should be assigned to each project member via the Lifecycle Project Administrator (LPA) or via the administrative console of the CLM application by a project administrator. In this example, appropriate process roles are assigned to Deon T. Adminio and John Doe via LPA by Deon T. Adminio as shown below.

22. Each project member should now log on to JTS and inspect whether their Jazz roles (repository permissions), licenses, project memberships and process roles match the settings made in step 5, 17, 19, 20 and 21. In this example, the project administrator Deon T. Adminio should only possess the JazzUsers role by reflecting the settings made in step 5. Please refer to the screen capture below for details.

Related Information

The following links point to related information

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Feedback

Was this information helpful?

Yes

No 12 people rated this as helpful.