SSO (Single Sign-On) Configuration

This article explains what SSO (Single sign-on) is, how it works and what configuration is needed to get it setup on your account.   

Single Sign-on (SSO) is an authentication method that allows users to log in to multiple applications or services with a single set of credentials. Instead of signing in separately to different platforms, SSO streamlines access by authenticating the user once and granting access across all connected systems. 

How SSO Works 

User logs in once – The user enters their credentials on an identity provider (IdP) platform.  
Authentication token issued – The IdP verifies the credentials and generates a secure authentication token.
Access granted – The token is shared with connected applications, allowing the user to access them without logging in again. 

Benefits of SSO 

Convenience – Users don’t need to remember multiple passwords. 

Security – Reduces the risk of phishing and password reuse. 

Efficiency – Speeds up login times and minimizes IT support requests for password resets. 

Pre-configuration information

At present, SSO is a request-only feature, so if you would like to have it enabled on your account, please submit a request with our support team using the contact details at the bottom of this page. If you already have the feature enabled, let's walk through how to get it set up. You need to meet certain criteria before you can proceed to configure SSO:

1. An identity provider that supports the SAML 2.0 standard. We offer support for the following providers: Microsoft Azure AD (Active Directory)
   Okta

2. User permissions that allow you to configure applications within your identity provider.

3. Administrator user credentials for the parent account.

Validating SSO Domain Verification

When setting up Single Sign-On (SSO), you’ll need to prove that you own the domain by adding a DNS TXT record. This is a common security practice across the industry.

Steps to validate your domain

1. Get your TXT record details - In the SSO configuration screen, you’ll see the TXT record value generated for your domain.
2. Add the TXT record to your DNS
   - Log in to your domain provider’s DNS settings.
   - Add a TXT record with the details provided.
3. Wait for DNS to update - DNS changes may take a few minutes to propagate.
4. Save your SSO configuration
   - Go back to the SSO setup page and click Save.
   - If the TXT record is not yet in place, the system will prevent you from saving and show clear guidance on what to fix.

_sso_domain_verify.dub.ams.stg.mmd.zone. 60 IN TXT "559d63e31092f630ecc07ef84b58a643b64dfd7d0612fc3125ab1c825deb53cd" "4c54ce3fe8553f75282c75f6be30d8d087c4dc82f6cd038d56fb8a3ec6415096"

Step 1 | Configuring your SSO Identity Provider

We use SAML 2.0 (Security Assertion Markup Language), a standard that permits Identity Providers (IdP) to safely pass authorisation credentials, such as your username and password, to service providers like multiTXT.

1. The first step is to create a new SAML application with your IdP:

• For Microsoft Azure AD, follow this guide
• For Okta, follow this guide

2. Configure the application using the following settings:

For Microsoft Azure AD 

• Claim

• Additional Claim

For Okta

• Okta Attributes

3. Configure a logo (Optional) 
4. Assign users or groups to the application
5. Copy or download the IdP XML metadata - you will need this for Step 5 of Configuring the multiTXT platform.

Step 2 | Configuring the multiTXT platform

1. Log into the parent account - remember, you will need admin-level user credentials to proceed from here.

2. Once you're logged in, navigate to Settings > Account > Security

   

3. Configure the email domains that you want to enable for SSO - email domains can only be used once per account hierarchy so if you set an email domain at a sub-account level, you can't set the same email domain on another sub-account. To save the entered information simply press Enter on your keyboard or click anywhere outside of the field. 
4. Use the dropdown arrow to select your Identity Provider (IdP) - either Okta or Azure AD. If your IdP is not listed, you can contact our support team to chat more about extending SSO support to your IdP.

5. Enter the XML provided by your IdP in the field provided.

   

6. When someone logs into the multiTXT platform using SSO but they don't already have a user profile, you can allow the multiTXT platform to automatically create a new user with the credentials provided by the IdP. Just toggle this switch to On to enable.
7. Use the dropdown arrow to set the default user role to be assigned to these newly created profiles.
8. Select the accounts and sub accounts you want to allow these new users to have access to.
9. Toggling this switch to On means that any users logging in with credentials matching your nominated email domains will be forced to log into the multiTXT platform using SSO only.
   

10. You can choose to enforce SAML authentication by toggling it on and off - this will apply to all users.

    

FAQs

• My organization uses an identity service provider (IdP) that's not in the list. Will it be supported?
  Please contact the support team via the link at the bottom of the page with the details of which identity provider you would like to use.
• Do you support on-premises Microsoft Active Directory?
  No, we only support Azure Active Directory.
• Do you support IdP initiated SSO?
  Unfortunately not at this stage. Users will need to re-enter their email address in the Log in with Single Sign On page.
• Does enforcing SAML SSO log out users?
  No, active user sessions stay logged in until they expire. The next time a user needs to log in, they will need to log in with SAML SSO.
• What version of SAML does the multiTXT platform support?
  We currently support SAML v2.0.
• Can I still log into the multiTXT platform if my identity provider is experiencing an outage?
  If you have Enforce SAML authentication turned on and your IDP is down, you should contact the support team and we can turn off “Enforce SAML” to allow administrators and users that existed beforehand to login with email again.
• Why am I receiving the error "SSO auth failed"?
  There are several reasons you may see this error message, you will find the two most common examples below, however if neither of these apply please contact our support team.
   a. It is most likely due to a disparity in your relative Active Directory (AD), where the records may be misaligned, in which case you would need to check with your AD admin to ensure the right details are there.
   b. Sometimes when a user logs in with Single Sign-On (SSO), they start by entering their email. After going through the login steps, the system confirms their identity and sends back their details, including their verified email. Sometimes, the returned email is different from the one they entered. This usually happens because the system was set up to pull the wrong email field. Many platforms store multiple email-like fields (e.g. yourorganisation.com vs. on.yourorganisation.com). If the wrong one is being used, the admin can simply update the settings to select the correct field.

If you have further questions, please email us at support@help.multitxt.co.nz