Enterprise SSO - Generic IdP
Setting up Enterprise SSO on a generic SAML identity provider
Enterprise SSO — Generic SAML IdP
Configure a SAML 2.0 application in your identity provider for ThreatSabre.
If you have not requested SSO yet, start with the Enterprise SSO overview.
For Microsoft Entra ID or Okta, use:
Two ways to sequence setup
You can share your IdP 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 SAML app early and want ThreatSabre to build the connection from metadata in the support ticket | Create SAML app → send metadata URL → receive ACS + Entity ID from ThreatSabre → paste them into the IdP (and finish attributes/groups) |
| B — ACS / Entity ID first | You prefer ThreatSabre values before (or while) creating the SAML app | Ask ThreatSabre for ACS + Entity ID → create SAML app with those values → send metadata URL → finish attributes/groups |
In both paths, the final ACS and Entity ID in your IdP must match exactly the values ThreatSabre issues for your tenant. Wrong values usually cause a SAML validation error at sign-in.
| From ThreatSabre | Paste into your IdP as |
|---|---|
| ACS / Reply URL | Assertion Consumer Service (ACS) URL / Reply URL / Single sign-on URL |
| SP Entity ID (Audience) | Audience URI / SP Entity ID / Entity ID |
Field names vary by product; use the pair that means “where to POST the assertion” and “who the assertion is for.”
1. Create a SAML 2.0 application
In your IdP, create an application that supports SAML 2.0 (SP-initiated SSO). Assign the users or groups who should access ThreatSabre.
2. Configure ACS and Entity ID
Path A — Metadata first
- You may need temporary ACS / Entity ID values so the IdP will expose a metadata URL.
- Copy the IdP metadata URL (HTTPS, publicly reachable) 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 IdP fields in the table above and save.
- Copy the IdP metadata URL and send it to ThreatSabre if they do not already have it.
Do not invent final ACS or Entity ID values — use only what ThreatSabre provides for your tenant. Metadata is preferred over pasting certificates manually.
3. Attributes ThreatSabre expects
Send at least:
| Purpose | Typical SAML attribute |
|---|---|
| Email (required for first login) | email, mail, or your IdP’s email claim |
| Groups / roles (for access mapping) | groups, group, memberOf, roles, or role |
If your IdP uses a custom group attribute name, tell ThreatSabre the exact name in the support ticket so we can wire it on our side.
Optional but recommended: first name and last name attributes.
4. Confirm metadata with ThreatSabre
Ensure ThreatSabre has your current IdP metadata URL.
- Path A: You usually sent it in the ticket; re-send if the app was recreated.
- Path B: Send it after ACS and Entity ID are set to the ThreatSabre values.
5. Group keys for ThreatSabre mappings
Decide what string your IdP puts in the group attribute (group name, DN, GUID, etc.). Tenant admins must paste that exact value as the IdP group key in ThreatSabre → Enterprise SSO → group and role mappings.
6. Test
- Confirm ThreatSabre has registered your email domain.
- Sign in via ThreatSabre → Enterprise SSO with a test user.
- Confirm the user lands with the expected organisations after mappings are configured.