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.
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.
- 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
- 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.
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.
- 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
- System A CRs: system=A
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.
- Start at the Rational Change page on developerWorks to learn about features and benefits, get product details and information on related Rational products, and to find more technical articles and where to get support. Find out more in the Project security section of the Rational Change information center.
- To learn more about Rational Synergy, check the product overview and features and benefits pages, as well as the developerWorks page. For support, see the Rational Synergy Information Center.
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the Getting Started ones are free.
Get products and technologies
- Get the free Trial Download or check the Trials and Demos page for Rational software.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Enterprise Change Management with Rational Change forum to ask questions and participate in discussions.
- Join the Rational Synergy forum to ask questions and participate in discussions.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Get connected. Join the Rational community to share your Rational software expertise and get connected with your peers.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.