SSO (Single Sign On) Configuration
The messaging Hub provides Single Sign-On (SSO) functionality for enterprise customers, allowing authorised users to access the web application via a single identity without the need for separate logins and passwords. This allows IT administrators to better manage team access and keeps information more secure.
At present, SSO is a "request only" feature, so if you'd like to have it enabled on your account, please contact support via the link at the bottom of the page and they can arrange that for you. If you already have the feature enabled, let's walk through how to get it set up:
- How to configure Single Sign On (SSO) with your Identity Provider
- How to configure the Hub to use Single Sign On (SSO)
- Frequently Asked Questions (FAQs)
Contact 2degrees to switch on SSO
The 2degrees team can turn on SSO for your account – please email business@2degrees.nz to request it.
Before you get started...
You will need to meet certain criteria before you can configure SSO:
- An identity provider that supports the SAML 2.0 standard
- We offer support for the following providers:
- Microsoft Azure AD (Active Directory)
- Okta
- We offer support for the following providers:
- Access/permissions to configure applications within your identity provider
- User credentials with admin-level access to the parent account on the Hub
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 the Hub.
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
Audience URI (SP Entity ID) | https://app.grouptext.2degrees.nz |
Single sign on URL | https://app.grouptext.2degrees.nz/login/sso |
Assertion Consumer Service URL (Reply URL) | https://api.messagemedia.com/v2/iam/sso/acs |
Claim
Claim Name | Type | Value |
Unique Iser Identifier (Name ID) | SAML | user.userprincipalname |
Additional Claim
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 |
SAML | user.userprincipalname | |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname | SAML | user.surname |
For Okta
Single sign on URL (Assertion Consumer Service URL (Reply URL)) | |
Audience URI (SP Entity ID) | https://app.grouptext.2degrees.nz |
Okta Attributes
Name | Name Format | Value |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | URI Reference | user.email |
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 (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 Hub
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, head to the menu panel on the left and click on Configuration, and then on Single Sign-on (SSO). If you can't see the Single Sign-on (SSO) option once you're in Configuration, don't sweat it... it hasn't moved. It just means that the feature isn't enabled on your account, and like we mentioned at the start of the article, our support team can easily get that sorted for you. Once that's done, you can circle back here and finish the configuration.
Note - just make sure that if you do have to touch base with support and circle back, you actually save your Identity Provider XML metadata somewhere safe because you'll need it for Step 5.
3. Configure the email domains that you want to enable for SSO:
Note - email domains can only be used once per account hierarchy (i.e. if you set an email domain at a sub-account level, you cannot set the same email domain on another sub-account).
4. Use the dropdown arrow to select your Identity Provider (IdP) - either Azure AD or Okta:
Note - if your IdP is not listed, please contact support via the link at the bottom of the page to discuss extending SSO support to your IdP.
5. Enter the XML provided by your IdP in the field provided:
Once you have configured SAML SSO, follow these last few steps to complete the configuration:
6. 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.
7. Use the dropdown arrow to set the default user role to be assigned to these newly created profiles.
8. Select the accounts & 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 Hub using SSO only.
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.
If you have further questions, please contact business@2degrees.nz