Configure SSO with Okta

Okta can act as the identity provider for ScatterSpoke over SAML 2.0. Configuration is self-serve on both sides: you copy two values out of ScatterSpoke, create an app integration in Okta, and hand Okta’s metadata back.

Before you start

• SSO must be available on your plan — the add-on on Business, or included on Enterprise. See Single sign-on.
• You need administrator access in both ScatterSpoke and Okta.

1. Get the ScatterSpoke values

Go to Settings → SSO and select Enable SSO. Step 1 of the card shows two fields, each with a copy button:

• Entity ID / Issuer — the audience Okta should send
• ACS / Callback URL — where Okta posts the SAML response

Keep these values open while configuring Okta.

2. Create the app integration in Okta

In the Okta admin console, create a new SAML 2.0 app integration. Okta’s own SAML application setup guide walks through the wizard; the steps below are the ScatterSpoke-specific answers.

App name — ScatterSpoke.

SAML settings

Okta field	Value
Single sign on URL	The ACS / Callback URL from step 1
Audience URI (SP Entity ID)	The Entity ID / Issuer from step 1
Default RelayState	Leave blank for the standard sign-in flow
Name ID format	EmailAddress
Application username	Email

Attribute statements — the default ScatterSpoke mapping reads the email from NameID, configured above. If you also send given and family name, ScatterSpoke can use them; if you send nothing but email, it derives a display name from the email instead. Names make the workspace far more readable, so send them if you can.

Assignments — assign the people and groups who should be able to reach ScatterSpoke. Assignment allows a person to use the Okta app. Workspace membership and seat capacity are still managed in ScatterSpoke; an existing Seat Holder does not need another seat for signing in.

Finish the wizard, then open the Sign On tab and copy the Identity Provider metadata URL.

For field definitions, see Okta’s SAML field reference.

3. Connect Okta to ScatterSpoke

Back on Settings → SSO, step 2 offers three routes. Any of them ends at the same form:

• Fetch from URL — paste the Okta metadata URL and select Fetch Metadata. Easiest, and the one to use here.
• Upload metadata.xml — if you downloaded the file instead.
• Or enter manually — paste the SSO URL and X509 certificate yourself.

Either import fills in the SSO URL (entry point) and X509 certificate for you. Review them, then set the mapping:

• Name field and Email field — leave both at nameID unless Okta sends the email under a different attribute name.
• Family name field — only if you send a separate surname attribute.
• Name transform method — Extract from email is the safe default. Choose Use first and last name if you configured separate first and last name attributes in Okta.

Select Save SSO Configuration.

Note

The certificate must be at least 100 characters for the form to accept it. If Save stays disabled, you are probably missing part of a pasted certificate.

4. Test before enforcing

The card now shows SSO is enabled · Active with the entry point, certificate status, and name transform.

Sign in from a private browser window with an Okta-assigned account: enter the work email on the login screen and you should continue to Okta. Only once that round trip works should you turn on Enforce SSO for all users — enforcement disables password login for everyone except organization administrators.

If the test fails

• Okta denies access: check that the test user is assigned to the app and meets its access policy.
• ScatterSpoke cannot identify the user: check that NameID contains the person’s email address, or update Email field to match the attribute actually sent.
• The callback fails: compare the ACS URL and Entity ID with ScatterSpoke, including their full paths. Check that the signing certificate is complete and current.
• The feature is unavailable: check your plan and SSO add-on in Billing.

Keep enforcement off until the test succeeds.

Changing or removing it

• Reconfigure reopens the setup form with the current values. Users signing in during the change may be briefly affected.
• Remove SSO deletes the provider and resets enforcement. Users need another available sign-in method. Confirm that administrators can still access their accounts before removing SSO.