Problem:

Starteam Access Rights Overview

Resolution:

Starteam Access Rights Overview

Information in this Brief applies to:

• Starteam 4.x & 5.x
• All Current Starteam OS and Database Platforms

Overview

This is an overview of the way Starteam"s Access Rights work, and a high level lookat options to implement them.

Details

There are three things you want to keep in mind when working with security (Access Rights):

1. The StarTeam Security model works from the object up.

2. If a group, groups, individual or individuals are granted an access right on a TAB, all groups and individuals not granted are denied for the same selection

3. Beware of any privileges granted to a group in the User Manager.

Examples to consider:

A. When a user selects, for example, to check in a file, StarTeam checks the immediate file to see if that User has the right to perform the operation. StarTeam will either find the user specifically granted the right (in which case the User can check in the file), or specifically denied (in which case the User cannot check in the file), or no security settings on the file at all (in which case StarTeam will move on to the next level looking for access rights). Access rights would be checked on the file, then on it"s parent folder, then on the folder"s parent folder, and so on, then the view, and then the project itself. If at any level in the chain, StarTeam finds the user granted or denied, it will apply those rights immediately to the process of check in, regardless of what rights the user may have on a higher level. This has the effect of being able to set Access rights on a more general level, say project level, and to have those rights filter down (unless otherwise specified differently at a lower level).

B. By default, all users are granted rights.

The following represents a common misconception:

A system administrator wants to restrict a given user group, so he adds the group and denies the group rights. He assumes that all other users will keep their rights, but this one group will be denied. In actuality, once a user group is added, other groups are inherently denied because they are also not added. So if Group A is added, and denied rights, group B, which has never been added, will also be denied rights. The rule of thumb is to add all respective groups when you add one group, and grant or deny rights to each group at that time. This model also holds true when working with a single user, as well.

C. In the User manager of StarTeam, you can right click a group and select the privileges Tab. When tuning security rights for a project, it is better to have no privileges specified for any group other than Administrators. Privileges can grant some overrides to normal security settings, making restricting and testing restrictions of different groups difficult. Make sure you uncheck all privileges to your non-administrator groups before tuning security.