Single Sign-On

Enterprise SSO lets your team, and optionally your partners, sign in to Journeybee through your own identity provider: Okta, Entra ID, Google Workspace, or any SAML or OIDC provider. Accounts are governed by your IdP, so joiners and leavers are handled where you already handle them.

This is different from the Google and Microsoft buttons on the sign-in page. Those are social sign-in, available to everybody. Enterprise SSO is a configured connection with domain claims, enforcement and role mapping.

Where to find it: Go to Settings, then Single Sign-On (under Workspace).

Who can use this: Admins only, and only when the Enterprise SSO module is enabled. The page does not appear otherwise. Contact Journeybee support to have it turned on.

The two surfaces

SSO is enabled per surface, and the two are independent:

App: your own team signs in to Journeybee through your IdP.
Portal: partners sign in to your partner portal through an IdP.

Portal SSO needs a verified custom domain. Without one, portal SSO sign-ins will not work. See Custom Domains.

Both surfaces are switched on by Journeybee as part of enabling the module. The page shows you their current state.

Step 1: Register Journeybee with your IdP

The Service provider details panel holds the values your identity provider needs when you create the Journeybee application at their end:

Entity ID
ACS URL (the assertion consumer service, for SAML)
Metadata URL
OIDC Redirect URI (for OIDC providers)

There is also Download SP metadata XML, which most SAML providers will accept as an upload so you do not have to copy fields by hand.

Step 2: Create the connection

Click Add connection.

Name and provider

Give the connection a name your team will recognise, such as "Okta", then choose SAML or OIDC.

The provider type is fixed once the connection is created. To switch, delete the connection and create a new one.

Scope

Company-wide: for your own team, available to any user in your company.
Partner organisation: scoped to one specific partner, so that partner's people sign in to your portal through their own IdP.

Scope is also fixed after creation.

Provider configuration

For SAML, supply the IdP's metadata either as a Metadata URL or by pasting the metadata XML.

For OIDC, supply the Discovery URL, Client ID and Client secret.

The client ID cannot be changed after creation. You can rotate the client secret or replace the SAML metadata at any time by editing the connection; leaving those fields blank keeps what is already saved.

Step 3: Claim your domains

A connection routes users by their email domain, so you have to prove you own the domain.

Add the domain, for example acme.com.
Journeybee shows a TXT record name and value. Add it at your DNS provider.
Click Verify.

DNS takes a few minutes to propagate, so a first Verify that fails is usually just impatience. The connection row shows how many of its domains are verified.

A domain can only be verified by one organisation. If it has already been claimed elsewhere, contact Journeybee support.

Step 4: Choose the settings

Enforce SSO

For a company-wide connection, enforcement requires SSO for every active member of your internal team, whatever their email domain. Domains are used only to route people to the right connection. For a partner-scoped connection, enforcement applies only to that partnership’s portal sign-in.

Once enforced, other sign-in methods, including password, magic link and the Google and Microsoft buttons, stop working for the people covered. There is no admin password fallback, so before enabling make sure everyone affected, including you, exists in your identity provider. If an identity provider outage locks you out, contact Journeybee support, who can disable enforcement after verifying the request.

Just-in-time provisioning

Creates the account automatically the first time someone signs in through the connection. With Just-in-time provisioning off, only existing team members and existing partner contacts can sign in; anyone else has to be invited first.

Portal provisioning

When just-in-time provisioning is on for a connection that serves the portal, you choose how new partner contacts may be created:

Approved partnership domains: a new contact is created only when their email domain is an approved domain on one of your active partnerships. Available on company-wide connections.
Trusted IdP mapping: you set the IdP claim name and map each Claim value to one active partnership, so your identity provider states exactly which partnership each person belongs to. Each mapping needs a unique claim value. Available on company-wide connections.

On a partner-scoped connection there is nothing to choose: new contacts can only ever be created for that connection’s partnership.

If someone’s sign-in matches more than one partnership, they are asked to choose which one to enter.

Default role

The role given to a user created by JIT when no group mapping applies.

Group to role mapping

Set the Group attribute your IdP sends, then map IdP group names to Journeybee roles. Group names are matched case-insensitively, and each group can only be mapped once.

Anyone whose groups do not match a mapping gets the default role.

Step 5: Test, then enable

A new connection is created disabled. That is on purpose: test it first.

Run test opens a new tab, sends you through the IdP, and shows you the profile that was asserted, including the groups. No session is created and nobody is signed in, so it is safe to run against a live connection.

Test works while the connection is still disabled. Partner-scoped connections are tested from the partner portal once portal sign-on is on.

When the asserted profile looks right, switch the connection to Enabled.

Managing connections

The connection list shows each connection's name, scope, verified domain count, and its Enabled, Enforce and JIT switches. You can toggle those from the row.

There is no per-connection sign-in link to distribute. People start from the normal sign-in page and enter their email address, and Journeybee routes them to the right connection.

Delete removes the connection. Anyone who signs in through it loses that route immediately, so make sure they have another way in first.

Troubleshooting

The Single Sign-On page is not in my settings

It needs the Enterprise SSO module and the Admin role. Contact Journeybee support to have the module enabled.

Domain verification keeps failing

Check the TXT record name and value against what is shown, and give DNS a few minutes. If the domain is already verified by another organisation, contact support.

A user signs in but lands with the wrong role

Run the test and look at the asserted groups. Either the group attribute is not the one your IdP actually sends, or the group name does not match a mapping, in which case they get the default role.

With just-in-time provisioning off, they need an invitation before their first SSO sign-in. Either invite them or turn JIT on.

There is no password fallback while enforcement is on. Contact Journeybee support, who can disable enforcement for the connection after verifying the request.

Portal SSO requires a verified custom domain. Check Settings, then Portal Settings, and confirm the domain shows as Live.

Good to know

Provider type and scope are locked after creation. Everything else, including secrets and metadata, can be rotated in place.
Test before enabling, every time. The test shows you the real asserted profile rather than making you guess from a failed login.
Company-wide enforcement covers every active member of your team, whether or not their email is on a claimed domain. Domains only decide which connection a sign-in is routed to.
Partner-scoped connections let a large partner use their own IdP for your portal, which is often what unblocks an enterprise partner's security review.

Company Profile: the sign-in methods available to your team.
Custom Domains: required before portal SSO will work.
Team Management: the roles your group mappings assign.
Partner Portal: how partners sign in generally.