Security

The security tab is used to manage admin accounts, either entered manually into SVN MultiSite Plus or managed through an LDAP authority. On the tab is an entry form for multiple admin accounts, along with LDAP Settings for binding MultiSite to one or more LDAP services.

SVN MultiSite Plus - Security

Add User: Enter the details of an additional administrator who will be able to login to the SVN MultiSite Admin UI. See Adding additional users for more information.
Add Authority: Enter the details of one or more LDAP authorities for managing administrator access. See Adding LDAP authorities for more information.
Disable Managed Users: This feature lets you block access to the SVN MultiSite Admin UI by non-LDAP users. See Disabling (Internally) Managed Users below.
Enable SSO: This button will only be available to click if you have entered valid Kerberos settings. When enabled it places SVN MultiSite Plus's admin console into Single Sign-on mode. When enabled accessing the admin UI will use Kerberos instead of the username and password login form. In the enabled state the button will change to say Disable SSO.
Export Security Settings: The data entered into the Securities tab can be backed up for later re-importing by clicking the Export Security Settings button. The data is stored in /opt/wandisco/svn-multisite-plus/replicator/export/security-export.xml which should be included in any backup procedures you are running. You will need access to the file from your desktop during a re-import.
Import Security Settings: Click the Import Security Settings button if you need to restore your Security settings, such as after a re-installation of SVN MultiSite Plus. The import will proceed providing that you can enter a file path to the security-export.xml file.
Reload: Click on the reload button to refresh the Admin UI screen, you will need to do this in order to view any changes that you make.

Admin Account Precedence

SVN MultiSite Plus uses the following order of precedence when checking for authentication of users:

First: Internally managed users (if they are enabled - see Disable Managed Users)
Second: Local LDAP authorities by order
Third: Global LDAP authorities by order

Explanation

This provider implementation tries to authenticate user credentials against either the list of internally managed users, or against any number of LDAP authorities, or both -- depending on how the administrator has configured the application.

When authenticating against LDAP authorities, each one is tried in sequence until one either grants access or they all deny access. In the event that they all deny access, only the error from the last authority tried will be returned.

Admin Accounts

Admin account changes are replicated to all nodes.
Changes to admin accounts are handled as proposals that require agreement from a majority of every node in the replication network.
Admin account changes are reported into the audit log.

Disable (Internally) Managed Users

Click the Disabled Managed Users button if you want to control access to SVN MultiSite Plus exclusively through LDAP. Once clicked, any Internally managed users will no longer be able to log into the Admin UI after they next log out. From that point only LDAP managed users will have access to the SVN MultiSite Plus Admin UI.

Re-enable Internally Managed users
If, after disabling Internally Managed Users you need to enable them again -- should there be a problem with your LDAP authorities -- then it is possible to enable access again by logging into the node via a terminal window (with suitable permissions), navigate to the following directory:

/opt/wandisco/svn-multisite-plus/replicator

and run the reset script:

java -jar resetsecurity.jar

Any internally managed users who remain in SVN MultiSite's database will have their access restored.

Internally Managed Users

SVN MultiSite Plus - Internally Managed Users

This table lists those admin users who have been entered through the Admin UI or imported using the Import Security Settings, along with the first admin account.

Admin Account #1

Note that the first admin account is the one set up during the installation of your first node. The credentials specified during this installation are stored to the users.properties file which is then used during the installation of all subsequent nodes.

** Alert! ** Admin Account Mismatch
The users.properties file is used to ensure that exactly the same username/password is used on all nodes during installation. In the even that there's a mismatch then you wouldn't be able to connect the nodes together (through the Induction process). Rather than clean-up and reinstall you can fix this by manually syncing the password files.

Admin Account #1 can be removed but the last admin account remaining on the system will not be deletable to ensure that it isn't possible for an administrator to be completely locked out of the admin UI.

Kerberos

Support for the Kerberos protocol is now included. When enabled, Kerberos handles authentication for access to the admin UI, where the administrator is automatically logged in if their browser can retrieve a valid Kerberos ticket from the operating system.

** Alert! ** You can't mix and match log-in type
When Kerberos SSO is enabled only users who are set up for Kerberos will be able to access the admin UI. The username and password login form will be disabled. If you ever need to disable Kerberos authentication this can be done using the authentication reset script which will return your deployment to the default login type.

kerberos settings entry form

Service Principal

A service principal name (SPN) is the name that a client uses to identify a specific instance of a service.

Example:

HTTP/host.example.com

Keytab File

The keytab is the encrypted file on disk where pairs of Kerberos principals and their keys are stored.

Example:

/tmp/krb5.keytab

Kerberos 5 Realm Configuration File

The krb5 configuration file location of the replicator host's Kerberos 5 realm configuration.

Example:

/etc/krb5/krb5.conf

Never replicated, always configured 'per-node'
Kerberos configuration is not replicated around the replication network because each node in the network needs its own host-specific configuration. This configuration is node-local only. The configuration needed is the host-specific service principal name, noted in the settings above. e.g.

On most systems the location of the host's encrypted key table file will be something something like:

/etc/krb5.keytab

The location of the host's Kerberos 5 realm configuration may be something like /etc/krb5.conf or /etc/krb5/krb5.conf

LDAP Authorities

LDAP Authority entry forms

Node-Local LDAP Authorities: If chosen, then only the local node will use the LDAP authority for authentication.
Replicated LDAP Authorities: If replicated is chosen, all nodes in the replication network can use the LDAP authority for authentication.

Mixing Local and WAN-based authorities

Both kinds of authority are supported simultaneously, with the node-specific LDAP authorities taking precedence over WAN-based authorities in order to support the use-case where, for example, a particular node may prefer to use a geographically closer LDAP directory. Also, if multiple LDAP authorities of either type are configured then the order in which they are consulted is also configurable, using the +/- buttons at the end of each entry.

Order: LDAP authorities are listed in the order of execution that you set when defining each authority's properties.
Url: The URL of the authority. The protocol "ldap://" or "ldaps://" are required.
Bind User DN: Identify the LDAP admin user account that SVN MultiSite will use to query the authority.
Search Base: This is the Base DN, that is the location of users that you wish to retrieve.
Search Filter: A query filter that will select users based on relevant LDAP attributes. For more information about query filter syntax, consult the documentation for your LDAP server.
Remove: Click to remove the authority from SVN MultiSite Plus.
Edit: Click to make changes to the authority's settings.

The usual configuration options are supported for each configured LDAP authority: URL, search base and filter and bind user credentials. Note that the bind user's password cannot be one-way encrypted using a hash function because it must be sent to the LDAP server in plain text, so for this reason the bind user should be a low privilege user with just enough permissions to search the directory for the user being authenticated. Anonymous binding is permitted for those LDAP servers that support anonymous binding.

LDAP Home or away

When adding an LDAP authority, the configuration can be selected to be either replicated or node-specific.

Replicated LDAP Authorities

If node-specific is chosen, then only the local node will use the LDAP authority for authentication. Both kinds of authority are supported simultaneously, with the node-specific LDAP authorities taking precedence over WAN-based authorities in order to support the use-case where a particular node may prefer to use a geographically closer LDAP directory, for example. Also, if multiple LDAP authorities of either type are configured then the order in which they are consulted is also configurable.

The usual configuration options are supported for each configured LDAP authority: URL, search base and filter and bind user credentials.

** Alert! ** Just enough permissions
The bind user's password cannot be one-way encrypted using a hash function because it must be sent to the LDAP server in plain text. For this reason the bind user should be only have enough privileges to search the directory for the user being authenticated. Anonymous binding is permitted for those LDAP servers that support anonymous binding.