This article explains what SSO (Single sign-on) is, how it works and what configuration is needed to get it setup on your Sinch MessageMedia 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.
Important SSO (Single sign-on) 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. 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:
a. Microsoft Azure AD (Active Directory)
b. Okta
2. User permissions that allow you to configure applications within your identity provider.
3. Administrator user credentials for the Hub parent account.
Step 1 | Configuring your SSO Identity Provider
Important - This setup guide is intended for IT system administrators. While we can help you set up SSO to work with our platform, we can't provide support for the configuration of your SAML identity provider. To ensure security and compatibility, for now our system only supports well-known Identity Providers (IdPs) such as Microsoft Entra ID (Azure AD) and Okta. Unfortunately, we do not support custom domains or self-hosted IdPs for SSO setup at this time. We’ve also noticed that some customers attempt to configure one-tap SSO login (such as Okta ISPM SSO app) with Sinch MessageMedia. At this time, we do not support this feature. To access your account via SSO, you must log in through the Sinch MessageMedia web portal SSO login page. |
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 the Hub.
1. The first step is to create a new SAML application with your IdP:
- For Microsoft Azure AD, navigate to the Microsoft Entra Gallery and select Create your own application, then follow this guide
- For Okta, follow this guide
2. Configure the application using the following settings:
● For Microsoft Azure AD
MICROSOFT AZURE AD | |
Audience URI (SP Entity ID) | https://hub.messagemedia.com |
Single Sign-On URL | https://hub.messagemedia.com/login/sso |
Assertion Consumer Service URL (Reply URL) | https://api.messagemedia.com/v2/iam/sso/acs |
MICROSOFT AZURE AD | Claim | ||
NAME | TYPE | VALUE |
Unique Iser Identifier (Name ID) | SAML | user.userprincipalname |
MICROSOFT AZURE AD | Additional Claim | ||
NAME | TYPE | VALUE |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | SAML | user.mail |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname | SAML | user.givenname |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name | SAML | user.userprincipalname |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname | SAML | user.surname |
● For Okta
OKTA | |
Audience URI (SP Entity ID) | https://hub.messagemedia.com |
Single Sign-On URL (Assertion Consumer Service URL (Reply URL)) | https://api.messagemedia.com/v2/iam/sso/acs |
OKTA | Attributes | ||
NAME | NAME FORMAT | VALUE |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | URI Reference | user.email |
http://schemas.microsoft.com/claims/authnmethodsreferences | URI Reference | session.amr |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname | URI Reference | user.firstName |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname | URI Reference | user.lastName |
3. Configure a logo - this is optional.
4. Assign users or groups to the application.
5. Copy or download the IdP XML metadata - put this somewhere safe as you'll need this for Step 5 of Configuring the Hub.
Step 2 | Configuring the Hub
1. Log into the parent account in the Hub - remember, your user credentials will need admin-level access to proceed from here!
2. Once you're logged into the Hub, go to the menu and click on Settings, then select Account:
Note - if you can't see the Single Sign-on (SSO) option it just means that the feature isn't enabled on your account. You can contact support to request for it to be enabled. |
3. Select the Security tab.
4. 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.
5. Use the dropdown arrow to select your Identity Provider (IdP) - either Okta or Azure AD. If your IdP is not listed, you can contact support to chat more about extending SSO support to your IdP.
6. Enter the XML provided by your IdP in the field provided.
7. When someone logs into the Hub using SSO but they don't already have a user profile, you can allow the Hub to automatically create a new user with the credentials provided by the IdP. Just toggle this switch to On to enable.
8. Use the dropdown arrow to set the default user role to be assigned to these newly created profiles.
9. Select the accounts & sub-accounts you want to allow these new users to have access to.
10. 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 Hub using SSO only.
Note on 2FA (Two-Factor Authentication) When SSO is enforced, the user cannot log in using a password, so 2FA is not triggered. |
FAQs
-
My organization uses an identity service provider (IdP) that's not in the list. Will it be supported?
Please contact the support team 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 Login 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 Hub support?
We currently support SAML v2.0. -
Can I still log into the Hub 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 support.
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 still need help please reach out to our support team and we will be happy to help.
Comments
0 comments
Article is closed for comments.