You are browsing the documentation for iTop 2.4 which is not the current version.

Consider browsing to iTop 3.2 documentation

User Authentication Options

In order to seamlessly integrate with your environment, iTop can use several authentication mechanisms. Some part of the iTop behavior is defined at the web server level, however it is possible to mix the different authentication types on a per user basis.

For example if you already have an LDAP server for authenticating the end-users, it may be convenient to use this LDAP authentication for end-users and local passwords for functional logins (for automation processes and scripts).

Authentication types

In the context of this document, “External authentication” means that the user authentication is performed completely outside of iTop (by the web server or some kind of web server add-on). In this case the iTop application will just be passed the name of the authenticated user, once it has been validated by the web server. This is what happens if you install iTop under Apache in a directory protected with a .htaccess file.

When deploying iTop, you have to decide whether the application will use an external authentication mechanism or rely on the iTop internal mechanism. If the application uses “internal” authentication, then several types of authentication may coexist for the same installation (for example you can configure iTop to use the form based dialog and use a mix of LDAP and Internal users).

Different types of user Accounts

If the authentication is not “external”, then iTop will actively participate to this authentication. Currently iTop supports two types of internal authentications:

  • “Local”: based on passwords stored encrypted in the iTop database
  • “LDAP”: by interacting with a remote LDAP or Active Directory server

Logon Types

In order to authenticate a user, the application has to prompt the user for a login and a password. iTop provides several methods to handle this dialog with the end user:

  • “Form based dialog”: this is the default mechanism that displays a formatted dialog to the end-user, as shown on the picture below:

iTop Login Form

  • “Basic Authentication”: this mechanism relies on the Basic Authentication of the HTTP protocol. With most web browsers, this appears as a pop-up to the end user. Command line tools (like wget) can generally use this type of authentication.

Basic Authentication Popup Dialog

  • “CAS”: in this mode iTop delegates the authentication to a CAS compatible server
  • URL”: Some scripts or applications have very limited capabilities for passing authentication credentials. In such a case it is possible to pass directly a login and password as parameters in the URL. Note that due to security considerations, this method is disabled by default, but can be enabled by configuration.
  • “External”: This type of login is used when the authentication has already been performed by the web server and iTop is just passed the name of the authenticated user as server side variable.

The different possibilities can be summarized in the table below:

Logon Type Purpose Limitations
form Form based logon, best suited for interactive logon. Provides also a logout/logoff functionality Not designed for use by batch/scripts or when the web browser is “hidden” from the end-user (i.e. Excel web queries)
basic Basic HTTP authentication. Compatible with all applications supporting this protocol (e.g. wget, Excel web queries) No logoff/logout functionality.
cas Use JA-SIG CAS APIs to connect to a CAS server for authentication Provides transparent single-sign-on with other CAS applications, for example a LifeRay portal
url Compatible with any application. Needed if you want to run web queries in OpenOffice. The password has to be written in clear text in the address of the page !
external Used when the authentication is performed by the web server itself before even accessing the iTop application. iTop does not perform any authentication when an “external” user connects. iTop simply trusts the parameters passed by the web server.

Configuration file

The parameter allowed_login_types in the iTop configuration file determines the behavior of the iTop application by defining which logon methods are enabled, and in which order the application will try them.

This parameter is a text string, in which the values are separated by the pipe ( | ) character. The string is made of a combination of form, basic, url, cas and external in the desired order.

The default mode is the first one in the list. It defines the behavior of the application when no credential is supplied. The first “mode” must be one of form, basic, cas or external.

'login_mode' page parameter

When connecting to any iTop web page, it is possible to override the default login mode, by specifying the parameter “login_mode” in the URL.

The value is one of the allowed modes: form, basic, url, cas, external. This login mode will be used (for this connection only, it's not persisted) provided that the corresponding mode is enabled in the configuration file. If the value is not valid, it is ignored and the first “mode” defined in the configuration file is used.

For example if the configuration file contains:

allowed_login_types => 'form|basic|external',

and a page is called with the parameter ?login_mode=basic, then the Basic authentication mechanism will be used for this page.

Now if a page is called with the parameters ?login_mode=url&auth_user=foo&auth_pwd=bar, the url mode being excluded from the configuration, the default mode (in the example above: form) will be used.


For an instance of iTop in which the users are authenticated either by the local password (stored in the iTop database) or by an LDAP server, and using either their web browser (to navigate in the application) or Microsoft Excel to run some reports (as web queries), the following value can be put in the configuration file:

'allowed_login_types' => 'form|basic',

When connecting to the application, end-users will be prompted to enter their login/password using the usual iTop login form. When using the application interactively, the end-user can log off the application using the “log off menu”.

When using Excel, it is possible, by adding &login_mode=basic at the end of the link to the page used for the web query, to have Excel prompt the user for their login/password when the web query is launched for the first time.

In this configuration is it also possible to have scripts retrieving data from iTop using a command line application like wget, with the following syntax:

wget --http-user=<login> --http-password=<password> -O test.csv --auth-no-challenge ""

Or by using this alternate command line:

wget --no-check-certificate --http-user=admin --http-password=admin2 -O test.csv ""

In the first command line, wget will send automatically the credentials to the web server (using the Basic authentication mechanism) and iTop will detect their presence.

In the second case, wget will not send any credentials first, but telling iTop that the preferred way to authenticate is “basic” (i.e. basic authentication), wget will get a response “401 unauthorized” from the web server, and will retry with the supplied credentials.

Basic Authentication and Apache in CGI mode

PHP inside the Apache web server can be configured to run in two different modes: as a module or as a CGI.

When using the basic authentication mechanism, iTop relies on the web server to populate two PHP internal variables: $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_USER']. When PHP runs as an Apache module, the two variables are automatically populated by the web server when the end-user fills the “basic authentication” pop-up dialog but this is not the case when PHP runs as a CGI.

In this latter case, a simple rewrite rule can be used to pass the authentication information to PHP.

Here is how to do it:

Make sure that the rewrite engine module is activated in Apache, otherwise the “rewrite rule” will be ignored (if you are not sure if the rewrite engine is no, you can comment out the two lines <IfModule mod_rewrite.c> and </IfModule> in the sample below. Then restart Apache. If you seen an error about “RewriteEngine on” not being recognized as a valid configuration directive in the Apache log file, then rewrite engine is not configured on your web server).

Use your favorite test editor to write the following code in a .htaccess file at the root of the iTop web directory (make sure that the user that runs the PHP/CGI process has enough rights to read this file).

<IfModule mod_rewrite.c> 
RewriteEngine on 
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L] 

This causes the Apache server to populate the server variable $_SERVER['HTTP_AUTHORIZATION'] with the credentials (base64 encoded). iTop reads and decodes this variable to extract the login and password.

Integrating with an external authentication

iTop can use an external authentication mechanism (Apache's .htaccess file, CA SiteMinder agent, etc…), however the users' profile is always defined in iTop and for each user allowed to connect to iTop there must be an iTop “External user” record in the database.

When using an external authentication mechanism, any request to the iTop application is intercepted and the end-user is asked to enter her/his authentication before connecting to iTop. In such a case iTop is unaware of the authentication means (login/password, certificate stored on smart card…). The only information that matters to iTop is the “login” (i.e. identifier) of the authenticated user.

iTop uses the standard mechanism for PHP applications by reading the server variable $_SERVER['REMOTE_USER']. If an “External user” record with the corresponding login is found in the iTop database, this user will become connected to iTop. If no match is found, the next authentication mechanism will be used and the user will prompted to authenticate with iTop.

Depending on the external authentication mechanism used, the web server may place the authentication information in different variables, therefore the variable used to retrieve this “external authentication” can be specified in the iTop configuration file. Look for the parameter:
ext_auth_variable => '$_SERVER[\'REMOTE_USER\']',

For example if your single-sign-on system uses the cookie variable auth_user to pass the user name, you can use something like:

ext_auth_variable => '$_COOKIE[\'auth_user\']',
In order to ensure that the external authentication is used first (preventing iTop from prompting the already authenticated user a second time), make sure that in the iTop configuration file, the order for allowed_login_types specifies “external” as the first login mode, as shown below:
'allowed_login_types' => 'external|form|basic',
Single Sign-On on Windows

Since iTop uses the PHP variable $_SERVER['REMOTE_USER'] to identify external users, this becomes really simple if your web server is running on Windows. Using IIS you can rely on the Integrated Windows Authentication and if using Apache you can use the sspi_auth_module. Both will set the variable $_SERVER['REMOTE_USER'] to the authenticated user as “DOMAIN\USERNAME”. Simply create your External users names the same way: DOMAIN\USERNAME and the iTop authentication will be transparent to your end users.

Sample configuration for external authentication

In the sample below the users are authenticated by a .htpasswd file stored in /var/www/.

iTop configuration

$MySettings = array( 
        'allowed_login_types' => 'external|form|basic', 

Apache configuration file

<Directory /var/www/> 
        AuthUserFile /var/www/.htpasswd 
        AuthName "Please identify yourself..." 
        AuthType Basic 
        require valid-user 

Integration Test script

If you use a third party authentication mechanism, you can place the following PHP script in a file in the /pages directory of iTop. Then point your web browser to it to test if your external authentication passes the appropriate information to iTop.

// Script to test External Authentication 
echo "<h1>External Authentication: Integration Test Script</h1>"; 
        $aAllowedLoginTypes = utils::GetConfig()->GetAllowedLoginTypes(); 
        $sAllowedLoginTypes = implode('|', $aAllowedLoginTypes); 
        echo "<p>allowed_login_types set to '$sAllowedLoginTypes'</p>\n"; 
        if (!in_array('external', $aAllowedLoginTypes)) 
                    echo "<p>Check your iTop configuration file, ". 
                           "<b>allowed_login_type</b> does not enable ". 
                           "'external' authentication.</p>"; 
                   echo "<p>Ok, external authentication is enabled by allowed_login_type.</p>"; 
                $sExternalAuthVariable = utils::GetConfig()->GetExternalAuthenticationVariable(); 
                echo "<p>External Authentication Variable: '$sExternalAuthVariable'</p>\n"; 
                if ($sExternalAuthVariable != '') 
                        $sEval = '$bVarIsSet = isset('.$sExternalAuthVariable.');'; 
                        if ($bVarIsSet) 
                                $sEval = '$sAuthUser = '.$sExternalAuthVariable.';'; 
                                echo "<p>External Authentication Variable set to: ". 
                                if ($sAuthUser != '') 
                                        echo "<p><b>Ok, integration with external authentication ". 
                                                 "successful !</b></p>\n"; 
                                        echo "<p>Empty user information passed by the web ". 
                                echo "<p>External Authentication Variable <b>NOT</b> set.</p>\n"; 
                        echo "<p>Check your iTop configuration file, <b>ext_auth_var</b> is set ". 
                                 "to an empty string.</p>\n"; 
catch(ConfigException $e) 
        echo "<p>iTop configuration file not found. Did you already install iTop ?</p>\n"; 
echo "<hr/>\n"; 
echo "<p>For information:</p>"; 
echo "<pre>\$_SERVER variable:\n"; 
echo "\$_COOKIE variable:"; 
echo "</pre>\n"; 

Configuration of LDAP authentication

iTop supports LDAP authentication against a remote LDAP server (or Windows Active Directory server). Both types of users (users with an account stored in the iTop local database and users with an LDAP account) can coexist on the same instance of iTop, on a per user basis.

LDAP users are created by selecting the appropriate type when prompted for a “New user Account”:

New LDAP User

Configure iTop to connect to your LDAP server

Once iTop is installed, open the file 'config-itop.php' and look for the section authent-ldap . It should looks as shown below:

      'authent-ldap' => array ( 
                  'host' => 'localhost', 
                    'port' => 389, 
                    'default_user' => '', 
                    'default_pwd' => '', 
                    'base_dn' => 'dc=mycompany,dc=com', 
                    'user_query' => '(&(uid=%1$s))', 
                    'options' => array ( 
                                                17 => 3, 
                                                8 => 0, 
                    'debug' => false, 


  • The host parameter must contain the IP address or host name of your LDAP server
  • The port parameter is the TCP port number to be used for connecting to LDAP (LDAP's default is 389)
  • default_user and default_pwd identify an LDAP account with enough rights to connect to your LDAP server (in read-only mode) in order to search for the specified user. On most systems an anonymous user can do this, so you can leave these two fields blank.
  • base_dn defines the “root” used for searching for the user/logins. It can be something like “dc=mycompany,dc=com” or “ou=People,dc=mycompany,dc=com”. If you're not sure, ask your LDAP administrator.
  • user_query defines a LDAP query that will be used for searching for the users. You can write whatever valid LDAP query using any of the following placeholders:
    • %1$s : iTop login of the user (i.e. what he/she types in the login form)
    • %2$s : User's First Name
    • %3$s : User's last name
    • %4$s : User's email
  • debug must be set to true to turn on debug traces output (in the file log/error.log). Since the debug traces contain passwords in clear text, it is recommended to turn them off in production, but they are useful to troubleshoot the behavior of the application during configuration phases.
The host parameter can contain a list of LDAP servers separated by a space. If the first server in the list fails to respond, the code will try the second one, and so on.
    'host' => 'ldap:// ldap://', 
When connecting to a Windows Active Directory the query to retrieve the user based on her/his Windows login looks like: '(samaccountname=%1$s) '
The parameters %2$s, %3$s and %4$s are non-empty only if the User record (in iTop) is associated with a Person (i.e. if the “Contact” field is not empty for this User).

The last part of the configuration, options defines some LDAP specific options. See for the full list of possible options. You can use either the PHP constants (like LDAP_OPT_PROTOCOL_VERSION - with no quote) or their numeric equivalent (i.e. LDAP_OPT_PROTOCOL_VERSION equals 17). In the example above:

If you get an error 'Cannot bind to LDAP server, invalid DN syntax', check the syntax of the 'default_user' in your iTop configuration file. For some LDAP servers, the user name must be a complete name like: 'cn=admin,dc=mycompany,dc=com' and not just 'admin'.
2_4_0/admin/user_authentication_options.txt · Last modified: 2018/12/19 11:40 (external edit)
Back to top
Contact us