Overview
All users in Tribal Habits must be authenticated. This means that each user must log in using unique credentials and a password. Users can log in to Tribal Habits via three methods:
Via the standard Tribal Habits login page, by entering their username or email address and a password stored in your Tribal Habits platform.
Via SAML 2.0 Single-Sign-On (SSO), which redirects the user to your SSO platform where they enter their standard SSO credentials and are then redirected back to your Tribal Habits platform as an authenticated user.
Via a custom OAuth2 authentication process, which allows users from one platform to log into a second platform. Learn more about OAuth2.
This article discusses the SAML 2.0 version of Single-Sign-On.
THIS FEATURE REQUIRES A BUSINESS PLAN
Please note that SAML 2.0 Single-Sign-On (SSO) is only available on Business plans. This feature is not available on smaller plans (such as Lite). Please contact our team at [email protected] if you would like access to this feature but it is not activated in your portal.
What is SSO?
Single-Sign-On (SSO) is an authentication process that enables users to securely authenticate with multiple platforms using just one set of credentials.
Tribal Habits utilises the SAML 2.0 standard for SSO. This is typically used by organisations that require their employees to log in to access their desktop and applications. This 'one login' approach allows employees to access Tribal Habits without needing a separate password - so once they've logged into their SSO environment at work, they are automatically logged into Tribal Habits.
For employees, SSO is a convenience - they don't need to remember a separate login and password for Tribal Habits.
For organisations, SSO is secure. It provides more control over each user's security settings, such as minimum password requirements, password changes, password resets and application access. Organisations can manage passwords and application access directly without using Tribal Habits' own settings.
Note that SAML 2.0 SSO is typically used by organisations for employees and requires your organisation to have an SSO platform to manage users, such as Microsoft Entra, OneLogin or Okta. SAML 2.0 SSO is different from an open authentication standard such as OAuth2, which can be used to allow users from one platform to log into another. Learn more about OAuth2.
How do we activate SSO in our Tribal Habits portal?
Enabling SSO in your Tribal Habits portal involves the following steps. The last step, where you configure the specific details from your SSO provider, will vary between organisations and SSO providers. We have more specific details about popular SSO providers in separate articles below.
As a Super Admin, navigate to Admin → Account → Security and toggle on "Enable SAML Single-Sign-On (SSO)" under the Authentication section.
Click the Manage button next to "Enable SAML Single-Sign-On (SSO)" to access your SSO settings with the list of required information and our SSO URLs.
Obtain the SSO details from your identity provider.
Complete the SSO configuration requirements in Tribal Habits and in your identity provider, then test your connection with some existing users.
If your IT team is familiar with your SSO processes, they can typically set up SSO in Tribal Habits in less than 15 minutes.
What Authentication settings should we configure?
Once SSO is enabled, go to Admin → Account → Security and review the Authentication section. Four settings here directly affect how SSO behaves in your portal, and all four can be changed directly by your Super Admins at any time (they no longer require a request to our Support team).
Enable SAML Single-Sign-On (SSO) - the master switch. This enables or disables SSO entirely and grants access to your settings (via the Manage button).
Enable auto-redirect for SSO login - when on, all users are sent straight to your SSO login page and never see the standard Tribal Habits login page. This is OFF by default. We recommend leaving it off unless close to 100% of your users log in via SSO. See 'Can I hide the local login credentials?' FAQ below for how to keep the SSO experience clean for most users (e.g. staff or employees) while still allowing local login for others (e.g. contractors or volunteers).
Prevent auto-provision of new users via SSO login - controls whether a new user can be created automatically the first time they log in via SSO. This is OFF by default (meaning auto-provision is allowed). We recommend switching this ON. See "Must users be set up in Tribal Habits before they can login via SSO?" below for why.
Notify SSO users if local password login occurs - when on, if a user set to Login = Internal logs in using their local Tribal Habits password rather than SSO, we email that user to let them know. This is a useful early warning if their local credentials have been compromised. We recommend setting this to ON for an additional layer of security.
What information is sent to Tribal Habits via SSO?
SSO is about user login - it is an authentication process, not a user or data sync between two platforms (which would be handled separately via a managed integration).
The SSO process works as follows:
A user attempts to access your Tribal Habits platform.
Tribal Habits redirects the user to your SSO login page.
The user logs into your SSO environment as usual and, if the user is already logged in, they are immediately redirected back to Tribal Habits without needing to log in again.
The user is redirected back to Tribal Habits as an authenticated user and is automatically logged in.
When the user is redirected back to Tribal Habits, your SSO platform sends four pieces of identifying information about each user. These four pieces of information (typically called 'claims' in the SSO process) are used to identify the user in Tribal Habits:
First name
Last name
Email address (must be unique for each user)
User name (must be unique for each user)
User name can also be email, but is still sent as a separate field
User name can also be any other unique identifier, such as a payroll or employee number
IMPORTANT! All four SSO 'claims' must exactly match a user in your Tribal Habits platform. Any difference in the spelling of a first name, last name or email address, for example, could result in an unmatched user. Differences in first name (preferred vs actual) or slight changes in spelling are the most common cause of SSO problems.
What data should we use for the 'user name' claim?
The user name field can be email, payroll number, employee number or an actual username. The key requirement is that the field is unique for each user.
Note that the user name sent as part of the claims process does not need to be the same as the user name used in your SSO login process. For example, an employee may log into your SSO environment using their email address, but you could still send an employee number as their user name field in the claims process.
The user name field is the key identifier field in Tribal Habits. It is the field we assume "never changes" and can always be used to identify a user.
Best practice: avoid using email address as the user name claim where possible. Use a stable identifier instead, such as an employee ID, payroll number, or your identity provider's own object ID (for example, the Entra ID Object ID). Email addresses can change when a person's name changes, when your organisation changes domains, or when a user has both a personal and a work email that could be confused. Any of these can break the exact match SSO relies on and lock a user out. If a stable, unique identifier already exists in your organisation's systems, use that instead.
FAQs
Must users be set up in Tribal Habits before they can login via SSO?
We recommend setting up users in Tribal Habits before they log in via SSO, rather than relying on auto-provision.
Our SAML 2.0 SSO implementation supports "auto-provisioning", where a new user is created automatically the first time they log in via SSO if they don't already exist in your portal. Users created this way only have the four basic claims sent via SSO (first name, last name, username and email) and none of your custom data fields.
This can cause problems if your organisation uses custom fields for auto-enrolment rules, or if you have a separate integration (such as a sync from Entra ID or an HR platform) that is meant to be the source of truth for user data. If SSO auto-provisions a user first, they can end up with an incomplete profile, missing enrolments, or a mismatch with the record your integration later tries to create or update (particularly around the email field, which can trigger a duplicate user error).
Best practice: switch "Prevent auto-provision of new users via SSO login" ON (Admin → Account → Security → Authentication). With this setting on, only users who already exist in Tribal Habits can log in via SSO. Any integration or HR sync process should create the user first, fully populated, so that by the time they attempt SSO login their record already matches. A user who isn't yet set up will see an error page with instructions to contact their IT department about access.
If you don't have an integration and are setting up users manually, make sure they are created in Tribal Habits before you ask them to log in via SSO.
What if we have users who are not in our SSO platform?
That's fine. Tribal Habits can support both SSO and non-SSO users in the same portal via the LOGIN field. Learn more about having SSO and external users in the one portal.
What if we already have users in Tribal Habits before we set up SSO?
That's fine. In fact, you will most likely have users in Tribal Habits (from a trial or initial set-up) before you set up SSO.
The key issue is ensuring that all existing users in Tribal Habits have their information updated to match the four claims from your SSO environment. For example:
Users created during a trial will likely have their email address in their user name field. If your SSO claim for user name is not email, you would need to edit this field to match your SSO claim.
Users created during a trial may have been set up with preferred first names. If a different first name is used in your SSO claim, this would need to be edited to match.
Are there specific support articles for different SSO platforms?
Yes! We have detailed articles to assist with set-up for these SSO providers:
Anything else we should know before setting up SSO?
It's easy to accidentally lock yourself out of your Tribal Habits portal while setting up SSO. If you enable SSO but it's not configured correctly, you won't be able to log in via your SSO process - and without access to your portal, you won't be able to access the Security page to make changes.
If this happens, don't worry. You can log in with your local Tribal Habits credentials at: https://yourorganisation.tribalhabits.com/accounts/sign_in_without_sso
What if we get stuck setting up SSO? How do we troubleshoot?
Can I hide the local login credentials?
Yes. Go to Admin → Account → Brand and enable "Hide local login fields" in the Login Page panel. Your login page will then show only your "Login with SSO" button. Users who still need local login (such as admins, contractors, or other external users) can reveal the username/password fields via a link below the button. You can customise the link's wording (for example, "Contractor Login") and add explanatory text to guide those users to the right option.
This is different from "Enable auto-redirect for SSO login" (see above), which sends everyone straight to your SSO provider and removes the Tribal Habits login page entirely. If auto-redirect is on, no one sees the login page at all - so "Hide local login fields" has no effect, since there's no page left for it to appear on. Instead, external users must be sent to a dedicated login URL, which is why reminder, enrolment and invitation emails to external users include a special link direct to that page.
If your portal has a mix of SSO and non-SSO users, we generally recommend leaving auto-redirect off and using "Hide local login fields" instead. It keeps a single login page for everyone, with SSO as the clear primary option, while still giving your external users a straightforward way in without needing a separate URL or relying on email links alone.