A small extension to add the SAML SSO to iTop. The extension embeds the onelogin/php-saml library and can be deployed as any other iTop extension.

The extension extends the login page and provides 2 extra pages: acs.php (Assertion Consumer Service, the return page after a successful login by SAML) and sls.php (Single Logout Service, the return page after a successful logout by SAML).

The login can be either transparently redicted to the SAML IdP server or co-exist with the traditional login/password form, as shown below:

This extension had been tested with the following Identity Providers:

• Keycloak
• Sign and Go
• Simple SAML
• ADFS Windows
• Azure AD
• Okta

The user provisioning (i.e. creation of the user accounts in iTop) is handled not by this extension. The current version of the extension only enables the authentication of existing iTop user accounts by a SAML IdP.

• A SAML Identity Provider (IdP) server configured to be accessible from iTop.
• iTop accounts of the class ExternalUser corresponding to the SAML users.
• if You use itop data collector for ldap, you need the latest version 1.2.4 if SAML is the default authentication

You can use the menu “SAML Configuration” to generate the configuration for iTop as a SAML Service Provider and to import the metadata of your Identity Provider into iTop.

To configure iTop as a Service Provider (SP) follow these steps (in this order):

1. Import the XML meta data of your Identity Provider into iTop using the first form of the configuration wizard.
2. Select the appropriate attribute to get the login from your IdP and generate a pair of private key and certificate, then save the Service Provider configuration using the second form of the configuration wizard.
3. Export the XML meta data to your IdP using the link at the bottom of the page.

Once the configuration is complete, it is located in the section combodo-saml of the iTop configuration file.

It should looks as shown below:

config-itop.php

'combodo-saml' => array (
    'strict' => true,
    'debug' => false,
    'retrieveParametersFromServer' => true,
    'idp' => array (
      'entityId' => '',
      'singleSignOnService' =>
      array (
        'url' => '',
        'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
      ),
      'singleLogoutService' =>
      array (
        'url' => '',
        'responseUrl' => '',
        'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
      ),
      'nameid' => 'uid',
      'sp' => array(
          'entityId' => 'https://....',
          'privatekey' => '.....',
          'x509cert' => '.....',
      ),
      'security' => array(
          'wantMessagesSigned' => false,
          'wantAssertionsSigned' => true,
          'authnRequestsSigned' => true,
          'logoutRequestSigned' => true,
          'logoutResponseSigned' => true,
      ),
    ),

All the possible parameters are:

Commented version of the configuration:

config-itop.php

'combodo-saml' => array (
    // If 'strict' is True, then the PHP Toolkit will reject unsigned
    // or unencrypted messages if it expects them to be signed or encrypted.
    // Also it will reject the messages if the SAML standard is not strictly
    // followed: Destination, NameId, Conditions ... are validated too.
    'strict' => true,
    // Enable debug mode (to print errors).
    'debug' => false,
    // Service Provider Data that we are deploying.
    // Identity Provider Data that we want connected with our SP.
    'idp' => array (
        // Identifier of the IdP entity  (must be a URI)
        'entityId' => '',
        // SSO endpoint info of the IdP. (Authentication Request protocol)
        'singleSignOnService' => array (
            // URL Target of the IdP where the Authentication Request Message
            // will be sent.
            'url' => '',
            // SAML protocol binding to be used when returning the <Response>
            // message. OneLogin Toolkit supports the HTTP-Redirect binding
            // only for this endpoint.
            'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
        ),
        // SLO endpoint info of the IdP.
        'singleLogoutService' => array (
            // URL Location of the IdP where SLO Request will be sent.
            'url' => '',
            // URL location of the IdP where the SP will send the SLO Response (ResponseLocation)
            // if not set, url for the SLO Request will be used
            'responseUrl' => '',
            // SAML protocol binding to be used when returning the <Response>
            // message. OneLogin Toolkit supports the HTTP-Redirect binding
            // only for this endpoint.
            'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
        ),
        // Public x509 certificate of the IdP
        'x509cert' => '',
        /*
         *  Instead of use the whole x509cert you can use a fingerprint in order to
         *  validate a SAMLResponse, but we don't recommend to use that
         *  method on production since is exploitable by a collision attack.
         *  (openssl x509 -noout -fingerprint -in "idp.crt" to generate it,
         *   or add for example the -sha256 , -sha384 or -sha512 parameter)
         *
         *  If a fingerprint is provided, then the certFingerprintAlgorithm is required in order to
         *  let the toolkit know which algorithm was used. Possible values: sha1, sha256, sha384 or sha512
         *  'sha1' is the default value.
         *
         *  Notice that if you want to validate any SAML Message sent by the HTTP-Redirect binding, you
         *  will need to provide the whole x509cert.
         */
        // 'certFingerprint' => '',
        // 'certFingerprintAlgorithm' => 'sha1',
 
        /* In some scenarios the IdP uses different certificates for
         * signing/encryption, or is under key rollover phase and
         * more than one certificate is published on IdP metadata.
         * In order to handle that the toolkit offers that parameter.
         * (when used, 'x509cert' and 'certFingerprint' values are
         * ignored).
         */
        // 'x509certMulti' => array(
        //      'signing' => array(
        //          0 => '<cert1-string>',
        //      ),
        //      'encryption' => array(
        //          0 => '<cert2-string>',
        //      )
        // ),
    ),
),

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

Those users can be provision using data import or data synchronization

Q: How to configure SAML with Windows authentication?
A: To configure iTop single sign on with SAML and Windows authentication you have to execute the following configuration:

1. On your windows ADFS server, you have to choose the option “Integrated windows authentication” in addition to “Forms authentication”
2. On the iTop server you have to add the following configuration parameter requestedAuthnContext in the configuration section iTop SAML. For instance:

Configuration

'combodo-saml' => array (
   ...
   'security' => array (
     'wantMessagesSigned' => false,
     'wantAssertionsSigned' => true,
     'authnRequestsSigned' => true,
     'logoutRequestsSigned' => true,
     'logoutResponseSigned' => false,
     'requestedAuthnContext' =>
     array (
        0 => 'urn:federation:authentication:windows',
     ),
   ),
),

Q: What happens if I set the conf. parameter can_logoff to true?
A: It all depends on the combinaison of both can_logoff and idp parameters.

Note that the 2nd use case can be helpful if you want to log off from iTop in order to reconnect as another user, but remain connected to the SAML server for other applications.

To understand the error codes, ahve a look at the reference documentation of the SAML protocol. Here is a version in the Microsoft Documentation

OneLogin provide a series of helpful SAML online tools here.