Enterprise SSO - Okta
Setting up Enterprise SSO on Okta
Enterprise SSO — Okta
Configure a SAML 2.0 application in Okta for ThreatSabre.
If you have not requested SSO yet, start with the Enterprise SSO overview.
Other IdPs: Generic SAML · Microsoft Entra ID
Two ways to sequence setup
You can share Okta’s Identity Provider metadata URL with ThreatSabre before or after you finish pasting our ACS and Entity ID. Pick the path that fits your IT process.
| Path | When to use | Order |
|---|---|---|
| A — Metadata first | You can create the Okta app early and want ThreatSabre to build the connection from metadata in the support ticket | Create Okta app → send metadata URL → receive ACS + Entity ID from ThreatSabre → paste them into Okta (and finish attributes/groups) |
| B — ACS / Entity ID first | You prefer ThreatSabre values before (or while) creating the Okta app | Ask ThreatSabre for ACS + Entity ID → create Okta app with those values → send metadata URL → finish attributes/groups |
In both paths, the final Single sign-on URL and Audience URI in Okta must match exactly the values ThreatSabre issues for your tenant. Wrong values usually cause a SAML validation error at sign-in.
| From ThreatSabre | Okta field |
|---|---|
| ACS / Reply URL | Single sign-on URL |
| SP Entity ID (Audience) | Audience URI (SP Entity ID) |
1. Create a SAML 2.0 app
- In Okta Admin, go to Applications → Applications → Create App Integration.
- Choose SAML 2.0.
- Name the app (for example
ThreatSabre).
2. Configure SAML settings
Path A — Metadata first
- You may need temporary Single sign-on URL / Audience URI values to complete the Okta SAML wizard and expose the metadata URL.
- From the app’s Sign On tab, copy the Identity Provider metadata URL and include it in your ThreatSabre support ticket (or send it as soon as the app exists).
- When ThreatSabre replies with your permanent ACS / Reply URL and SP Entity ID, replace any temporary values with those exact strings and save.
Path B — ACS / Entity ID first
- Paste the ThreatSabre ACS / Reply URL and SP Entity ID into the Okta fields in the table above.
- From the Sign On tab, copy the Identity Provider metadata URL and send it to ThreatSabre if they do not already have it.
Typical options:
- Name ID format: EmailAddress or Unspecified (match what you use for user identity).
- Application username: Email.
Do not invent final ACS or Entity ID values — use only what ThreatSabre provides for your tenant.
3. Attribute statements
Add attribute statements so the assertion includes:
| Name (example) | Value |
|---|---|
email | user.email |
firstName | user.firstName |
lastName | user.lastName |
ThreatSabre’s Okta connection profile expects short names such as email, firstName, and lastName.
4. Group attribute statements
Configure a Group Attribute Statement (or equivalent) so group membership is sent to ThreatSabre. Common patterns:
- Attribute name:
groups(or another name you document for ThreatSabre) - Filter: matches the Okta groups that should grant ThreatSabre access
Assign users to the Okta app and to those groups.
Tell your ThreatSabre tenant admin the exact group name strings Okta emits — those become IdP group keys in mappings (usually Okta group names, not Entra-style GUIDs).
If you use a non-standard attribute name instead of groups, include that name in the ThreatSabre support ticket.
5. Confirm metadata with ThreatSabre
Ensure ThreatSabre has your current Identity Provider metadata URL.
- Path A: You usually sent it in the ticket; re-send if the app was recreated.
- Path B: Send it after SAML settings are saved with the correct ACS and Entity ID.
6. Map in ThreatSabre
In ThreatSabre → Enterprise SSO, create group and role mappings using the exact Okta group names from the assertion.
See Configure access in ThreatSabre.
7. Test
- Assign a test user to the app and a mapped Okta group.
- Sign in via ThreatSabre Enterprise SSO.
- Confirm organisations and role match your mappings.