Security strategies

By default, all users initially have access to everything in the client. To avoid accidental deletions and other problems, administrators must set access rights as soon as possible. Until you become familiar with access rights, we recommend that you follow the guidelines suggested in this section.

StarTeam Server strategies

On the StarTeam Server, the User Manager dialog allows you to create users and groups for each server configuration while that configuration is running. Use the following guidelines:

Do not change the privileges for the All Users, Administrators, System Managers, and Security Administrators groups.
Do not create additional groups under the Administrators group.
Create the groups that you need under All Users or under each other. For example, you may need to create the following groups: Developers, Testers, and Writers.
Create users and assign them to groups. Make sure that at least two users are administrators, in case one administrator becomes locked out.

Client strategies

Use the following guidelines when working with the client:

Although you can deny rights as well as grant them, it is best only to grant them.
If you do deny rights, observe both of the following rules:
1. Never allow any node on an Access Rights dialog box to have only deny rights records.
2. Always make sure that the deny rights records for any node precede any records that grant rights for that node.
When you set access rights for a node, remember that any user who does not have access rights for the node (individually or in a group) is denied all rights at this level for this node (unless that user has privileges that allow access).
Set access rights at the project level first. Set them for every group (except the All Users group) for every node. The nodes are Project, View, Child Folders, File, Change Request, Requirement, Task, and Topic. Depending on which version of the client your company uses, you may not see all of these nodes. The most important nodes to set at this level are the Project and View nodes. The Project node is the only location in which you can set project access rights. The View node controls view-level access to all views. Newly created views start out with only the view access rights set here for all views. Initially, they have no view-level access rights.
Set access rights at the view level next. Set rights for every user and/or group that needs access at this level for every node. (The nodes are View, Child Folders, File, Change Request, Requirement, Task, and Topic).
Set up access rights at the folder level only if you really need to have access rights for the folders. Remember that these settings go with the folder when it is moved or shared and when it becomes part of new views (until the folder branches in the new view). Remember that folders branch only when their properties change, and that their properties tend to change infrequently.
Avoid setting access rights on root folders because those rights can conflict with those set at the project or view levels.
Avoid setting access rights on items. Remember that these settings go with the item when it is moved or shared and when it becomes part of new views (until the item branches in the new view).

Determining object access rights and tokens

The StarTeam server checks access rights in layers. The right to access an object begins with the System Policy tab which can be reached by choosing Tools > Accounts > System Policy in the Server Administration Tool.

Similarly, unless privileges are being ignored, the privileges granted to groups also override and take precedence over the access rights configured elsewhere. Privileges are group properties that are set by using the Privileges tab of the Group Properties dialog.

A user is granted the same privileges as the group to which he or she belongs. If the user belongs to two groups and one group is granted certain privileges and the other group is denied the same privileges, the user is granted the privileges because at least one group to which he or she belongs has those privileges.

After checking privileges, the client checks the access rights granted for specific objects. Settings on the Access Rights dialogs for projects, views, folders, and individual items grant or deny users or groups the ability to perform operations at those levels.

Note: If rights are granted to any user or group at a given level in an Access Rights dialog, those users who are not granted rights at that level are effectively denied the rights. Ultimately, if a user can see an object and no deny records stop the user from performing an operation, the user can do anything that a grant record allows him or her to do, whether as an individual user or as a member of a group. The only exception involves issues of privileges.

To summarize, the client performs the following checks to determine whether a user can perform an operation:

If the user belongs to a group that has a satisfactory privilege and privileges are not being ignored, access is granted. Note that privileges, when not ignored, take precedence over access rights wherever access rights are set. If users belong to a group that has the correct privileges, they can be granted access rights that are specifically denied to them in the client.
If the user or any group to which the user belongs has been granted satisfactory access rights for the object on which the operation will performed, access is granted. If the object has access rights set, but none are satisfactory, the user is denied access.
If the object has no access rights set, the client checks the next higher level. For example, if the operation is on a file, change request, topic, task, or child folder, the client checks the access rights for the parent folder. If the operation is on a root folder, the client checks the access rights for the view. If the operation is on a view, the client checks the access rights for the project. If the operation is creating a project, the server access rights are checked.
If none of the levels has access rights set, access is granted.

Administrators can override group privileges by setting options from the server configuration System Policy dialog. Use this option with caution, because it changes the steps used by the StarTeam Server to check every user (including administrators) for access to all objects in the repository. If you ignore privileges, only access rights determine who can and cannot perform operations on objects in the repository.

Group privileges for objects

The privileges assigned to a group may allow members of that group to access objects and perform operations that they are otherwise not allowed to do. In other words, group privileges override the access rights settings.

If you choose Tools > Accounts > User Manager from the Server Administration Tool, notice that the server configuration comes with some default groups: All Users, Administrators, System Managers, and Security Administrators. The default user named Administrator belongs to both the Administrators and the Security Administrators groups. By default, the Administrators group has all group privileges. Also by default, the other groups have none of these privileges.

All members of a group have the same privileges on every project managed by this server configuration. The privileges apply to all levels equally: projects, views, folders, and items within folders. If users belong to more than one group, they have the maximum amount of privileges, regardless of which group provides them with those privileges.

Understanding object access right levels

Access rights are defined for individual users or groups at the following levels:

Project level	Access rights can be defined for the project itself. You can also define access rights that apply to all its views, child folders and items, unless a object has access rights set specifically for it. There are View, Child Folders, and other nodes at this and other levels.
View level	You can define access rights for the view itself. You can also define access rights that apply to all its child folders and items, unless a specific object has access rights set specifically for it.
Folder level	You can define access rights for the folder itself. You can also define access rights that apply to all its child folders and items, unless a specific object has access rights set specifically for it.
Item level	You can define access rights to a specific file, change request, requirement, task, or topic. (It is unusual to set rights at this level.)

Note: Project access rights can be set only at the project level, because that is the only level with Project node in the access rights hierarchy. You can set view access rights at either the project or the view level, because both of those levels have a View node. You can set folder access right at the project, view, or folder levels, and so on.

Opening projects and views

A project is indistinguishable from its initial view and also from the root folder of that view. In fact, any view of a project is indistinguishable from its root folder. Therefore, a user will not be able to open a project if you deny that user (or all groups to which the user belongs) any of the following:

Ability to see the project.
Ability to see the initial project view.
Ability to see the root folder of the project’s initial view.

A user will not be able to open a particular view of a project if you deny that user (or all the groups to which the user belongs) any of the following:

Ability to see that view.
Ability to see that view’s root folder.

Component, filter, and query-level access rights

The client components (file, change request, requirement, task, and topic) are server-wide objects. For example, the change request component appears in every project view and has the same filters and queries in every view.

Component-level access rights govern the use of filters and queries for each component. They determine the users who can create public filters and queries in that component, who can use the filters and queries, and so on. A server-level access right named Administer component-level access rights allows users to set these rights.

Individual filters and queries also have access rights. These rights override the general access rights set for filters and queries.

The right pane contains a tree of access rights subcategories. When expanded, each subcategory displays a set of access rights as its children.

Each filter or query resides in a particular component (such as the Change Request component or the File component) and can be applied to that component’s type of data only in any project view managed by a specific server configuration.

Any user can create and use private filters and queries, but public filters and queries have access rights, individually and per component. Rights set on a specific filter or query take precedence over access rights set at the component level.

To apply a public filter or query, a user must be able to access the data type for the component in some open project view. When you apply the filter or query, it affects the type of data that visible in the open project view.

Users can apply any public filters and queries that they can view. In general, users can see any public filters and queries for which they have access rights.

Access rights for promotion states

Each view has its own set of promotion states. Access to these states is controlled by:

The “Define promotion level” right.
Access rights that govern access to individual promotion states.

The define promotion level right

The Define promotion level right is available from the View node of the Access Rights dialog at the view and project levels. A user with the Define promotion level right can do anything to the promotion model:

Create and delete states.
Edit their properties.
Promote a label from one state to another. Promotion is a subset of editing properties. Anyone who can edit the properties of a state can also promote that state.
Reorder the states within the view.

Promotion state access rights

Promotion state access rights govern access to individual promotion states. These Generic object rights and Promotion state specific rights are available from the Promotion State node of the Access Rights dialog at the view and project levels. They also appear on the access rights for individual promotion states.

The rights for an individual promotion state are checked at the state level; if necessary, the checking continues at the view level and eventually the project level. If a user is granted a given right at one level, there is no need to check the next.

When a right is granted at the view level, it applies to all states in the view, unless access is denied at the state level.

When a right is granted at the project level, it applies to all the states in all the views within the project, unless access is denied at the state or view levels.