Enterprise SSO — Microsoft Entra ID

Use this guide after ThreatSabre has sent you the ACS / Reply URL and SP Entity ID (Audience) for your tenant.

If you have not requested SSO yet, start with the Enterprise SSO overview.

Other IdPs:

• Generic SAML
• Okta

Values from ThreatSabre must match exactly. Wrong ACS or Entity ID usually causes a SAML validation error at sign-in.

---

Two ways to sequence setup

You can share Entra’s App Federation Metadata Url with ThreatSabre before or after you finish pasting our ACS and Entity ID. Pick the path that fits your IT process.

In both paths, the final Reply URL and Identifier in Entra must match exactly the values ThreatSabre issues for your tenant. Wrong values usually cause a SAML validation error at sign-in.

---

1. Create the enterprise application

1. In the Microsoft Entra admin center, go to Identity → Applications → Enterprise applications.
2. New application → Create your own application → integrate a non-gallery application (or use your preferred SAML gallery path).
3. Name it clearly (for example ThreatSabre).

2. Configure SAML single sign-on

Open the app → Single sign-on → SAML.

Path A — Metadata first

1. You may need temporary Identifier / Reply URL values to save the SAML blade and expose metadata (Entra often requires them before the metadata URL appears).
2. Copy the App Federation Metadata Url and include it in your ThreatSabre support ticket (or send it as soon as the app exists).
3. 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

1. Paste the ThreatSabre ACS / Reply URL and SP Entity ID into the Entra fields in the table above and Save.
2. Copy the App Federation 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.

3. Attributes and claims

Email (required)

Ensure an email claim is released. ThreatSabre expects the Entra email claim URI:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

(ThreatSabre configures this on our connection when IdP type is Entra; your assertion must still include it.)

Also typically present:

• Given name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
• Surname: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Groups (required for mapped access)

1. Under Attributes & Claims, add or edit a group claim.
2. Set Which groups associated with the user should be returned to Groups assigned to the application (recommended — not “All groups”).
3. Set Source attribute / emit format to Group ID (Object ID / GUID).

Using Groups assigned to the application keeps the assertion small and predictable. Using All groups often hits Entra limits and can drop the groups claim entirely.

4. Assign users and groups to the app

Enterprise application → Users and groups:

1. Create a small set of security groups for ThreatSabre (for example ThreatSabre-Admins, ThreatSabre-Analysts) if you do not already have them.
2. Assign those groups (and any required users) to the enterprise app.
3. Copy each group’s Object ID from Entra — that GUID is the IdP group key in ThreatSabre mappings.

5. Confirm metadata with ThreatSabre

Ensure ThreatSabre has your current App Federation Metadata Url.

• Path A: You usually sent it in the ticket; re-send if the app was recreated.
• Path B: Send it after the SAML blade is saved with the correct ACS and Entity ID.

6. Map in ThreatSabre

In ThreatSabre → Enterprise SSO:

• Group mapping IdP group key = Entra group Object ID (GUID), not the display name (unless you deliberately emit display names — Group ID is the supported default).
• Role mapping uses the same GUID keys if an IdP group should grant tenant Admin.

See Configure access in ThreatSabre.

7. Test

1. Test user is a member of an assigned security group.
2. Sign in via ThreatSabre Enterprise SSO.
3. Confirm organisations and role match your mappings.