Step 1 - Configure your IdP Information

Step 1 - Download the SP Metadata

By default, SAML 2.0 Single Sign-On is not configured. The only login option for all users is direct login. System Administrators can download the SP metadata to configure the IdP and gather the information required to update the SSO configuration for their tenancy.

Navigate to the SAML SSO page in Admin Settings.
Locate the Service Provider Metadata section in SAML 2.0 Single Sign-On Configuration.
Click Download Service Provider Metadata.
Example SP Metadata File

Step 2 - Configure your Third Party IdP to add MXO as a New SP

For this step, you will need the SP metadata you downloaded in Step 1.

Note:

You must ensure you include the Recipient value as part of your configuration, as MXO will not process SAML responses without it.

Depending on the IdP you have chosen, the configuration methods will vary and will either use the metadata directly or require you to manually enter various configuration options, the values of which can be derived from the metadata provided. Your chosen third party IdP should be able to provide assistance on how to configure a new SP within their product.

As part of the SP configuration being defined on your chosen IdP you will need to ensure that additional attributes will be included in the SAML assertions generated to send the required email address, as well as the optional first name, last name, roles, and groups data.

Roles and groups can be sent as:

a list of attribute values

<Attribute Name="http://schemas.xmlsoap.org/claims/Group">
<AttributeValue>Group 1</AttributeValue>
<AttributeValue>Group 2</AttributeValue>
</Attribute>

a comma-separated list

<Attribute Name="http://schemas.xmlsoap.org/claims/Group">
<AttributeValue>Group 1, Group 2</AttributeValue>
</Attribute>

Where the group attribute values should correspond to the group names defined on the Groups page in ONE, and the role attribute values are taken from the list of role IDs below:


Field	Description
1	System Administrator
2	ONE User

If no role and group attributes are configured, the default roles and groups will be used.

You can also configure the first part of a user's auto-provisioned userId (that is '@your-org') to come from the value of the NameID sent in the SAML assertion, or the value of another attribute. URL unsafe characters will be replaced, and if none of these optional configurations are provided, the mandatory email address will be used by default to derive the userId. The userId can't be updated when a user is provisioned.

Example IdP Configuration File

Step 3 - Generate the IdP Metadata

When MXO has been added as an SP to the IdP you will need to generate the IdP metadata.

Again, the specifics of obtaining this will vary with different IdPs but most will simply provide a download link from within the configuration pages.

Step 4 - Upload the IdP Metadata to MXO

After generating your IdP metadata, you must upload that metadata to ONE.

Navigate to the SAML SSO page in Admin Settings.
Locate the Identity Provider Information section in SAML 2.0 Single Sign-On Configuration.
Click Choose File and navigate to the file you want to upload.
Enter the attribute names for email, forename (first name), surname (last name), roles, and groups.
Optionally, configure any userId prefix settings.Forename, surname, roles, groups, and userId prefix attribute names are not mandatory.
Click Apply.The status of the SAML 2.0 Single Sign-On Configuration changes to Configured.

Your tenancy now has an SSO configuration saved, and the SSO identifier has been generated so that a System Administrator can test the SSO login. All other users will still login directly. Auto creation of users through the SSO login process is not yet available.

You can use Delete to clear the saved SSO configuration and remove the SSO identifier. The status will return to Not Configured. A new SSO identifier will be generated when you save a new SSO configuration.

Note: You can save only one SSO configuration per tenancy, so we recommend that only one System Administrator modifies these settings at a time. This is to ensure that the configuration that is tested is the one that gets activated.

Notes about Groups and Roles

Unrecognized groups will be provisioned.
Groups aren't tied together beyond the name, so a group rename will be treated like a new group.
Groups aren't deleted automatically.
If no groups are received, but a group attribute is configured, the groups will be removed from the user.
Invalid role IDs will lead to an error.
If no roles are received, we won't update them (at least one role is compulsory).