Set up SAML single sign-on

Single sign-on (SSO) lets your admins and managers reach CultureMonkey through your own identity provider (Okta, Microsoft Entra ID / Azure AD, Google Workspace, OneLogin, and any other provider that speaks SAML 2.0) instead of a separate CultureMonkey password. Sign in once with your corporate identity, and you're handed straight into CultureMonkey. This guide walks an account admin through the whole connection: the details you give your identity provider, the details you give CultureMonkey back, how email matching works, and how to test and roll it out safely.

What SAML SSO does (and who it's for)

SAML is the open standard that lets two systems agree on who a user is without sharing passwords. In a CultureMonkey connection there are two parties:

• Your identity provider (IdP) - Okta, Entra ID, Google Workspace, OneLogin, and similar. This is the system that already knows your employees and authenticates them.
• CultureMonkey, the service provider (SP) - the application your people want to reach.

When SSO is on, an admin who visits your sign-in page is sent to your IdP to authenticate. Your IdP confirms who they are and posts a signed SAML assertion back to CultureMonkey, which reads the person's email from it and signs them in. No CultureMonkey password is ever created or checked.

Before you begin

You'll need a few things lined up on both sides of the connection:

• Account admin access in CultureMonkey. Setting up SSO is an account-level change, so it's an admin task, not a manager one. See Invite and manage administrators if you need to confirm who holds that role.
• Admin rights in your identity provider, or a colleague on your IT team who has them, so you can register a new SAML application.
• Your CultureMonkey subdomain - the yourcompany part of yourcompany.culturemonkey.io. Every SP value below is built from it.
• Matching email addresses. The email your IdP sends must match the email on each person's CultureMonkey admin or manager record, because that email is how CultureMonkey identifies them. More on this under Email and NameID mapping.

The CultureMonkey service-provider details

To register CultureMonkey inside your identity provider, your IdP needs to know where to send users and how to identify the application. These are CultureMonkey's SP details, and every one of them is derived from your subdomain.

Replace yourcompany with your actual subdomain in both URLs. The ACS URL is the single endpoint your IdP posts the signed assertion to after a user authenticates. The entity ID is the unique identifier CultureMonkey presents as its audience, so your IdP knows the assertion is meant for CultureMonkey and no one else.

CultureMonkey also publishes its own SP metadata at https://yourcompany.culturemonkey.io/sso/saml2/metadata. Some identity providers let you import an SP by URL rather than typing fields one at a time - if yours does, point it at that address and it will read the ACS URL, entity ID, and NameID format automatically.

Configuring your identity provider

The exact screens differ between Okta, Entra ID, Google Workspace, and OneLogin, but the shape of the task is the same everywhere. Create a new SAML application and feed it the SP details above.

1. 1Create a new SAML 2.0 application - in your IdP's admin console, add a new app integration and choose SAML 2.0 (not OIDC or SWA). Give it a recognizable name like "CultureMonkey".
2. 2Enter the ACS URL - paste https://yourcompany.culturemonkey.io/sso/saml2/acs into the field your provider labels Single sign-on URL, ACS URL, or Reply URL. Set the binding to HTTP-POST if asked.
3. 3Enter the entity ID - paste https://yourcompany.culturemonkey.io/sso/saml2/metadata into the Audience URI, SP Entity ID, or Identifier field.
4. 4Set the NameID to email - configure the SAML subject / NameID to send the user's work email, with the format EmailAddress. This is the value CultureMonkey uses to find the account, so it has to be the email.
5. 5Assign your users and groups - grant the CultureMonkey app to the people (or groups) who should have admin or manager access. Only assigned users will be able to sign in through SSO.
6. 6Copy your IdP metadata URL - your provider exposes a metadata URL (sometimes called App Federation Metadata URL or Identity Provider metadata). Copy it - you'll hand it to CultureMonkey next.

app.culturemonkey.io/integrations

The IdP metadata and certificate you provide

Once your SAML application exists, your identity provider generates the details CultureMonkey needs to trust assertions coming from you: the IdP's sign-in URL and its signing certificate. Rather than copying these one field at a time, CultureMonkey reads them from your provider's metadata URL.

That single URL is the only thing you need to hand over. When SSO runs, CultureMonkey fetches your metadata from it and pulls out:

• your IdP's single sign-on URL (where users are sent to authenticate),
• your IdP's entity ID, and
• the X.509 signing certificate used to verify that each assertion genuinely came from your IdP and wasn't tampered with.

Because CultureMonkey reads the certificate live from your metadata URL, a routine certificate rotation on your side is usually picked up automatically, as long as the URL keeps serving the current certificate. That's why the metadata URL is preferred over a one-time file upload.

1. 1Locate your metadata URL in the IdP - in Okta it's the Identity Provider metadata link; in Entra ID it's the App Federation Metadata Url; other providers use similar wording. It should be a public https URL ending in something like .xml.
2. 2Send it to CultureMonkey - share the metadata URL and your subdomain with your Customer Success contact or through support.
3. 3CultureMonkey stores it and enables SSO - the team saves your metadata URL against your account and switches SSO on. From that moment the SSO button can appear on your login page.

Email and NameID mapping

This is the single most important detail to get right, so it's worth stating plainly: CultureMonkey identifies a person by the email in the SAML NameID.

When your IdP posts an assertion, CultureMonkey reads the NameID, lowercases it, and looks for an admin or manager whose email matches. If it finds one, that person is signed in. If it doesn't, they're sent back to the sign-in screen. The match is case-insensitive, so Jane.Doe@company.com and jane.doe@company.com are treated as the same person, but the address itself has to line up exactly on both sides.

A few consequences worth planning for:

• The person must already exist in CultureMonkey. SSO authenticates people; it doesn't create them. Before someone can sign in through SSO, an account admin has to have invited them as an admin or manager. See Invite and manage administrators.
• The IdP email and the CultureMonkey email must be the same address. If your IdP sends j.doe@company.com but CultureMonkey has jane.doe@company.com, the login won't match. Align the addresses, usually by making the IdP send the same primary work email you used to invite the person.
• NameID must be the email, not a username or an opaque ID. Some IdPs default the NameID to a persistent identifier or a UPN that isn't an email. Set it explicitly to the email address format.

Optional: password-protected assertions

Some security teams want CultureMonkey to explicitly request a password-protected authentication from the IdP. CultureMonkey supports adding the standard PasswordProtectedTransport authentication-context class to its SAML requests, which asks your IdP to authenticate the user with (at least) a password over a protected transport. This is an optional hardening step CultureMonkey can turn on for your account if your policy calls for it.

Testing your connection

Never enforce SSO before you've confirmed a real sign-in works. Test with an account you can also reach another way, so you're never locked out.

1. 1Open your sign-in page - go to https://yourcompany.culturemonkey.io/signin. With SSO enabled, you should see a Sign-in with {your company} SSO button beneath (or instead of) the password fields.
2. 2Select the SSO button - you'll be handed off to your identity provider's login.
3. 3Authenticate at your IdP - sign in as a user who is both assigned the CultureMonkey app in your IdP and invited as an admin or manager in CultureMonkey.
4. 4Confirm you land inside CultureMonkey - a successful sign-in drops you on your reports or dashboard. If you're bounced back to the sign-in screen instead, the email likely didn't match - see the troubleshooting notes below.

If the handoff works for a test user, it will work for everyone who is both assigned in your IdP and present in CultureMonkey.

Enforcing and streamlining SSO

Once you've confirmed SSO works, you can decide how prominent it should be on your login page. CultureMonkey gives you two behaviors:

• Button alongside password - by default, the Sign-in with {your company} SSO button appears above the normal email/password form, separated by an "OR". People can choose either path.
• Automatic redirect - CultureMonkey can instead redirect admins straight to your identity provider after a short countdown, so the SSO button is effectively the only door. This is the closest thing to "enforced" SSO and is the usual choice once you're confident in the connection. The countdown length is configurable.

Once enforced, your invitation emails also adapt: when SSO is enabled, the invite link CultureMonkey sends new managers points them at the SSO sign-in flow rather than a password-setup page, so their very first experience is the one you've standardized on.

Troubleshooting

Most SSO problems trace back to a mismatch between the two sides of the connection. Match the symptom to the likely cause below.

If none of these fit, see Logging in to CultureMonkey for the wider set of sign-in issues, or reach out through Getting help & contacting support.

Frequently asked questions

Do I upload a certificate file, or provide a URL?

You provide a metadata URL. CultureMonkey reads your IdP's sign-in URL and signing certificate from that URL, so there's no separate certificate file to upload and re-upload when it rotates - as long as the same URL keeps serving your current metadata.

Which identity providers are supported?

Any provider that speaks SAML 2.0, which includes Okta, Microsoft Entra ID / Azure AD, Google Workspace, and OneLogin. The setup shape is the same for all of them: register CultureMonkey as a SAML app, map email to NameID, and share your metadata URL.

Does SSO apply to survey participants?

No. SSO covers admins, sub-admins, and managers who log in. Survey participants answer through a personal link (and an optional one-time passcode) and never see the SSO login. See Logging in to CultureMonkey.

What happens to existing passwords when we turn on SSO?

Admins who sign in through SSO no longer need a CultureMonkey password. When a first SSO sign-in happens for someone who was invited but never set a password, CultureMonkey verifies their account automatically. If you enforce SSO with auto-redirect, the password form is effectively bypassed.

Can someone still use email and password after SSO is on?

By default, yes - the SSO button appears alongside the email/password form. If you ask CultureMonkey to enable auto-redirect, admins are sent straight to your IdP instead, which is how most organizations effectively require SSO. Keep a recovery path for admins before enforcing it.

Why does one user get bounced back after logging in at our IdP?

Almost always an email mismatch. CultureMonkey matches the SAML NameID email to an invited admin or manager. If that person isn't invited in CultureMonkey, or the IdP sends a different address, the sign-in won't complete. Align the emails and confirm the person is invited.

Where to go next

• See every way people sign in: Logging in to CultureMonkey
• Make sure the right people have admin access first: Invite and manage administrators
• Need a hand enabling SSO on your account? Getting help & contacting support