Understanding access permissions for distributed VDFS repositories

Applies to: VisualSVN Server 3.7 and later

Аccess permissions work identically for both distributed VDFS and non-distributed repositories, as described in the KB33: Understanding VisualSVN Server authorization article.

However, distributed VDFS repositories also allow the access permissions used for the Windows authentication to be automatically replicated from a master repository to the connected slave repositories. Starting from VisualSVN Server 3.7, a VDFS repository may be configured to either use the replicated permissions or to use a standalone (non-replicated) set of permissions. This may be achieved through the use of the separate authorization profiles.

An authorization profile is an independent set of access permissions for a repository. When your server is configured to use Windows authentication, every VDFS repository has two different authorization profiles — Shared and Local. Permissions in the Shared authorization profile are automatically replicated from the VDFS master to the connected slave repositories. Permissions in the Local authorization profile are specific to the particular repository and are never replicated between the repositories.

At each moment of time, only one authorization profile can be active. An active authorization profile is a profile that controls the actual access to the repository by the users. The active authorization profile can be selected using VisualSVN Server Manager. The access permissions in both profiles may be changed independently.

Shared authorization profile for Windows authentication

The Shared authorization profile is active by default. Permissions in the Shared authorization profile are automatically replicated from the VDFS master to the connected slave repositories.

Permissions in the Shared authorization profile can only be modified for the master repository. For all the slave repositories, the permissions in the Shared profile are read-only. Changes to the Shared authorization profile of the master repository are immediately propagated to the Shared profiles of the connected slave repositories. Note that the changes to the Shared authorization profile are propagated irrespectively of whether this profile is active or not.

For example, let’s assume that you have a master repository with an active Local authorization profile and a slave repository with an active Shared authorization profile. If you modify the permissions in the Shared authorization profile of the master repository (without making that Shared profile active), these changes will be immediately propagated and take effect on the slave repository.

Shared authorization profiles can be used when the master and slave servers are located in the same or trusted Active Directory domains if you would like to have the same permission settings across your distributed VDFS repositories.

Local authorization profile for Windows Authentication

Permissions in the Local authorization profile are specific to the particular repository and are never replicated to other servers. In other words, when you modify permissions in the Local authorization profile of the master repository, these changes are isolated, and the connected slave repositories are not affected by them.

Local authorization profiles can be used:

• When the master and slave servers reside in the different non-trusted domains or if there is no domain at all.
• If you would like to have separate permissions for the master and slave repositories.

Non-replicated global access permissions for Windows authentication

Servers configured to use Windows authentication support a concept of global (or server-wide) access permissions. Global permissions are combined with the permissions configured for each repository on this server (including the distributed ones), according to the principles described in KB33: Understanding VisualSVN Server authorization. You can inspect global access permissions configured for your servers by opening the properties of the Repositories node in VisualSVN Server Manager or by running the Get-SvnAccessRule -Global PowerShell command.

In a distributed environment, master and slave servers always have their own sets of global Windows permissions. In other words, global access permissions are never replicated between different servers.

See also