From Seapine Labs
 Surround SCM Security Groups
This wiki includes best practices for Surround SCM security group settings. The phrase Paranoid is used to describe heightened security for users and Relaxed is a term used to described empowered settings for users.
 Security Overview
Surround SCM security is expansive and can be confusing. This information is provided to help you create your own best practices for implementing Surround SCM security.
There are three primary levels of security ranging from server level (global) to repository level (mainline) and branch level (branch-repository specific). Users can also exist in multiple security groups, which means there are different combinations of group settings that can be applied.
The repository and branch security settings are additive for both positive and negative settings, meaning it is possible to add a new setting that either restricts or enables permissions. The default server security settings are used if a repository or branch does not use its own security.
When multiple groups are associated with a user Surround SCM uses optimistic interpretation of conflicts. This means if a group has a setting turned off and another group has a setting turned on, if a user is a member of BOTH groups that setting will be turned on.
Branch security settings can only be used if the branch is configured to use its own security. To do this, right-click on a branch and select Properties. On the Security tab specify that the branch will "Use Own Security". Then, click the Branch tab in the Security Group settings to set specific security for the branch.
 Server, Repository, and Branch
Security exists on three levels in Surround SCM. The first is server security.
Server Security, which includes six categories, is used to manage global and administrator settings.
The Users and Security Groups operations are usually only made available to administrators. Some Admin rights, such as setting up triggers and email notifications, are enabled for power users and managers.
The File and Branch operations are the most important to setting up security rights for users and will be discussed in the best practice sections.
 Best Practice Approaches
 All Off, Some On Approach
This is possibly the most common system for setting security up in Surround SCM. By default all security settings are turned off and they are turned on selectively for specific mainlines.
When All Off, Some On (AFSO) is used, the users will typically have access to only one mainline per group. When new mainlines are created users will NOT have access to them. Users can then be added to the security groups that they should have access to.
For Paranoid settings disable all branch options except View Branch History.
For Relaxed settings enable all options except Destroy, which is an option reserved for administrators.
Promote and rebase can be very helpful or very dangerous branch operations. For relaxed environments, these commands will allow users to promote and rebase specific changes (such as in their workspace or in a baseline branch) to and from other branches. Promote and rebase mistakes can be disastrous, and, while Surround does have a rollback command, the Paranoid approach will lock the system down so that only power users or administrators can promote or rebase changes.
The server security settings disable access to all mainlines in Surround SCM, including any newly created mainlines. Once access to all mainlines is disabled, you can allow security groups to access specific mainlines.
To do this click on the Repository tab and use the Add button to specify the Mainline/Repository to enable access to.
Next enable all the security rights, with the exception of the Destroy command.
Create one security group for each mainline, and set up the repository security as shown for each corresponding mainline. Users' roles in Surround can be determined by the groups they are inBecause users can belong to multiple security groups, users can also have multiple roles in Surround SCM. For example, a user may be in a security group that allows access to most commands for one mainline, but be in another security group that restricts users to only viewing files for security reasons.
 All On, Some Off Approach
If users should have access to most projects, including new projects, but should have specific and unchanging restrictions to other projects, then the All On, Some Off (AOSO) approach will work best.
This approach grants default rights for users into the whole system. Then specific mainlines can be disabled, which prevents the group from accessing those branches. The result is a more Relaxed environment. As new repositories are created over time the default privileges will be all-on unless the group is changed after new repositories are created with new restrictions.
This is more popular for administrators who want to designate security by department as opposed to by team member's role. For example, the Marketing team has access to all the marketing mainlines but none of the developer mainlines and vice versa.
With this approach it may be necessary to modify the existing security groups when new mainlines are added to restrict other groups from seeing and accessing them.
The server security settings enable access to everything by default. To add restrictions, click the Repository tab and use the Add button to select a Mainline/Repository that the users in this group should not have access to.
Set the Security options to None (disable all). To allow read-only access, enable the View Repository List, Get, and View File History options.
Repeat this process for each group combination. With this approach users will typically only exist in one security group at a time, which may require additional maintenance to the group settings when new mainlines are added to the system.
 Per-User Definition Approach
The AFSO and the AOSO approaches allow an administrator to create roles by assigning users to one or multiple security groups. These approaches work in most situations but there may be times that users require specific access. In thise case, the administrator may need to create one security group per-user definition to define user access.
Creating groups for special needs tends to involve the highest amount of overhead and maintenance. As new projects and mainlines are added the administrator will have to modify security groups. If possible use a role-based solution that defines rights on a per-project or per-mainline approach. Otherwise the following may occur:
Per user settings allow for a combination of Relaxed and Paranoid settings for individual users. A user might be a Relaxed power user in one mainline or a restrained Paranoid user in another mainline. This is sometimes necessary for users with dual-roles of Admin and User where projects are split among multiple mainlines.
 Branching Methodology and Security
The security group settings can work hand in hand with branching practices and the SDLC methodology being used by the project manager. The existing capabilities can be leveraged to enforce system policies for change. One example is the 'Promotion state' model, which is popular for continuous change rollouts common with Web site development. This requires making use of branch level security.
 Branch Level Security
Branch level security is the most granular type of security Surround SCM offers. It is similar to repository security with one major difference. The repository security applies to the mainline and all branches underneath, while branch level security applies to repositories in just one specific branch.
Branch security has to be enabled for each branch individually. This is done by right-clicking on a branch and selecting Properties. On the Security tab specify that the branch will "Use Own Security".
Once this is done, edit one of the security groups and add new restrictions on the Branch tab.
In the example of the Reverse Waterfall branching technique from the Surround SCM Branching Strategies guide, it is necessary to allow users to check in to a baseline branch but also restrict access to QA and Staging branches that are used to rollout changes and to prevent unapproved changes from accidentally being shipped.
Following are the settings for the Developer group:
Users may need access to promote and rebase changes if they are using workspaces. The administrator can enable these options and still prevent users from promoting to a branch by using the following branch security options.
On the Branch tab click the Add button to add new restrictions to the QA branch. The options shown in the previous screenshot represent a read-only view; members of this group can still View and Get files but cannot check in or promote changes.
Repeat this step for other branches that should not be changed by developers like the Staging and Mainline branches.
In this approach there will be a security group for each department and a configuration management (CM) administrator. The developers need read/write access to a development baseline used to integrate changes. Workspaces can also be used to keep incomplete changes isolated.
It is also necessary to create a CM admin group whose members can promote or rebase changes from one branch (e.g., state or stage) to the next as changes are approved.
This type of approach can be made simpler by using the TestTrack Suite integration, which allows the CM admin to identify specific files ready for promotion using the issue tracking workflow and asset reports (like file manifest) available in TestTrack.
Branch level security follows a more Relaxed approach, because users will by default have full access to new branches. Branch level works well if there are not a lot of new branches, but it can become high maintenance if many branches are actively used.
 Administrator Group
Administrators are users who set up system configurations. They do not necessarily need access to File and Branch operations but all other category operations should be enabled.
 Code/Change Manager a.k.a CM Admin
CM admins are users who may be responsible for moving changes from one branch to the next. Users in this security groups can generally promote, rebase, check in, and check out in any active branch.
The CM admin group must be unique, which means it is possible that this group is created for a single person on a small team, but it is necessary to distinguish this set of security rights from the standard user and also from the administrator.
The CM admin is responsible for moving changes through different branches, which may represent different stages in a release cycle. Sometimes, CM admins do not even need to set working directories because the promote operations are performed server side. CM admins require check in privileges in order to promote changes, especially if manual 3-way merges will be used.
 Power User
There are several user-friendly features in Surround SCM that group leaders, project managers, or other users may want to take advantage of. These options can be found in the Admin category of Server Security. Power users will have Relaxed security roles that provide access to more features than then typical users.
These options can be enabled by themselves with all other options disabled. A power user can then be added to the power user group to have access to these additional features. Because Surround SCM uses an optimistic approach to conflicts, the user will retain all the rights of the primary group they are in, in addition to the rights granted by the power user group settings.
 Inheritance and Hidden Repositories
One tricky issue to get around in Surround SCM security settings is the fact that security is inherited from a parent repository to a child repository by default. This is the correct way to apply security, so that if you set read-only access to a repository for a group and then create new sub-repositories they will also be read-only. After all, it would not make sense if you had to set up security on every repository individually.
The one place where this makes it tricky to set up your ideal security settings is when you do not want projects to be visible to other users within a single mainline. In Surround SCM, you have to be able to see a parent repository in order to see the child, and if you set your root repository to hidden then all the children will also be hidden (even if you set up full access on a child), due to how this inheritance works and also because you cannot have gaps in the tree list view.
For the Paranoid security preference this may be something you need to do. It is still possible to achieve this type of configuration and this is how I recommend accomplishing it.
In Surround SCM when repository security settings are in conflict the higher level settings are used.
The net result is that everyone in the User group has a default level of privileges to login, to work with branches, and to see the root repository which is read-only. All the other repositories are invisible. Next, add the user to the Project groups they should belong to. They will then be able to see those repositories and have the level of access you have set for the group.
When new repositories are created all users will by default have read-only access to it. To correct this, all that is required is to edit your User group and add the additional repository with None access and then create your new Project group with the proper repository settings.
This is a highly maintainable approach as you scale up with additional projects you only need to manage the User group and the new Project group. Users can be easily moved in and out of multiple Project groups while all users belong to the default User group.