Introduction to Single Sign-On

MXO supports single sign-on (SSO) to your environment (tenancy) using the SAML 2.0 standard. This means the list of authorized users is controlled centrally using your corporate login details or a third party SAML 2.0 Identity Provider (IdP).

If SSO is being used, the user list is managed using the IdP not MXO 's Admin Settings. This means that the Add User and Delete User functions are not available. System Administrators retain access to the Reset Account and Reset Password functions.

When a user logs in to MXO for the first time through SSO, a user record is created for them and they are assigned the roles and groups defined in Single Sign-On Defaults on the Security page. System Administrators can modify this as they would when not using SSO. The next time the user logs in to MXO through SSO, their user record is updated with any changes to their email or name fields sent from the IdP.

When your tenancy is converted to use SSO it is highly likely that users will already be set up in your system. After conversion of the tenancy, users will only be able to authenticate using your chosen IdP and will not be able to login to MXO directly, using their old credentials (System Administrators can still login directly using their old credentials). When a user first logs in through this route the system will attempt to match the information provided by the IdP to that held in MXO . This match is based on email address, so it is important that a System Administrator ensures the email addresses configured in MXO correspond to those held for users on the corporate or third party IdP being used, prior to activation of the SSO functionality. Where multiple users have been configured within your tenancy with the same email address, login via SSO will fail. To resolve this issue a System Administrator must ensure that email addresses are unique. In this scenario the role and group of existing users will not be modified by the SSO login process.

Supported Configurations

SSO to MXO is supported using the SAML 2.0 standard with a third party IdP of your choice. There are several technical requirements that your chosen IdP must support if you want to use it with MXO , including being able to provide certain data as attributes in the response it sends to MXO (the SAML Assertion):

  • The IdP must provide the name of the user being authenticated to the Service Provider (SP), in this case MXO .There are a number of different formats defined by the SAML 2.0 standard for the SAML assertion NameID.The preferred format for this value is 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'.
    Note: The only prohibited format is 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
    Information on formats can be found in Section 8.3 of the SAML assertions and protocols specification. The value must be unique to each user it defines, and will not change between subsequent logins.
  • The IdP must be able to provide the user's email address as a SAML attribute.The name of this attribute can be chosen by you, but you will need to know this value later when SSO is enabled.
  • The IdP should be able to provide the user's first and last name as SAML attributes.This is optional, but will improve the user experience by allowing the user's real name to be displayed in relevant areas of MXO .If these details cannot be provided by your chosen IdP, that IdP is still compatible with MXO . You will, however, need to enter user names manually using MXO 's Admin Settings if you want them to be displayed in MXO . For this reason we recommend configuring this information to be supplied by the IdP on login. If this information is to be provided by your IdP, the names of the attributes used to hold this information will be needed later when enabling SSO.
The SAML 2.0 standard supports multiple profiles. The current implementation of MXO 's SSO supports "Web Browser SSO Profile with POST binding".
Note: Only users with the System Administrator role can configure an SSO enabled tenancy.
## Enable SSO for Your Tenancy

Enabling SSO for your tenancy is a 4-stage process, as follows:

  1. Step 1 - Configure your IdP Information
  2. Step 2 - Test that the SSO Tenancy works as a System Administrator
  3. Step 3 - Set the SSO Defaults
  4. Step 4 - Activate SSO for All Users of your Tenancy

Deactivate the SSO Tenancy

To switch the authentication type for your tenancy back to AD, you must be logged in using your AD credentials.

Note that you may need to reset the password or reset the account for some of your users. If a user hasn't set up security credentials in MXO , reset password will give an error. In this case you will need to reset the account so that the user can complete registration.