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

SAML assertion errors after IdP certificate update

Fatima Al-Rashid

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:

  1. The IdP-initiated flow completes successfully on the Okta side (SAML assertion generated, no policy violations)
  2. The SP-initiated flow exhibits identical failure patterns
  3. The discrepancy is not correlated with user role, department, or last login timestamp
  4. 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:

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

Ticket reference: FP-SAML-20250902-001

Parents
  • 0

    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:

    1. Security > Authentication > Sign On Policies
    2. Locate the policy applied to your FieldPulse app
    3. Add a rule: IF user is accessing FieldPulse THEN skip step-up authn requirements
    4. 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.

Reply
  • 0

    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:

    1. Security > Authentication > Sign On Policies
    2. Locate the policy applied to your FieldPulse app
    3. Add a rule: IF user is accessing FieldPulse THEN skip step-up authn requirements
    4. 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.

Children
No Data