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

  • 0

    Can you share the full SAML response from a failed attempt? Redact sensitive values but keep the structure intact. Also:

    • Are you using IdP or SP-initiated flow primarily?
    • What's the NotOnOrAfter timestamp in the failed assertions vs. successful ones?
    • Any clock skew between your IdP and FieldPulse servers?

    I've seen Okta inject that AuthnContextClassRef when password policy changes trigger step-up authn. The SP might be rejecting it if it's expecting a specific value.

  • 0

    Carlos, thank you for the diagnostic framework. Please find the requested information below.

    SAML Response Structure (Failed Authentication)

    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="id-abc123"
    IssueInstant="2025-09-02T14:15:30.123Z"
    Version="2.0">
    <saml2:Issuer>www.okta.com/.../saml2:Issuer>
    <saml2:Subject>
        <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
            affected.user@company.com
        </saml2:NameID>
        <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml2:SubjectConfirmationData NotOnOrAfter="2025-09-02T14:20:30.123Z"
                Recipient="">auth.fieldpulse.io/.../
            >
        </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2025-09-02T14:10:30.123Z"
        NotOnOrAfter="2025-09-02T14:20:30.123Z">
        <saml2:AudienceRestriction>
            <saml2:Audience>auth.fieldpulse.io/.../saml2:Audience>
        </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AuthnStatement AuthnInstant="2025-09-02T14:15:25.456Z"
        SessionIndex="idx_abc123">
        <saml2:AuthnContext>
            <saml2:AuthnContextClassRef>
                urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
            </saml2:AuthnContextClassRef>
            <saml2:AuthnContextDeclRef>
                schemas.okta.com/.../step-up
            </saml2:AuthnContextDeclRef>
        </saml2:AuthnContext>
    </saml2:AuthnStatement>
</saml2:Assertion>

    Comparative Analysis

    AttributeFailedSuccessful
    NotOnOrAfter2025-09-02T14:20:30.123Z2025-09-02T14:18:45.789Z
    AuthnInstant2025-09-02T14:15:25.456Z2025-09-02T14:12:10.234Z
    AuthnContextDeclRefPresent (step-up)Absent
    Clock skew (IdP vs. SP)Confirmed <2 secondsIdentical

    I have confirmed that the 5-minute assertion lifetime is consistent across both populations. The presence of AuthnContextDeclRef with the Okta step-up authentication URI appears to be the discriminating factor.

    Further investigation reveals that the affected users were subject to a recent password policy update requiring MFA enrollment. Users who completed MFA enrollment prior to the certificate rotation are unaffected. This correlation was not initially apparent.

  • 0

    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.

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

  • 0

    Eli, thank you for the comprehensive response. We have implemented Option A as an interim measure.

    Resolution Confirmation

    I configured a dedicated sign-on policy rule for the FieldPulse application within Okta:

    • Rule Name: FieldPulse_SAML_Compatibility
    • Condition: Application is FieldPulse
    • Action: Skip step-up authentication

    Following policy deployment, I validated authentication flows for 5 previously affected users. All assertions now generate without the AuthnContextDeclRef element, and SP validation completes successfully.

    From a governance perspective, I have documented this as a temporary compatibility measure with a scheduled review date coinciding with FieldPulse 3.4 release. I have submitted account ID FP-ACCT-8847 via support ticket for the permanent fix tracking.

    It is worth noting that this approach maintains our security posture—the step-up authentication remains enforced for all other applications, and FieldPulse access retains MFA via the primary Okta sign-on policy. The risk delta is acceptable for the interim period.

    I will monitor ENG-4421 for resolution confirmation. Thank you to Carlos and Eli for the collaborative diagnosis.