Enterprise SSO
Overview of how Enterprise SSO works in ThreatSabre and how to set it up
Enterprise SSO overview
ThreatSabre Enterprise SSO lets your organisation sign in with your company identity provider (IdP) using SAML 2.0, instead of (or alongside) email and password.
This page explains how SSO works in ThreatSabre, important limitations, and how to request it. After ThreatSabre sends your ACS / Reply URL and SP Entity ID (Audience), your IdP team should follow the matching setup guide:
| Guide | Use when |
|---|---|
| Generic SAML IdP | Any SAML 2.0 provider that is not Entra or Okta |
| Microsoft Entra ID | Azure AD / Entra ID enterprise app (SAML) |
| Okta | Okta SAML application |
Those values from ThreatSabre must match exactly in your IdP. Wrong ACS or Entity ID usually causes a SAML validation error at sign-in.
How it works
- A user opens the ThreatSabre login page and chooses Enterprise SSO, then enters their work email.
- ThreatSabre routes that email domain to your tenant’s SSO connection.
- The user authenticates at your IdP (Entra, Okta, or another SAML provider).
- On each successful sign-in, ThreatSabre reads the user’s IdP group memberships from the login and applies the mappings you configured in tenant admin:
- Group mappings — IdP group → ThreatSabre user group (which organisations and permissions they get)
- Role mappings — IdP group → tenant role (Member or Admin)
- Access is re-evaluated on every SSO login. Changes in your IdP (joining or leaving a group) take effect the next time the user signs in with SSO.
Limitations and important rules
Read these before requesting SSO — they affect how you design access.
One tenant per SSO setup
Enterprise SSO is tied to one ThreatSabre tenant. Email domains used for SSO routing are unique: only one customer can claim a given domain (for example acme.com).
Organisation and role access come from the IdP
For SSO users:
- Which organisations they can see and what they can do are controlled by ThreatSabre user groups that already have organisation and permission-profile assignments.
- You map IdP groups to those ThreatSabre groups (and optionally to tenant Admin / Member).
- You do not assign SSO users to organisations one-by-one in the usual invite flow for those identities.
Enterprise SSO users cannot be invited
SSO creates a separate identity from email/password. Users who only sign in with Enterprise SSO are provisioned through SSO enrolment. They are not added by inviting them as a normal email user into the tenant.
If someone previously used email/password under the same address, that older account does not automatically receive the same access on the SSO identity. Access for the SSO identity comes only from IdP groups → your mappings (or your fallback policy).
Owner is never assigned by SSO
Tenant Owner cannot be granted via IdP role mappings. Role mappings may assign Member or Admin only. Existing owners are never demoted by SSO.
Owners must be email/password users. A tenant owner can appoint another email user as owner in ThreatSabre; SSO-only users cannot be owners.
SAML only (current product)
The supported path is SAML 2.0. Generic OIDC/OAuth enterprise connections are not available in this phase.
No real-time SCIM
There is no continuous SCIM sync. Group and role changes apply on the user’s next SSO login.
Email sign-in stays available
ThreatSabre always offers Sign in with email on the login page. There is no per-tenant switch to turn email login off or force SSO-only.
That is intentional for tenant administration:
- The tenant Owner must be an email/password user. Owner cannot be granted via IdP role mappings.
- Tenant admins/owners can still remove ordinary email-based members from the tenant if you want those people to use SSO only going forward.
- Enterprise SSO identities are separate from email identities; removing someone’s email membership does not change how SSO enrolment works for a mapped IdP user.
Large IdP directories (especially Entra)
Some IdPs truncate or omit group claims when a user is in very many groups. Prefer a small set of app-assigned groups for ThreatSabre, and use a deliberate fallback policy if unmatched users should still get limited access.
How to request Enterprise SSO
- Open a support ticket with ThreatSabre (or contact your CSM).
- Include the information in What to put in the support ticket.
- ThreatSabre creates the connection and registers your email domain(s), then sends you:
- ACS / Reply URL
- SP Entity ID (Audience)
- Your IdP team configures the SAML app using the guide for your provider (Generic / Entra / Okta).
- Return or confirm the IdP metadata URL if ThreatSabre does not already have it.
- When ThreatSabre confirms your tenant shows Enabled, open Enterprise SSO in the client app and configure mappings (below).
- Run a test login with a user in a mapped IdP group.
What to put in the support ticket
- ThreatSabre tenant name (the tenant you administer).
- Email domain(s) that should use SSO (for example
acme.com). - IdP type — Microsoft Entra ID, Okta, or other SAML.
- Setup order — either:
- IdP metadata URL now (metadata-first), or
- a request for ThreatSabre to send ACS + Entity ID first; you will return the metadata URL after the IdP app is created.
- How groups are identified in your IdP (display names vs Entra group object IDs / GUIDs).
- Whether group membership is sent under a standard attribute (
groups,memberOf, etc.) or a custom attribute name (exact name). - IT contact who will edit the IdP (often different from the ThreatSabre admin).
Configure access in ThreatSabre (after enablement)
Where: Client app → Tenant admin → Enterprise SSO
Path pattern: /tenant/{tenantId}/sso
You need to be a tenant owner or admin. Status on the page should show Enabled after ThreatSabre finishes setup.
Access defaults
| Setting | Meaning |
|---|---|
| Fallback → Assign default group | Users whose IdP groups match no mapping receive the default group below. |
| Fallback → Deny access | Unmatched users get no usable organisation access until you add a mapping. |
| Default group | Least-privilege group used when fallback assigns a default. Prefer a limited / read-only group. |
Tip: Prefer a safe default group for large directories. Use Deny access when you want an explicit allow-list via mappings only.
Group mappings (IdP group → ThreatSabre user group)
Each row:
- IdP group key — exact value from your IdP (Okta: usually the group name; Entra: usually the group object ID / GUID if you emit Group ID).
- Optional label — friendly name in the UI.
- Target user group — a ThreatSabre tenant user group that already has the right organisation and permission-profile assignments.
On every SSO sign-in, membership in SSO-managed groups is re-synced from the IdP. Manual memberships outside that mapping set are left alone.
Role mappings (IdP group → tenant role)
Optional. Maps an IdP group to Member or Admin.
- Unmapped SSO users default to Member.
- Owner cannot be granted via SSO.
- Role is re-applied from the IdP on every sign-in.
Group mappings and role mappings are separate. The same IdP group GUID or name can appear in both tables if that group should both grant a ThreatSabre user group and elevate tenant role.
How users sign in
- Go to the ThreatSabre login page.
- Under Enterprise SSO, enter a work email on a registered domain (for example
you@acme.com). - Click Sign in with Enterprise SSO.
- Complete authentication at your company IdP.
- Land in ThreatSabre; groups and roles update from the IdP for that login.
If the domain is not registered yet, SSO lookup will say enterprise SSO is not available for that domain — reply on the support ticket rather than retrying blindly.