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

Users with a matching verified domain must sign in through SSO. Password sign-in stops working for them.

Company admins keep password login as a break-glass fallback, deliberately, so an IdP outage cannot lock you out of your own workspace entirely.

Just-in-time provisioning

Creates the Journeybee account automatically the first time someone signs in through the connection. With JIT off, a user has to be invited before their first SSO sign-in will work.

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.

Copy sign-in link gives you a direct link to that connection's sign-in flow, which is the easiest thing to send to a partner organisation or put in your own intranet.

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.

Company admins retain password sign-in as a break-glass fallback. If enforcement still needs lifting, Journeybee support can disable it for the connection.

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.
Enforcement applies to users on a verified domain. A user on a domain you have not claimed is unaffected.
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.