This article applies to:

• MailMarshal Cloud
• Spam Quarantine Management (SQM) site
• End user spam site login

Question:

• How do I configure Single Sign On for users of the SQM site?
• Can I use AD, Azure, or G Suite logins to authenticate users to the MailMarshal Cloud SQM?

Response:

MailMarshal Cloud supports SAML 2.0 SSO for the SQM site. You can use any compliant SAML source.

Procedure

For details of procedure with ADFS, Azure AD, and Google directories, see the linked documents.

• ADFS 
• Azure AD
• Google 

For other SAML 2.0 compliant providers, the general instructions are:

1. In the MailMarshal Cloud Customer Console, navigate to Security Configuration > Single Sign On > SQM Identity Providers
2. Click Provider Metadata to download an XML file containing the metadata definitions for the SPE installation. This file can be imported to the provider. Alternatively, when you add or edit a provider, the Entity ID and ACS URL display and can be copied.
   • Note that these values may be case sensitive, depending on the provider.
3. Complete configuration of SSO on the provider side.
   • Ensure that you have enabled at least one user for SSO on the provider side.
4. On the MailMarshal Cloud SQM Identity Providers page, click Add to create a new provider.
5. Enter the details given by the provider in the Identity Providers window: the Entity ID, the SSO URL, and the SSL certificate.
   • Note: The "Entity ID" information is supplied by the Identity Provider. Do not use the Entity ID copied from the MailMarshal Cloud site.
     • Providers may also refer to this value as the "SAML Issuer ID", "Federation Service identifier", or "Azure/Entra AD Identifier"
   • IMPORTANT: Take a note of the expiration date of the SSL certificate. You must create and upload a new certificate before the old one expires.
6. After saving the provider data, select the default provider using the button at the top of the list.
   • You can also select different providers for each domain (System Configuration > Domains).
7. Test SSO with the user name that is enabled on the provider side.
8. When ready to deploy SSO, enable all required groups or users for SSO on the provider side.
9. When a user is authenticated with SAML SSO for the first time, a SQM user is created and the user name/email address is added as the alias managed by this login. 

Notes:

• If the user attempts to log in with an email address is already managed as an alias by an existing SQM user, then a SQM user is not created.
• If the provider delivers additional alias information (multiple email addresses), then the additional aliases are added to the list of aliases managed by the user (unless they are already managed by another user). See the list of fields below.
• New aliases, if any, are added each time the user is authenticated via SSO.
• Aliases are not removed from SQM by the SSO process even if they are no longer listed by the provider.

Field mapping

When configuring SSO on the Provider site you might be required to enter the names of "claims" or attributes. SQM uses the following claim names (note that all names are case INsensitive, and spaces are ignored):

• FullName, Name
  • The personal name or friendly name of the user.
• User, UserName
  • The primary email address for the user, and their login username. This value is only used if the username is not provided directly by the IDP.
• FirstName, GivenName
  • Used to create Fullname if Fullname not present
• Surname, LastName
  • Used to create Fullname if Fullname not present
• Email, EmailAddress, EmailAddresses, Alias, Aliases, Emails
  • Any and all of these values will be added as alias email addresses. For example with ADFS you can map the proxyAddresses value to this claim name. 
  • Note that Azure AD does not allow multi-value claims. You cannot retrieve proxy addresses or multiple "othermails" from Azure AD through SSO. This is a documented limitation of Azure AD, not a limitation of MailMarshal Cloud. 

Trustwave MailMarshal Cloud KB article Q21040

Last Modified: February 7, 2024