本文发表在 rolia.net 枫下论坛A Practical Solution to ClearCase Access Control

1 Introduction

Security and access control have always been among the most difficult issues in contemporary software development. The difficulty lays in business requirements rather than the techniques. If not dealt with carefully, security control can be a long and exhausting task. Specifically, access control in ClearCase is very complicate, partially because there are too many facilities available but ClearCas provides no user management system.

This article discusses some of ClearCase’s build-in security features, such as users and groups, locks, UCM policies, and customer build triggers. In addition, it discusses other features that are not initially designed for access control, such as PVOB and region, because a proper design of PVOB and region can enhance the security of ClearCase implementation. Using a combination of different sets of facilities, this article proposes some practical solutions to ClearCase access control.

Through the article, the author assumes that the ClearCase VOB server and VOB storages are located in a UNIX (AIX) server and most clients have Windows XP operating system. Also, the author focuses on ClearCase UCM implementation, rather than base ClearCase.更多精彩文章及讨论，请光临枫下论坛 rolia.net

This article discusses some of ClearCase build-in security features, such as users and groups, locks, UCM policies, and customer build triggers. In addition, it discusses other features that are not initially designed for access control, such as PVOB and region, because a proper design of PVOB and region can enhance the security of ClearCase implementation. Using a combination of different sets of facilities, this article proposes some practical solutions to ClearCase access control.

Through the article, the author assumes that the ClearCase VOB server and VOB storages are located in a UNIX (AIX) server and most clients have Windows XP operating system. Also, the author focuses on ClearCase UCM implementation, rather than base ClearCase.

本文发表在 rolia.net 枫下论坛2 Business Requirements
There are two possible categories of requirements usually push you into the areas of access control in ClearCase, to maintain the system integrity and to facilitate certain software process. In the first category, we want to prevent normal users from doing anything to harm the system, while in the second category we want to allow certain users to have some special rights to drive a certain workflow.
2.1 Facilitating access controls
2.1.1 Priority users
In this case, only certain users can do certain critical tasks in ClearCase. For example, you would like to allow only ClearCase administrators or experienced integrators to change the basic UCM project and stream configurations.
2.1.2 Restricted areas
Organizations such as banks normally have higher security requirements for the source controls system. It’s common to have such a requirement that some projects don’t want anyone else other than the project team members to peek into their projects. Here we called this situation as zero-visibility. Means other projects even don’t knows there is such a high secured project existing in ClearCase.
2.1.3 Read-only access
For most of other projects, we want to allow the project team members only to have the right to modify their code, but still give read-only right to others. We hereby called this as read-only access. Means you can see what they have but have no right to change anything there.

There is a good reason to give out the read-only to other projects. In today’s software development, component based and architecture oriented design approach are very common in a lot of large organization such as banks. Most of projects are relying on other project teams’ deliveries, components and sub-systems, which represented as components in ClearCase.更多精彩文章及讨论，请光临枫下论坛 rolia.net

2.2 Implementing processes
As a SCM tool, ClearCase plays a very important role in software development lifecycle from beginning to the end. Since most of artifacts are version controlled in ClearCase, who can access to certain resources becomes an integral part of many processes. These processes can be a team integration process, or an official build and release process.

For example, we are currently having such a build process in our J2EE development:
1. Any project has code exposed to others will have to put their code in a _Interfaces_src component.
2. A build script will build this component, create a new jar and store it in /bin directory.
3. A new baseline will be created on this component and promotion level will be changed.

To facilitate such a process, some access controls is required:
1. Nobody else except the “build” id can create a new baseline on this project’s integration stream.
2. Nobody else except the “build” id can change the baseline promotion level.