The simplest way to authenticate people is to create a password file for Cruise to use. This is just a plain text file with the following format:

[username]:[password hashed with SHA1 and encoded with base 64]

If your SHA1 algorithm and base 64 encoding works properly, the word "badger" should come out as "ThmbShxAtJepX80c2JY1FzOEmUk=".

You can use the htpasswd program from Apache to manage your password file. You must use the -s option with htpasswd to force it to use SHA1 encoding for the password. So for example, you can use the following command to create a password file called "passwd" and put the password for the user "user" in it:

htpasswd -c -s passwd user

You can put as many username / hashed password pairs as you like -- use a new line for each one.

Tell Cruise where the password file is using the following entry in the configuration file:

  <cruise>
    <server>
      <license ... />
      <security>
        
<passwordFile path="[path to password file]"/>

      </security>
    </server>
  </cruise>
  

As usual, Cruise should pick up this change immediately and start authenticating new users (note that anybody already using Cruise will be required to authenticate).

The file format for the password file is the standard one for Java Properties, which means in particular that spaces, the equals sign and the colon are special characters in the username and must be escaped with a backslash.

Cruise can be made to authenticate against any standard LDAP / AD server. Cruise uses the standard JNDI APIs to access LDAP / AD, with some help from the Acegi Security framework. Cruise can only use "bind" authentication, in which it authenticates directly to the LDAP / AD server.

You can use the following configuration to get Cruise to talk to your LDAP / AD server:

  <cruise>
    <server>
      <license ... >
      <security>
        
<ldap uri="[LDAP server URI]"
          managerDn="[LDAP server manager DN]"
          managerPassword="[LDAP server manager password]"
          searchBase="[LDAP search base]"
          searchFilter="[LDAP search filter]"/>

      </security>
    </server>
  </cruise>
  

The manager DN is the LDAP / AD manager user's DN, used to connect to the LDAP / AD server.

The manager password is the LDAP / AD manager user's DN, used to connect to the LDAP / AD server.

The search base is the name of the context or object to search in for the user record.

The search filter is the expression used in the user search. It is an LDAP search filter as defined in RFC 2254 with optional parameters -- in this case, the username is the only parameter. An example might be:

(uid={0})

which would search for a username match on the uid attribute, or

(sAMAccountName={0})

which would search for a username match on the sAMAccountName attribute (for ActiveDirectory users)

The authentication operation has two steps: firstly, Cruise uses the managerDn and managerPassword supplied to search for the user using the searchBase and searchFilter attributes. By default Cruise will search subtrees and time out after five seconds. Cruise then uses the DN returned to attempt to bind to LDAP / AD using the username and password supplied by the user.

Note that Cruise doesn't retrieve any further information from LDAP / AD such as roles, groups or email address. It simply gets the user's CN.

From Cruise 1.1, you can define roles that can be used anywhere that authorization is required. A role is just a group of users. You define roles in the security section of Cruise's configuration file. Here's an example:

<cruise>
  <server>
    <license ... />
    <security>
      <passwordFile path="/etc/cruise-server/passwords.properties" />

      <roles>
        <role name="qa">
          <user>dyang</user>
          <user>pavan</user>
        </role>
        <role name="cruise_admin">
          <user>jhumble</user>
          <user>qiao</user>
        </role>
      </roles>

      <admins>
        <role>cruise_admin</role>
        <user>chris</user>
      </admins>
    </security>
  </server>
</cruise>
  

In this example, the "qa" role has two users: dyang and pavan. The "cruise_admin" role also has two users: jhumble and qiao. The <admins> section of the configuration controls who is allowed to administer Cruise. We discuss it in the following section.

Cruise allows you to restrict the users who can perform certain functions. Only administrators are allowed to use the administration tab, and hence to change Cruise's configuration. Furthermore, only administrators can manage Cruise's build cloud.

The "admins" section is optional -- without it, all users are automatically made administrators. If you do include the admins section, only users and roles specified within it can administer Cruise.

In the example in the section above, members of the "cruise_admin" role (jhumble and qiao), along with the user chris, can administer Cruise.

If administrators are specified, only they can perform the following actions:

• Access the "administration" tab
• Add pipelines
• Approve agents
• Add / remove agent resources

In Cruise, it is possible to specify manual approvals between stages. From Cruise 1.1, you can specify who is able to trigger manual approvals. In the example below, only members of the role "qa", and the user "jerry", can trigger the approval.

      <stage name="uat">

        <approval type="manual">
          <auth>
            <role>qa</role>
            <user>jerry</user>
          </auth>
        </approval>

        <jobs>
          <job name="deploy">
            <resources>
              <resource>uat</resource>
            </resources>
            <tasks>
              <ant target="deploy" />
            </tasks>
          </job>
        </jobs>
      </stage>