July 15, 2011

Configuring File Access Permissions in Surround SCM

Surround SCM
In a recent post, I discussed how to use security groups in TestTrack to simplify the Item window. In this post, I'm going to cover Surround SCM security groups, specifically the permissions that control the access to files. To access security groups go to View > Security Groups...

Understanding File Access Permissions in Surround SCM

Surround SCM provides three levels of file access permissions, and these are set for each security group.

Default Security

These are the permissions that will, by default, apply to all files on all branches and repositories. These are set on the Server Security tab of the Security Group window. Under the "Files (Default)" category you specify the file access permissions that will be the default for all branches and repositories. In the following screenshot, you'll see that the Dev Team has all file permissions enabled except Destroy on all branches and repositories across all mainlines. [caption id="attachment_9031" align="aligncenter" width="230"]Edit Security Group Window Edit Security Group Window[/caption]

Repository Security

Use Repository Security to set permissions for a repository across all branches. These are set on the Repository Security tab in the Security Group window. Repository Security permissions will override any permissions set in the "Files (Default)" category on the Server Security tab. In the following screenshot, you'll notice that the Dev Team cannot access the Marketing repository at all. Because the repository is the  root of the Mainline, the Mainline branch is not visible to members of this team. The Dev Team also has limited access to the WysiCRM repository. Remember, repository security applies across all branches. [caption id="attachment_9034" align="aligncenter" width="331"]Repository Security Repository Security[/caption]

Branch Security

Use Branch Security to set permissions for a repository in a specific branch. These permissions will override any "Files (Default)" Server Security or Repository Security permissions. In the following screenshot, the Dev Team has no access to the Wysi CRM 1.x branch. They do not even see it or know that is there. [caption id="attachment_9037" align="aligncenter" width="410"]Branch Security Branch Security[/caption] To make the Branch Security tab available, you need to set the branch to use its own security. You do this in the Properties window of the branch as shown below. [caption id="attachment_9082" align="aligncenter" width="330"]Branch Properties Branch Properties[/caption] Note that you can also set branch security in the Properties window of a specific repository in a specific branch. The main difference is that you can configure multiple security groups at the same time, as shown in the following screenshot. [caption id="attachment_9051" align="aligncenter" width="410"]Repository Properties Repository Properties[/caption] Use the Security Group window to set branch security when you are configuring a single group, such as when you configure a new security group. Use the Repository properties window when configuring the security for a specific branch and repository across many security groups, such as when you add a new branch or repository to Surround SCM.

Approaches To Configuring File Access Permissions

Keep It Simple!

Surround SCM allows a user to belong to more than one security group. This is a useful feature because you don't have to create a security group for every possible role that your organization may have. But don't go overboard! If you have a user that belongs to five security groups, and each group has repository and branch security enabled, it may be difficult to answer "why doesn't this user see this branch?". In case you do encounter this situation, the Security Group Comparison Report should help you figure out permissions.

All Off, Some On

One approach is to set the default permissions to none. This would hide all mainline branches from users by default. You can then use repository and branch properties to specifically set the branches and repositories that the group should have access to.

All On, Some Off

Another approach is the opposite of all off, some on. In this approach, set the default permissions to all (maybe except destroy). Then use repository and branch security to specifically set the branches and repositories that the group should not have access to. The best approach will depend on the security group you are configuring. If a group is going to be very limited to what branches and repositories are accessbile, it may be easier to start with the All Off, Some On approach and then enable the few repositories and branches that the group should have access to. On the other hand, for a group that should have access to most of the branches and repositories, it would be easier to start off with the All On, Some Off approach, because you would only need to configure permissions for a few branches and repositories.

Words of Wisdom

Here are a couple of  things to keep in mind when configuring file access permissions at the repository and branch level:
  • You should always have a security group that has permissions to access and see everything.
  • In order to see a child repository or branch you need to be able to see its parent.

Where did that branch go?

If you are not careful, it is possible to get into a situation where you hide a branch from everyone, to the point where you cannot access it to change the permissions. It may be also difficult to determine if the branch is actually hidden because of security, or if a user removed or even destroyed the branch. Under Tools > Administration > Branch Maintenance... there is a check box labeled "Ignore branch security". If the branch appears when you check this box, then it is hidden because of security. [caption id="attachment_9059" align="aligncenter" width="356"]Branch Maintenance Branch Maintenance[/caption] Once you determine that the branch is hidden because of security, use the command line interface to reset its file access permissions. The branchproperties (bp) command allows you to reset the permissions in a specific branch. In the following screenshot, I'm using the "-o" option to set it so the branch uses file access permissions that apply to all branches. If you are using an All Off, Some One approach, you may want to use the "-i" option, which sets the branch to inherit the file access permissions from its parent. [caption id="attachment_9062" align="aligncenter" width="543"]branchproperties (bp) command branchproperties (bp) command[/caption]

Other Resources

Check out the Surround SCM help and security best practices for more information about configuring security groups and restricting user access to files.