SSO comes as a standard feature and takes the hassle out of having to remember different credentials for multiple applications and eliminates the need to individually log into each one every time you need to use it. MEX handles this in the back end allowing users to open up and instantly use all MEX applications with their credentials automatically activated.
How Single Sign On Works With MEX Applications
All MEX applications are compatible with the MEX SSO, including mobile applications.
MEX SSO allows customers to specify an Identity Provider (such as Azure AD also known as Microsoft Entra) that MEX 15 can authenticate against, utilizing the SAML 2.0 protocol. This means that once a user has logged into the Identity Provider they will not need to enter any credentials again and MEX will know who they are. Upon opening the MEX application, MEX will cross check their credentials within the MEX Database and if that user exists, grant them access. In the case where the user does not exist, there is the SSO setting to automatically create a new user account with a default security group nominated.
Here is a flow chart illustrating this process:
Setting Up Azure SSO – Creating the Enterprise App
If your hosted MEX URL address is for example: 'https://SimpleSolutions.mex.com.au/' the name would be 'SimpleSolutions'. For the last 3 steps above, replace the text 'YourWebsiteName' with your website name with: 'SimpleSolutions'.
5. Click the top 'Save' button to save the changes.
Back on the 'Set up Single Sign-On with SAML' page, scroll down to section 3 'SAML Certificate'.
Click the 'Download' button next to 'Certificate (Base64)'.
This will download a certificate file
This will need to be emailed to MEX, however as the MEX email provider blocks '.cer' files, first rename the file from e.g. 'MEX SSO.cer' to 'MEX SSO.txt'. By renaming the file to the '.txt' extension this will no longer be blocked.
Email 'cloud.admin@mex.com.au', attach the certificate file e.g. 'MEX SSO.txt' and on the email note your MEX hosted website address e.g. 'https://SimpleSolutions.mex.com.au/'.
MEX will get back to you to confirm that the certificate has been setup, then proceed with the next steps.
Setting Up Azure SSO – Enabling SAML in Mex
The next step is to configure the MEX SAML settings.
Make sure to keep the Microsoft Entra page open, you will later need to access this.
Open a new browser tab and enter the MEX URL followed by ‘/SAML’, for example: https://SimpleSolutions.mex.com.au/SAML/. The page should ask to login with a MEX account, once you have logged in you will see the following page:
Enable 'Use Single Sign-On?'.
You will need to copy URL addresses from the Microsoft Entra page. Under section 4 'Set up MEX SSO'.
Copy 'Login URL', then on the MEX SAML page paste that into 'Issuer'.
Copy 'Microsoft Entra Identifier', then on the MEX SAML page paste that into 'Provider Trust'.
Copy 'Logout URL', then on the MEX SAML page paste that into 'Logout URL'.
Previously on the 'Basic SAML Configuration' step above the 'Identifier (Entity ID)' was set:
Copy and paste that into the MEX SAML page 'Reply Address'.
Untick 'Sign Logout Request?'
The MEX SAML page should now look similar to:
The 'User Type' and 'Security Group' refer to default for new accounts that are created by MEX SSO. Please note these settings only apply if it the first time a user is logging into MEX.
For most cases, set the 'User Type' to 'MEX'. To explain the options:
'None', MEX SSO accounts will not automatically be created. This requires a MEX administrator to create the account before the person can login to MEX.
If you do not want MEX SSO to automatically create accounts, a better way to manage this is the section below 'Setting Up Azure SSO – Setting User Access'. you should set 'User Assignment Required' to 'Yes' and manually define the users and groups which are set to have access.
'MEX', MEX SSO account will be automatically created and give access to login.
'Ops', MEX SSO account will be automatically created and restrict login to the '/Ops' page. Please note this requires 'MEX Ops' licensing.
Set the 'Security Group' to your preferred Security Group.
To explain Security Groups, in MEX
'User Type': This drop-down is used to define what will happen when a user that is not already recorded as a MEX User access the application. The following options are available:
None: The user will be denied access to the MEX application if they do not have an existing MEX account.
MEX: The user will automatically be added to MEX as both a MEX and a MEX Ops user.
MEX Ops: The user will be automatically added to MEX as a MEX Ops user only.
'Security Group': If the User Type 'MEX' has been selected, then any new users created in MEX by SSO will be automatically assigned to the Security Group selected here. If Security Group is set to 'None' any new user will be added as an administrative-level user.
Before clicking the 'Apply' button to save the changes, please read the below sections.
If you only want to save the details and do not want to enable SSO, untick 'Use Single Sign-On?' then click the 'Apply' button. This way you can enable SSO later without having to re-enter the information.
If you run into any issues with SSO, you can always visit the MEX URL followed by ‘/SAML’ to turn SSO off or on.
Setting Up Azure SSO – Setting User Access
The last action to complete is setting up Azure user’s access to MEX SSO. The options are either to allow all users access, or define which users and groups can access MEX SSO.
By default User assignment required is set to Yes. You will either need to define the users or groups to be allowed access or allow all users.
To allow individual users:
Alternatively, if you are required to apply access to SSO functionality per each user, we can ignore the steps above and leave the ‘User Assignment Required?’ field remaining on Yes. Instead we can apply each user’s level of access from the ‘Users and groups’ module.
Navigate to ‘Users and groups’ module
Select ‘Add User’ button
Select to add by ‘Users and groups’
Select User on the right-hand side to allow access
Selected users will be listed here
Click the select button to save them with access to use SSO
To allow all users:
Navigate to the properties of the MEX SSO Enterprise app
Change the option for ‘User Assignment Required’ to No
FAQ
What if SSO is being setup after there are already existing MEX user accounts?
IMPORTANT - Existing MEX user accounts must have the username field replaced with the persons company email before enabling SSO. Otherwise if the user logs into MEX with the SAML option 'User Type' set to 'MEX' a second account will be created under their company email.
This can lead to confusion and duplicate accounts as MEX is unable to link existing accounts unless the existing accounts username field is replaced with the persons company email that they will login with.
For example:
Open 'Control Files', then click on 'Security Users'. See the 'Username' column.
In this example you will see Liam Brown has the username 'liam.brown@mex.com.au' which is the persons company email. However Barry Reynolds has the username 'breynolds' which would not be the persons company email. Barry Reynolds would need to have their account's username changed, this can be done by double clicking their name in the listing.
This will open the 'Contact Details' page. Click on the 'MEX User' tab, then see the 'Login Name' field, please note this is the 'Username' field.
Change the persons 'Login Name' to their company email, for example:
Return to the Security Users Listing and repeat steps 4-5 for the remaining users.
If there are hundred(s) of users that would need to have this change and you would need assistance, contact the support team - support@mex.com.au.
What if external users who are not part of the organization’s directory have accounts created to access MEX?
When SSO is enabled on the application, access is restricted to users within the organization's identity provider. As a result, third-party contractors or external users who are not part of the organization’s directory will not be able to log in or access the application unless explicitly provisioned through the identity provider.
The best practice is that third-party contractors should not have accounts created in MEX and instead the MEX administrator should manage any changes that the contractor would have done instead of providing the contractor access to the MEX system.
It is recommended that a MEX administrator conducts a periodic review of the contractor accounts to ensure that the contractor is still active and that they have a valid reason to access MEX. If an account is not in use, the account should be marked as 'Inactive' to prevent access. If you would like assistance with this process, contact the support team - support@mex.com.au.
After logging into MEX with SSO the account email, name or other fields did not pass the correct information?
In some cases users primary identifier or other fields may not match the data that you are expecting to be sent to MEX. You can review this after logging into MEX with SSO, check your users username and other fields to make sure the correct data is being sent. If that does not match what you expect the following can be done:
Visit the Enterprise Application, Single Sign-On page.
Under section 2 'Attributes & Claims' click the top-right 'Edit' button.
Here you will see that identifiers are used to link data in your organizations identity provider with values that are sent to MEX application.
In the case that the MEX username does not match, this is the 'Unique User Identifier (Name ID)'. click on this claim.
To change which field is sent, click on the Source attribute value. Then change this to the relevant field.
If you are not sure which field to change this to:
On the top navigation bar search 'Users'. Then on the Users page, search a user and open that user. Once you are on the users page, click the top 'Edit properties' button.
By default the primary identifier is the 'User principal name'. In some cases this may not be what you want to use. For example some companies use the email field instead to identify users.
Click on the 'Contact Information' tab. Check if there is an alternative field to use instead of the User principal name. In this example you will see the the email is different from the User principal name.
Then back on the 'Manage claim' page, you would set the 'Source attribute' value to 'User.PrimaryAuthoritativeEmail'. Then click the top 'Save' button.
Our company uses System for Cross-domain Identity Management (SCIM), is this supported to automatically set a MEX Security Group?