With a few exceptions, a user cannot execute AccuRev commands unless he is authenticated as a registered AccuRev user. For authentication purposes, each registered AccuRev user has a username/password pair recorded in the database. A user’s password can be empty.
AccuRev automatically distinguishes two categories of users — those who have empty passwords, and those who have non-empty passwords. The keywords
authuser and
anyuser, respectively, are used by the ACL facility to designate these categories. See
secinfo on page 221 of the
AccuRev CLI User’s Manual for more information.
AccuRev supports authenticating a user through an explicit login to the AccuRev Server. Using the GUI or the CLI, the user invokes the
Login command and enters his password (possibly empty). This launches a user session, which is typically of limited duration (a few hours). When the session expires, the user must login again to continue using AccuRev.
This feature provides tremendous flexibility. For example, an authentication script could use an external user database, accessed through an LDAP interface, to perform AccuRev user authentication.
Prior to V4.7.3, any authentication scheme on the master was only as trustworthy as the security of all the replica servers. The changes to replica authentication in AccuRev 4.7.3 allow sites using replication to deploy replicas to sites they may not trust to do user authentication, by allowing user authentication to be performed on the master server only.
Use the MASTER_AUTHENTICATES_LOGIN parameter in the
acserver.cnf file on the master server:
As a result of these changes, the XML input to the server_auth_trig script has changed to add
server and
port elements, which should contain the hostname and port of the master server.
The server_auth_trig user-authentication script, used by the
custom user-authentication method, is similar to the
server_admin_trig administrative trigger script. A sample script, implemented in Perl, is included in the AccuRev software distribution, in the
examples subdirectory.
The script is called when a user invokes the AccuRev Login command. It executes in a subprocess of the AccuRev Server. The script’s standard input is a simple XML document, with the structure shown in this example:
<triggerInput> <hook>server_auth_trig</hook>
<command>login</command>
<ip>192.168.6.186</ip>
<username>derek</username>
<password>MyP@ssw0rd</password>
<server>myserver</server>
<port>5050</port>
</triggerInput>
(No password encryption is necessary, because this XML document is passed to the subprocess through an operating system pipe, not through a file.) The script’s standard output is appended to file
triggers.log, located in the
logs subdirectory of the
site_slice directory. No output is required, however; only the script’s exit status is significant:
The user’s Login command also fails if the script does not execute properly — for example, if a runtime error occurs or the script file is not executable.
When you install AccuRev on the machine where the AccuRev Server process will run, the AccuRev Installation Wizard automatically sets the authentication method. Thereafter, you can switch methods with the
authmethod command. Example:
The current user-authentication method is stored in file preferences.xml in the
site_slice directory. (Don’t confuse this with individual users’
preferences.xml files.) For example:
As an alternative to the authmethod command, you can change the user-authentication method by editing this file, then stopping and restarting the AccuRev Server process.
User authentication is performed by the add-new-user command (GUI: Add User, CLI:
mkuser). To prevent a chicken-and-egg problem, user authentication is bypassed if the AccuRev user registry is currently empty. After the first AccuRev user has been created, only an authenticated user can add users to the AccuRev user registry.