Planning project security

There are four basic steps of planning for project security.

Identify the roles of the Rational® Change users, which can include titles like tester, developer, manager, and team lead.
These titles roughly correspond to the job function of the person. However, it is acceptable for a person to have more than one role, or even different roles on different projects.
Determine the privileges required to perform those roles, such as submitting, verifying, reviewing, assigning, concluding, and permission to modify certain attributes.
Use these privileges in defining your change request processes. Then define roles in terms of the privileges they entail.
Partition your IBM® Rational Directory Server users into groups.
You may already have groups, but create additional project-specific groups based on role-project combinations (for example, developers for a given project).
Identify logically related sets of CRs, such as by product, release, or team.
Combine these related sets with group members and their roles to form projects.

Security model migration

Migration from the traditional database security model to dynamic privileges with project security is a manual process. The process consists of two high-level steps:

Define project security.
Remove any database privileges from Rational Synergy that were used exclusively for Rational Change.

Implications for multiple servers

Project security, roles, and global assignments are stored in Rational Directory Server and are global. Two Rational Change servers sharing the same Rational Directory Server share project security and role definitions. Likewise, if you point an existing Rational Change server to a different Rational Directory Server, it has a different project security setup.

Note: Project security and role definitions follow Rational Directory Server, not the Rational Change server, even though they are defined from the Rational Change server.

Staged deployment

Instead of making changes to project security in a live production environment, make the changes in an isolated staging environment. You can deploy the results into a production environment. Then you can experiment and validate the system before going live.

This type of deployment is only needed when the staging and production environments use separate Rational Directory Servers. If not, then the data is already shared because the project security definitions are persisted in Rational Directory Server and are common to both Rational Change servers.

Two Perl APIs have been provided for this purpose:

ExportProjectSecurityData
ImportProjectSecurityData

Import is non-destructive by default. That is, it augments rather than overrides existing data. See the Perl API help for details.