SAML — Microsoft Entra ID

Entra ID (formerly Azure AD) is the second most common enterprise IdP after Okta. The SAML 2.0 setup is similar in shape to Okta but with Microsoft-specific terminology and a handful of quirks. This guide walks the full handshake.

If your B2B customer's IT team is on Microsoft 365, they almost certainly use Entra for SSO. Even if their primary collaboration is Slack or Google Workspace, the company-wide identity layer often still lives in Entra.

Before you start

Customer-side prerequisites:

• An Entra tenant.
• An admin account with "Cloud Application Administrator" or "Global Administrator" role.

Your side:

• Your IntelliAuth tenant URL ready.

Step 1 — start the connection on the IntelliAuth side

Tenant admin console → Authentication → SAML connections → New connection.

Fill in:

• Connection name — e.g. "Acme Corp Entra".
• Slug — e.g. acme-entra.

Save. IntelliAuth returns:

• ACS URL (Reply URL, in Microsoft terminology) — https://<your-tenant-url>/auth/saml/acme-entra/acs.
• SP Entity ID (Identifier, in Microsoft terminology) — https://<your-tenant-url>/saml/acme-entra.
• SP metadata URL.

Share these with the customer's IT.

Step 2 — register the Enterprise Application in Entra

The customer's IT admin in the Azure portal:

1. Entra ID → Enterprise applications → New application → Create your own application.
2. Name: "Cymmetri Banking".
3. Choose "Integrate any other application you don't find in the gallery (Non-gallery)".
4. Create.

After creation:

5. In the new app, open Single sign-on → SAML.

6. Basic SAML Configuration:

   • Identifier (Entity ID) → paste the SP Entity ID you provided.
   • Reply URL (Assertion Consumer Service URL) → paste the ACS URL.
   • Sign on URL → optional; use IntelliAuth's SP-initiated URL if you want a "sign in" entry point.

7. Attributes & Claims — the default Entra set is:

   Claim name	Source
   Unique User Identifier (Name ID)	user.userprincipalname
   givenname	user.givenname
   surname	user.surname
   emailaddress	user.mail
   name	user.userprincipalname

   Add a custom claim for groups if you want IntelliAuth to receive group memberships — see "Groups" below.

8. SAML Certificates — Entra has already generated one. Click "Download" on the "Certificate (Base64)" or "Federation Metadata XML" line. You will paste this into IntelliAuth.

Step 3 — feed Entra's metadata to IntelliAuth

Two options:

• Federation Metadata XML — the full self-describing document. Paste it into the IntelliAuth connection editor. Best for keeping the connection in sync as Entra rotates its signing certificate.
• App Federation Metadata URL — Entra serves the same metadata at a stable URL. Even better: paste the URL into the connection editor and IntelliAuth refreshes the certificate automatically.

The metadata URL option is the right default; manual XML pastes go stale on cert rotation.

Step 4 — attribute mapping in IntelliAuth

The connection editor surfaces the SAML attributes Entra sends. Map them to IntelliAuth user fields:

• emailaddress → user's email.
• givenname → given name.
• surname → family name.
• name (Entra's UPN) → username or username-only display.
• groups (if configured on Entra side) → IntelliAuth group memberships.

For custom claims (department, employee id, region), map them to IntelliAuth user attributes.

Step 5 — JIT provisioning + assign users

Enable JIT in the connection settings so the first sign-in creates the user record automatically.

In Entra, assign the application to users or groups:

• Enterprise applications → your app → Users and groups → Add user/group.
• For initial testing, assign a single test user.
• For production, typically assign a group that represents "everyone who should have access to Cymmetri Banking" — managing membership in that group then controls access without further IntelliAuth-side changes.

Step 6 — test

The test user signs into the Microsoft 365 portal (portal.office.com) and opens the app from their app launcher. They should round-trip into your product, signed in.

For SP-initiated testing: in IntelliAuth, the connection page has a "Try sign-in" button. Click it; you should be sent to Entra, sign in, and come back.

The Entra-specific gotchas

Groups limit

Entra includes group memberships in the SAML response, but if the user is in more than 150 groups, the response carries an overage claim instead — a link to fetch the full list from Microsoft Graph. IntelliAuth does not by default follow the overage link.

Workarounds:

• Filter groups in Entra's "Attributes & Claims" → "Groups assigned to the application" so only relevant ones are sent.
• Use security groups, not Office 365 groups (smaller in number typically).
• Configure Entra to send group claims only for groups assigned to this application.

UPN vs email

Entra's userprincipalname is usually user@company.com, but for some tenants it is user@company.onmicrosoft.com (the legacy form). If user.mail is empty on a user, the SAML response will not include an email — and IntelliAuth's email-required policy will refuse the sign-in. The fix is on the Entra side: populate the mail attribute on each user, or remap IntelliAuth's "email" field to the UPN claim if your tenant accepts that.

Conditional Access

If the customer has Conditional Access policies (block sign-ins from outside the corporate network, require compliant devices, etc.), those policies fire before the SAML response is generated. A user who fails Conditional Access will see Microsoft's block screen and never reach IntelliAuth. The audit log on the IntelliAuth side will show no record of the attempt. This is normal — the policy is doing what it should.

Certificate rotation

Entra rotates its SAML signing certificate every 1–3 years. If you used the metadata URL (recommended), this is handled automatically. If you pasted the certificate by hand, watch for InvalidSignature errors in the audit log and refresh.

See also

• SAML — Okta
• Federation — OIDC and SAML
• Sign in with Microsoft