Use these topics to learn how to plan, configure, and use
the project security feature.
Project security
Project security is an alternative to traditional database
security, where privileges are statically assigned at the database
level. Instead of assigning users static privileges that apply to
all CRs and tasks within a particular database, users are assigned
dynamic privileges within the context of a set of related CRs. These
dynamic privileges are defined in the context of a project and are
applied whenever the user is in the context of the CR that belongs
to the project.
Example projects
This topic contains examples of a scenario where you have
two projects, each corresponding to a different system.
Planning
There are four basic steps of planning for project security.
Login and database access rules
Project security affects login, including the databases
and interfaces users have access to. These rules apply to both central
and stand-alone modes.
Configuring privilege security mode
By default, Rational® Change
uses traditional database privileges, as it did in previous releases.
Alternatively, it can be configured to use dynamic privileges with
project security. Use this procedure to switch privilege security
modes.
Defining roles
In project security, a role is a set of related privileges.
Roles logically group privileges together based on the duties of the
person with that role. The advantage of using roles over assigning
privileges directly is that related privileges can be administered
as a unit, which requires fewer steps and ensures consistency.
Assigning global roles and privileges
Roles and privileges are usually defined at the project
level. However, it is also possible to define them statically and
globally, so that they are defined outside of a project and are not
context-specific. These assignments always apply and are not subject
to the context of the CR.
Defining projects
A project defines a set of related CRs and assigns roles
to groups of users within that context. Therefore, user privileges
vary dynamically based on the CR.
Creating subprojects
A subproject is derived from an existing project (parent
project) but is more specific in scope. For example, you can create
a parent project for SystemA and subprojects for different releases
of SystemA.
Reporting on projects
Use project reports to find out the projects users are
assigned to and what roles they have within the projects. You can
also run a report to find out the project members and their privileges
in a given set of projects.
Deleting projects
You can delete projects when they are no longer needed.