• State Verified Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 0 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.

  • 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.

  • 0

    From a governance perspective, I would caution against requesting bulk clearing of sso_external_id fields without understanding why the mismatch occurred.

    It is worth noting that Okta's SAML configuration allows you to specify the NameID format on a per-application basis. If your previous Azure AD integration used the urn:oasis:names:tc:SAML:2.0:nameid-format:persistent format (which sends an opaque identifier), and your current Okta configuration uses urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress, the fundamental identifier has changed.

    In my experience, the more robust long-term solution is:

    1. Configure Okta to emit a persistent identifier that matches your historical Azure AD values, or
    2. Implement a formal user re-provisioning workflow that captures the new identifier and updates FieldPulse accordingly

    Bulk clearing may satisfy immediate access requirements, but it creates an audit gap — you will have users authenticating without a verifiable link between their historical SSO sessions and current identity provider.

    I have confirmed that FieldPulse does not currently support SCIM provisioning, which would have provided a cleaner migration path. It may be worth evaluating whether your organization requires this capability for future IdP transitions.

  • 0

    Confirmed — this was the sso_external_id mismatch. Support provided the mapping report and all 23 affected users had Azure GUIDs populated from our 2023 implementation.

    I have confirmed that clearing these fields resolved authentication for 22 of 23 users. The remaining user had a duplicate email address conflict that was masked by this issue — separate problem, now resolved.

    For future reference: FieldPulse support advised they can enable a configuration flag that forces email-based lookup when sso_external_id is present but non-matching, rather than hard-failing. This may be preferable for organizations with similar migration patterns. The flag is not documented and requires support intervention.

    Thanks to Anita and Eli for the rapid diagnosis — saved us significant downtime.

  • 0 in reply to Rachel Nguyen

    Great catch on that flag, Rachel — that's actually a newer configuration option we added for exactly this scenario but haven't fully documented yet. I'll make sure it gets added to the official SSO troubleshooting guide.

    For anyone finding this thread later: the flag is called saml_allow_email_fallback and it's account-scoped. Support can toggle it if you anticipate ongoing IdP transitions or have a hybrid identity environment.