SAML assertion errors after IdP certificate update

Question

We recently completed a scheduled certificate rotation on our Okta tenant per our security policy (certificate valid from 2025-08-15 to 2026-08-15). Following the rotation, a subset of users—approximately 12 of 340—are experiencing authentication failures when attempting to access FieldPulse via SSO.

Error Manifestation 
 The affected users receive a generic "Authentication failed" message at the FieldPulse login screen after successful authentication at the IdP. I have confirmed that: 
 
 The IdP-initiated flow completes successfully on the Okta side (SAML assertion generated, no policy violations) 
 The SP-initiated flow exhibits identical failure patterns 
 The discrepancy is not correlated with user role, department, or last login timestamp 
 Metadata refresh has been performed on both systems

IdP Configuration Details 
 
 Identity Provider: Okta Workforce Identity Cloud 
 SAML Version: 2.0 
 Binding: HTTP-POST 
 NameID Format: EmailAddress (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress) 
 Signature Algorithm: RSA_SHA256 
 Certificate Chain: Single certificate, no intermediates

From a governance perspective, I am particularly concerned that the failure is selective rather than universal. This suggests a potential mismatch in attribute mapping or certificate validation logic that is not immediately apparent in the standard integration documentation.

It is worth noting that our previous certificate rotation (August 2024) proceeded without incident using identical procedures.

I have captured SAML assertion samples from both successful and failed authentications. The differences appear minimal, though I observe that the failed assertions contain an additional saml:AuthnContextClassRef node that was not present in our prior configuration. I am uncertain whether FieldPulse's SAML implementation enforces strict schema validation that might reject assertions with this element.

Requesting guidance on: 
 
 Whether FieldPulse maintains certificate pinning that would require explicit update on the service provider side 
 Any known issues with AuthnContextClassRef handling in the current SAML implementation 
 Recommended debugging steps to capture SP-side validation errors (currently obscured by generic error messaging)

Ticket reference: FP-SAML-20250902-001

Eli Torres (Staff) · Accepted Answer

Hey Fatima — yeah this one tripped me up too when I first looked at it. Carlos is on the right track, and I want to give you the full picture from our side.

Root Cause 
 FieldPulse's SAML implementation uses a strict schema validator that flags assertions containing AuthnContextDeclRef as malformed. This is technically a bug on our end — the element is valid per SAML 2.0 spec, but our parser was written against an older profile that didn't anticipate IdP-specific extensions.

Immediate Fix 
 I've filed ENG-4421 to properly handle extended AuthnContext elements. Target fix is 3.4 (mid-October). Until then, you have two options:

Option A: Okta Sign-On Policy Rule (Recommended) 
 In your Okta Admin Console: 
 
 Security > Authentication > Sign On Policies 
 Locate the policy applied to your FieldPulse app 
 Add a rule: IF user is accessing FieldPulse THEN skip step-up authn requirements 
 This suppresses the AuthnContextDeclRef injection specifically for FieldPulse while preserving it for other applications

Option B: FieldPulse Configuration Override 
 I can enable relaxed validation for your tenant specifically. This requires a security review on our end (24–48 hour turnaround). Reply here with your account ID if you want me to start that process.

Longer Term 
 We're updating our SAML library to pysaml2 7.5+ which handles extended AuthnContext properly. This will ship with 3.4.

Documentation reference: Single Sign-On (SSO) Configuration (I'll add a troubleshooting section for this specifically).

Let me know if you need the exact Okta rule configuration — I can share screenshots.

Carlos Vega · Answer

That AuthnContextDeclRef is your culprit. FieldPulse's SAML validator doesn't expect extended AuthnContext elements and likely fails schema validation. Two paths:

Option 1: IdP-side (recommended) 
 Configure Okta to suppress AuthnContextDeclRef for this SP. In your SAML app settings: 
 Settings > Sign On > SAML 2.0 > Advanced Settings
> Assertion Encryption > Authentication context class mapping 
 Or use an Okta expression language rule to conditionally omit the element based on SP entity ID.

Option 2: SP workaround 
 Contact FieldPulse support to disable strict AuthnContext validation. YMMV—they may not expose this toggle.

We've hit this with other IdPs too. Ping me if you need the Okta config specifics.