Working with the IBM Rational Change project security feature: Part 1. Introduction and terminology

The project security feature was added to Rational Change in Version 5.3 an alternative to traditional database security, where privileges are statically assigned at the database level. When you enable project security, rather than assigning users static privileges that apply to all change requests (CRs) and tasks within a particular database, users are assigned dynamic privileges within the context of a set of related CRs. This makes user management for Rational Change 5.3 easy. Part 1 of this two-part article explains the feature and the related terms. The purpose of both parts is to make you comfortable with the terms used in the feature before you begin using it and to help you understand and implement the feature easily.


Ritesh Nigam (, Staff Software Engineer, I.B.M.

author photoRitesh Nigam is a senior software engineer with nearly eight years of experience in software development. He has been working as a senior developer for IBM Rational Change software for the past five years. He also has experience in Java, Java 2 Enterprise Edition (J2EE), Perl, and web technologies, such as Dojo toolkit, Ajax, web services, OSLC, and change and configuration management.

30 October 2012

How the project security feature works

Project security is a feature introduced in IBM® Rational® Change Version 5.3 to manage user privileges. Privileges are assigned dynamically, based on a grouping of change requests (CRs). Project introduces the notion of projects as a way to group CRs and roles as a way to group and organize privileges.

In a traditional privilege management system (all that was available before Rational Change 5.3), each Rational Change user has a set of privileges defined at the database level. These privileges determine, among other things, whether a user can transition a CR to a new state and which attributes can be modified. This method is based on the assumption that one set of privileges is always appropriate for a given user (at least for a particular database).

However, it is often desirable to have contextual privileges, based on properties of the CR. For instance, suppose that Carol plays two roles within the organization:

  • Team Leader for system A
  • Change Control Board (CCB) member for system B.

To perform those duties, Carol must be granted the privileges relevant to those roles: Team leader and CCB member.

Thus, when she's viewing a CR for system B, she can act as both Team Leader and CCB Member. She needs only the CCB role to act on CRs for system B. Eventually, she gets the Team Leader role on these CRs also, but it is not relevant in the context of system B.

Providing these kinds of privileges in the traditional way of privilege management can become cumbersome. Another drawback of the previous method is administration of privileges:

  • When a new user is added, privileges need to be assigned at each database level.
  • If the responsibilities of an organizational role changes, the privileges for all of those users need to be updated together.
  • If a user changes roles in the organization, a new set of privileges needs to be assigned.

Project security addresses those issues. After project security is enabled, it eases the administration of privileges and users associated with those privileges. The project security heavily relies on Groups defined in Rational Directory Server to grant privileges dynamically to the users.

Terms explained

There are few new terms added, and some of the previous terms have updated definitions in project security. Understanding them is important.

Projects are nothing but the logical grouping of CRs. Projects are defined through the Admin interface of the Rational Change application. A project consists of attributes with their values (which ultimately form a query to group CRs), and users or groups as members of the project with the roles and privileges assigned to them for this group. These privileges are applicable to the CRs that come under this project.
Project rules
Project rules are the rules defined for a project through the Change Admin interface.
A Project Rule consists of
  • CRs that can be grouped under this project, based on the attribute values selected.
  • Members (Users and Groups) for whom this project and the roles are applicable.
Rule example:
  • Carol is team leader for system A and a CCB member of system B.
    [User: Carol, Project: system=A, Role: Team Leader][User: Carol, Project: system=B, Role: CCB Member]
  • Members of the Developers group have the Developer role for CRs against the products classified as "product A or product B."
    [Group: Developers, Project: product_name="product A" OR product_name="product B, " Role: Developer]
Roles are logical groupings of privileges. For example:
  • Team Leader role = enterer, reviewer, assigner, resolver, concluder
  • CCB Member role = reviewer
In these examples, the Team Leader role consists of enterer, reviewer, assigner, resolver, and concluder privileges, and CCM Member role consists of only one privilege: reviewer.

  • It is also possible to assign a privilege directly to a user or group as you did in earlier versions.
  • Before Version 5.3, the term Role was used to indicate the actual login interface, such as User, Admin, or Report Builder, during login. That has been changed to Web Interface. This means that User, Admin, and Report Builder will each be called as a Web Interface rather than as a Role from Rational Change 5.3 onward.
Potential privileges
Potential privilege is relevant only to Rational Change. These privileges are defined through the Lifecycle Editor and are totally different from Rational Synergy privileges. A potential privilege is applicable only for CRs, not for tasks.

Users' potential privileges are the union of their global privileges and any dynamic privileges that could be granted to them, based on project security rules:
  • All global privileges that pertain to the user and the user's groups
  • All dynamic privileges that pertain to the user and the user's groups across the project definitions
  • User's potential privilege are combination of the privileges from the first two
Database privilege
A database privilege is Rational Synergy privilege, so it is defined through Rational Synergy, not through Rational Change. Therefore, it is applicable only to Rational Synergy tasks, not to Rational Change CRs.
Global privilege or role
Global privileges or roles are defined outside of the projects and are applicable to all the projects and all the CRs in all the databases associated with a Change server.

For example:
User Carol is granted the Contributor role and the enterer privilege globally. Carol always has these roles/privileges in Change regardless of the state of a CR or the database she's logged into. Carol may have additional privileges when working with CRs if so granted by project rules.
CR-only database
CR-only database is a database for which access or login for a user totally depends on the potential privilege a user has, but not Rational Synergy privileges. In other words, to log in to this database, a user must have a dynamic privilege assigned either through a project or through a global privilege, but the user does not need to be a Rational Synergy user.
  • For a central Rational Change server, the central CR database will be automatically taken as CR-only database.
  • For a stand-alone server, an administrator has to set a CR-only database form the list of databases associated with the Rational Change server. This database can have tasks also, but to work with the tasks in this database, the user must have any additional Rational Synergy privilege.
Development database
A development database is a regular Rational® Synergy database that is not a central CR database. In central server mode, it is not a CR-only database, so it would not have CRs. However, in stand-alone mode, it could have tasks and CRs. From the Rational Change perspective, Rational Synergy database roles in a development database affect access in two ways:
  • Whether or not a user can log in
  • What task operations a user can do

Although Rational Synergy privileges do come into play during login for development databases, CR operations are not affected by the Rational Synergy database roles.

To log in to any development database, the user must have a potential privilege, as well as a database privilege through Rational Synergy.

Roles and privileges

Privileges have traditionally been database-specific and static, meaning that they are defined in and applicable to a particular database, and they seldom change. This is in contrast to the dynamic nature of privileges in the project security model, because dynamic privileges can vary from one CR to another, based on what project rules match.

The following changes occur when project security is activated:

  • Change privilege assignments are no longer stored in the database, mixed in as they were with Rational Synergy database roles.
  • Roles and privileges are now assigned either globally in a static fashion or dynamically at the project level. They are not assigned at the database level.
  • Change privileges are independent of Rational Synergy database roles, even if they happen to share the same name.
    • For example, having assigner as a Rational Synergy database role does not imply that the user has the assigner privilege in Rational Change, or vice versa. The name overlap is historical only.
    • Rational Synergy database roles and Change privileges are scoped separately.
  • Rational Change cannot administer Rational Synergy database roles. That must be done through Rational Synergy.
  • Rational Synergy database roles are relevant to Rational Change only in allowing access to task databases and for task operations.

Login and database access

Project security affects login, including the databases and interfaces that users have access to.

Database access

  • Access to a central CR database or a CR-only database is allowed if the user has at least one potential privilege.
  • Access to a development (task) database is allowed if the user has at least one Rational Synergy database role, as defined by ccm users (which role doesn't matter), and at least one potential privilege.

Web interface access (previously called Role)

The list of valid interface choices is determined by a user's potential privileges, according to how they map to interfaces. These choices are independent of the database selection.

These access rules apply to both central and stand-alone modes.

Comparison of traditional and dynamic privileges

Traditional database privileges

  • Users are assigned static privileges that apply to all CRs and tasks within a particular database.
  • Privilege assignments are stored in the Rational Synergy database (that is, ccm users).
  • CR and task privileges might overlap as they share a common namespace.

Dynamic privileges with project security

  • Users are assigned dynamic privileges for a set of matching CRs or global privileges across all CRs.
  • Users' net privileges are the union of their dynamic and global privileges.
  • Dynamic privileges are based on the attributes of the CR, such as all CRs against a particular product. Thus, a user can have different privileges, depending on the CR.
  • Sets of related privileges are grouped into roles for easier assignment and management of privileges.
  • Projects define a set of related CRs and assign roles to groups of users within that context.
  • Privilege assignments — including roles and projects — are stored in the Rational Directory Server (RDS), thus shared across all databases and Rational Change servers with common RDS.
  • CR and task privileges do not overlap, even if they share the same name.
  • Tasks are still governed by Rational Synergy database privileges.
  • To log in, a user must have at least one potential privilege for a CR-only database, and both a Rational Synergy database privilege and a potential privilege for all other databases.


Are used in lifecycle security rules. For example, an assigner privilege is required to perform the Assign transition for a CR (Entered > Assigned).
Are defined to logically group the related privileges based on the duties of the person in that role.
  • Team Leader: Enterer, reviewer, assigner, resolver, concluder
  • CCB Member: Reviewer
Are defined to classify CRs based on attribute values; this also defines access to users and what roles or privileges they are given.
Project rules
Determine what CRs should be grouped under this project, who the users are, and what privileges they have on these CRs:
  • System A CRs: system=A
    User or Groups: Carol
    Role: Team Leader
  • System B CRs: system=B
    Users or Groups: Carol
    Role: CCB Member

As users view CRs, their sets of privileges are dynamically determined, thus granting or denying them certain capabilities. Therefore, Carol can perform the Assign transition on CRs for system A, but not on any other CRs.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Working with the IBM Rational Change project security feature: Part 1. Introduction and terminology