• State Verified Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 2 views
  • Users 0 members are here
Options
Related

SSO implementation with Okta — SAML assertion failing for subset of users

Rachel Nguyen

We migrated our IdP from Azure AD to Okta last weekend. SSO is functional for approximately 85% of our user base, but I'm seeing consistent authentication failures for a specific subset of users.

Failure Pattern:

  • Affected users: 23 of 156 total licensed FieldPulse users
  • Commonality: All affected users were created in FieldPulse prior to March 2024
  • Error received: "SAML assertion validation failed" with no additional detail in the login UI

Environment Details:

  • FieldPulse SSO configuration: SAML 2.0
  • IdP: Okta (production tenant)
  • NameID format: EmailAddress
  • Attribute mapping: email → email, firstName → firstName, lastName → lastName
  • SP-initiated and IdP-initiated flows both exhibit the same failure pattern

Diagnostics Completed:

  • Verified Okta user profiles have correct email addresses (no trailing spaces or special characters)
  • Confirmed affected users have active Okta assignments and can authenticate to other SPs
  • Exported SAML assertion from browser dev tools — signature validates successfully against Okta certificate
  • Compared assertion XML between working and failing users: identical structure, differing only in user-specific values
  • Checked FieldPulse audit logs at Settings → Security → Audit Log: login attempts from affected users do not appear (no entry at all, success or failure)

The absence of audit log entries suggests the failure occurs before FieldPulse processes the assertion. I have confirmed that the email address in the NameID matches exactly what is stored in FieldPulse user records.

Has anyone encountered selective SAML failures based on user creation date or historical IdP linkage? I suspect there may be residual metadata from the previous Azure AD configuration causing a mismatch, but I cannot locate where FieldPulse stores historical IdP identifiers per user.

I can provide redacted SAML assertions via direct message if helpful for analysis.

Parents
  • 0

    I have observed similar behavior during IdP migrations. FieldPulse maintains a sso_external_id mapping that is not exposed in the UI. When you initially configured Azure AD, each user was provisioned with an immutable identifier tied to Azure's objectId (or oid claim). This value persists even after IdP reconfiguration.

    The likely cause is that your affected users have an sso_external_id that does not match the new NameID format from Okta. FieldPulse's SAML handler attempts to match on this identifier before falling back to email-based lookup.

    Recommended diagnostic steps:

    1. Open a support ticket to request a report of sso_external_id values for your user base
    2. Compare these against the NameID values present in your Okta SAML assertions
    3. If mismatched, request that FieldPulse support clear the sso_external_id fields for affected users, or re-provision them with the correct Okta identifier

    Note that clearing this field will require affected users to complete a one-time re-linking on their next login, but will not affect their job history or permissions.

  • 0 in reply to Anita Sharma

    Anita's got it right — this is almost certainly the sso_external_id mismatch. The audit log silence is the tell: FieldPulse bails out of SAML processing before it ever writes anything to the log when the identifier lookup fails.

    Yeah this one tripped me up too when I first looked at it — the docs don't mention that this field persists across IdP changes because technically it's supposed to be immutable per the SAML spec. In practice, migrations happen and we don't always handle the cleanup gracefully.

    Quick way to confirm without waiting for support: grab the NameID from your Okta assertion and check if it matches the email address stored in FieldPulse. If NameID is the email but the user still fails, that's your smoking gun — the sso_external_id is set to something else (probably the old Azure GUID) and FieldPulse is looking for that instead.

    Workaround if you need users functional immediately: temporarily configure Okta to send the old Azure objectId as an attribute (not NameID), then map that in FieldPulse's custom attribute configuration. Or just wait for support to clear the fields — usually same day for this request.

    Heads up: we're tracking a feature request to expose sso_external_id in the admin UI so admins can manage this without support tickets. No ETA yet but it's on the radar.

    I've linked this to Single Sign-On (SSO) Configuration — the troubleshooting section there will be updated with this scenario once we confirm the root cause.

Reply
  • 0 in reply to Anita Sharma

    Anita's got it right — this is almost certainly the sso_external_id mismatch. The audit log silence is the tell: FieldPulse bails out of SAML processing before it ever writes anything to the log when the identifier lookup fails.

    Yeah this one tripped me up too when I first looked at it — the docs don't mention that this field persists across IdP changes because technically it's supposed to be immutable per the SAML spec. In practice, migrations happen and we don't always handle the cleanup gracefully.

    Quick way to confirm without waiting for support: grab the NameID from your Okta assertion and check if it matches the email address stored in FieldPulse. If NameID is the email but the user still fails, that's your smoking gun — the sso_external_id is set to something else (probably the old Azure GUID) and FieldPulse is looking for that instead.

    Workaround if you need users functional immediately: temporarily configure Okta to send the old Azure objectId as an attribute (not NameID), then map that in FieldPulse's custom attribute configuration. Or just wait for support to clear the fields — usually same day for this request.

    Heads up: we're tracking a feature request to expose sso_external_id in the admin UI so admins can manage this without support tickets. No ETA yet but it's on the radar.

    I've linked this to Single Sign-On (SSO) Configuration — the troubleshooting section there will be updated with this scenario once we confirm the root cause.

Children
No Data