PingFederate SSO Failures: Diagnosing First-Attempt-Only Authentication Errors and 404s

When PingFederate SSO fails on the first attempt and succeeds on retry, the failure pattern is diagnostic in itself. A system that recovers on retry is not broken end-to-end. It is losing state between two steps of a multi-step flow and then restarting cleanly on the second pass. Three misconfiguration patterns account for the overwhelming majority of first-attempt-only failures in PingFederate deployments.

Cause 1: Load balancer session affinity misconfiguration. In a PingFederate cluster, each node stores in-flight SSO transaction state in memory on the node that handled the first request. During SP-initiated SSO, the user's browser sends the SAML AuthnRequest to node 1, which creates the transaction and stores its state locally. If the load balancer then routes the SAML response or SP callback to node 2, that node has no record of the transaction and returns a 404 or system error. On retry, the browser often reconnects through node 1 by chance or via IP affinity, finds the state, and completes successfully. The user assumes the first attempt was a fluke.

Cause 2: SameSite cookie attribute misconfiguration. Modern browsers, beginning with Chrome 80 in early 2020, enforce SameSite=Lax by default for cookies that do not specify an explicit SameSite attribute. During SP-initiated SSO, the browser makes a cross-site POST to the PingFederate endpoint. If the PingFederate session cookie does not carry SameSite=None with the Secure attribute, the browser drops the cookie on this cross-site POST. PingFederate cannot find the session and returns an error. On retry, after the cookie is re-established in a first-party context during the initial page load, the subsequent cross-site POST may succeed.

Cause 3: Clock skew between the IdP and SP. SAML assertions carry NotBefore and NotOnOrAfter conditions that define a narrow validity window. If the clock on the SP differs from the PingFederate server clock by more than the configured tolerance, the SP rejects assertions as either not yet valid or already expired. Because clock drift is not uniform across time, some assertions pass and others fail depending on when exactly the assertion was issued relative to the drift at that moment, which produces intermittent failures rather than a consistent outage.

PingFederate logs all SSO activity to <PF_INSTALL_DIR>/log/server.log. The default logging level captures errors and warnings, which is sufficient to identify most failures, but enabling verbose Policy Tree logging reveals the exact step and node where a session breaks.

To enable verbose Policy Tree logging:

1. Log in to the PingFederate admin console.
2. Navigate to System > Server > Log Settings.
3. Find the Policy Tree logger and set it to Verbose.
4. Save the change. In a clustered environment, repeat this step on every node.
5. Clear your browser's cookies and cache to start a clean session.
6. Reproduce the failure.

After reproducing the failure, open server.log and search for lines matching the timestamp of the failed attempt. Use the pf-tracking-id from the browser's network trace (visible in browser DevTools under the Network tab, in the headers of the request to the PingFederate endpoint) or the PingFederate session cookie value to filter log lines to the specific failed request and ignore unrelated activity from other users.

Key log strings to search for and what they indicate:

• No session found for token: the node receiving the request has no record of the transaction, which points to a load balancer affinity failure routing the callback to a different node than the one that started the flow.
• Assertion is not yet valid: the SP's clock is behind the IdP's clock, causing the assertion's NotBefore to be in the future from the SP's perspective. This is clock skew.
• Assertion has expired or NotOnOrAfter: the SP's clock is ahead of the IdP's clock, or the network or processing delay exceeded the assertion's validity window.
• SameSite or cookie rejection messages: browser-enforced cookie policy is dropping the session cookie on a cross-site request.
• WARN lines referencing SAMLResponse: malformed or rejected SAML assertion, which may indicate a metadata mismatch or signature verification failure.

If the logs show the error only on the first attempt and not on the successful retry, the error message itself will distinguish the causes. Load balancer affinity failures consistently produce 'No session found.' Clock skew produces assertion validity messages. Cookie failures produce session lookup errors that may look similar to affinity failures but appear even on single-node setups where node routing is not a factor.

SameSite cookie misconfigurations became a widespread issue starting with Chrome 80's enforcement of SameSite=Lax as the default for cookies that do not specify the attribute. PingFederate's session cookies need to carry SameSite=None; Secure to pass through cross-site POST requests during SP-initiated SSO flows. Without this, any browser enforcing the SameSite default will drop the cookie, and PingFederate will be unable to associate the SAML response with the in-flight transaction.

To configure SameSite=None in PingFederate 10.3 and later: Add or update the following properties in your run.properties or pingfederate.properties file, located in <PF_INSTALL_DIR>/pingfederate/bin/:

pf.samesite.cookie.support.enabled=true
pf.samesite.cookie.support.samesite.value=None

Save the file and restart PingFederate for the change to take effect. In a cluster, apply and restart each node individually rather than simultaneously to avoid a full outage.

The SameSite=None attribute requires the Secure flag, and the Secure flag requires HTTPS. Confirm that your PingFederate endpoints are served over HTTPS end-to-end. If PingFederate terminates TLS at a load balancer or reverse proxy rather than at the application server, verify that the proxy passes the X-Forwarded-Proto: https header correctly so PingFederate knows the connection is secure and sets the Secure attribute on the cookies it issues. Without this header, PingFederate may omit the Secure flag even with SameSite=None configured.

After applying the change, test with a clean browser session in Chrome, Firefox, and Safari, as each browser enforces SameSite rules slightly differently. Confirm in browser DevTools under Application > Cookies that the PingFederate session cookie now shows SameSite: None and Secure: true. If the Secure flag is missing, the SameSite=None attribute will be ignored by most browsers, and the problem will persist.

Sticky sessions, also called session affinity or server affinity, ensure all requests from a given browser session route to the same PingFederate cluster node for the duration of the SSO transaction. Without sticky sessions in a clustered deployment, the load balancer can route the initial SSO request to node 1 and the SAML callback to node 2, producing the 'No session found' error because node 2 never saw the transaction state that node 1 created.

NGINX (requires NGINX Plus sticky module):

upstream pingfederate {
    sticky cookie pf_srv_id expires=1h path=/ httponly;
    server pf-node1.example.com:9031;
    server pf-node2.example.com:9031;
}

Set the expiration to cover your longest expected SSO flow plus a reasonable buffer. One hour is typically sufficient for interactive login flows.

HAProxy:

backend pingfederate
    balance roundrobin
    cookie PF_STICKY insert indirect nocache
    server pf1 10.0.0.1:9031 check cookie pf1
    server pf2 10.0.0.2:9031 check cookie pf2

AWS Application Load Balancer: In the target group settings, enable Stickiness with type lb_cookie and a duration of 3600 seconds. The ALB sets its own persistence cookie to track node affinity.

F5 BIG-IP: Create a cookie persistence profile with cookie method set to Insert and assign it to the virtual server handling PingFederate traffic. Set the timeout to 3600 seconds to match the session lifetime.

After enabling sticky sessions, verify by checking which PingFederate node is encoded in the affinity cookie value visible in browser DevTools during a login attempt. Confirm that the same node handles both the initial SP redirect and the SAML callback. Run the test across at least five separate browser sessions from different client IPs to ensure the load balancer is not rotating nodes between requests in a way that defeats cookie-based affinity.

SAML assertion validity windows are designed to be narrow, and PingFederate's default clock skew tolerance does not provide unlimited forgiveness for clock drift. When the difference between the PingFederate server's clock and the SP's clock exceeds the configured tolerance, assertions are rejected as either not yet valid or already expired, producing intermittent SSO failures that are time-dependent and difficult to reproduce consistently.

Step 1: Verify NTP synchronization on all PingFederate nodes. On each PingFederate node, confirm that an NTP client is active and synchronized:

# Systems using systemd-timesyncd
timedatectl status

# Systems using chrony
chronyc tracking

Both commands should show the system clock synchronized with an NTP source and drift within 100 milliseconds. If a node is not synchronized or the drift is elevated, check the NTP client configuration and confirm the upstream NTP server is reachable from the node.

Step 2: Verify NTP synchronization on the SP. Clock skew is a bilateral problem. If the PingFederate nodes are synchronized but the SP server is not, assertions still fail when the SP evaluates the NotBefore and NotOnOrAfter conditions. Work with the SP owner to verify their NTP configuration independently and confirm drift is within tolerance.

Step 3: Adjust the clock skew tolerance in PingFederate if needed. In the PingFederate admin console, the allowed clock skew is configurable per partner connection in the SP connection settings under SAML Profiles or Assertion Validity. The default tolerance is typically three minutes. Raising it to five minutes buys headroom while you correct the underlying synchronization issue, but it should be treated as a temporary measure only. A permissive clock skew setting weakens the replay protection that the validity window provides.

After synchronizing clocks and optionally extending the skew tolerance, reproduce the SSO flow and confirm that server.log no longer contains 'assertion is not yet valid' or 'assertion has expired' messages for the partner connection in question.

Open a Ping Identity support ticket when the following conditions are all true and failures persist:

• Sticky sessions are confirmed working. The same PingFederate node handles both the initial SSO request and the SAML callback, verified in load balancer logs or by inspecting the affinity cookie in browser DevTools.
• SameSite=None; Secure is set on PingFederate session cookies and confirmed visible in browser DevTools under Application > Cookies.
• All PingFederate nodes and the SP are NTP-synchronized with drift below 500 milliseconds, confirmed with timedatectl status or chronyc tracking.
• Failures persist across clean browser sessions on multiple browsers and multiple client devices.
• The failure reproduces consistently in a controlled test environment with verbose Policy Tree logging enabled, not just from help desk reports.

Before opening the ticket, collect the following artifacts because Ping Identity support will request them upfront and cases with complete artifact sets resolve significantly faster:

• Full server.log output with verbose Policy Tree logging enabled, covering the time window of a reproduced failure. Include logs from all cluster nodes.
• Browser DevTools network trace exported as a HAR file, showing all requests and responses including headers during the failed SSO attempt.
• The SP metadata XML and the partner connection XML exported from the PingFederate admin console.
• PingFederate server version and patch level, found under System > Server > Server Information in the admin console.
• Load balancer type, version, and the sticky session configuration currently applied to the PingFederate backend.

For cluster-wide outages affecting all users, classify the case as severity 1 or 2. For intermittent failures affecting a subset of users or specific browser types, severity 3 is appropriate. Ping Identity's support portal allows upgrading severity if the situation worsens after initial submission.