Undertow SameSite Cookie Configuration for SAML SSO Compatibility in JBoss EAP 8

Solution Verified - Updated -

Environment

  • JBoss Enterprise Application Platform (EAP)
    • 8.x

Issue

  • Dynamic Path Matching for SameSite=None Cookies in JBoss EAP with Undertow Filters
  • Fixing SAML InResponseTo Validation Errors Caused by SameSite Cookies in EAP 8
  • Configuring SameSite=None for JSESSIONID to Support SAML SSO in JBoss EAP

Resolution

  • The solution is to modify the Undertow filter predicates to accurately match the application's URL structure. A server restart is required after applying these changes.

Two solutions are presented below. The Regex-based solution is highly recommended for its flexibility and robustness across different environments.

Solution 1: For Statically Deployed Applications (Fixed Path)

Use this method if your application's context path is fixed and known (e.g., it is always deployed as /MyApplication).

  • Identify the full context path to your SAML endpoint (e.g., /MyApplication/saml2).

  • Update the existing filter-ref predicates to use this full path.

    Update the section of your standalone.xml configuration file.

Change this:

<filter-ref name="saml-response-samesite-filter" predicate="path-prefix('/saml2')"/>
<filter-ref name="samesite-cookie-filter" predicate="not(path-prefix('/saml2'))"/>

To this (replace with your actual path):

<filter-ref name="saml-response-samesite-filter" predicate="path-prefix('/<Your_App_Context_Path>/saml2')"/>
<filter-ref name="samesite-cookie-filter" predicate="not(path-prefix('/<Your_App_Context_Path>/saml2'))"/>

Solution 2: Recommended for Dynamic Deployments (Regex Path)

This is the preferred solution for environments where the context path may change or if you want a more resilient configuration. It uses a regular expression to match any path containing saml2, regardless of what precedes it.

  a.  Remove the old, incorrect filter references

  b.  Add new filter references using a regex predicate

Execute the following commands using the jboss-cli.sh or jboss-cli.bat tool.

  1. Remove existing filters:
/subsystem=undertow/server=default-server/host=default-host/filter-ref=saml-response-samesite-filter:remove()
/subsystem=undertow/server=default-server/host=default-host/filter-ref=samesite-cookie-filter:remove()
  1. Add new filters with regex predicate:
/subsystem=undertow/server=default-server/host=default-host/filter-ref=saml-response-samesite-filter:add(predicate="regex('.*saml2.*')")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=samesite-cookie-filter:add(predicate="not(regex('.*saml2.*'))")

Configuration (XML - standalone.xml) should look like below:

<filter-ref name="saml-response-samesite-filter" predicate="regex('.*saml2.*')"/>
<filter-ref name="samesite-cookie-filter" predicate="not(regex('.*saml2.*'))"/>

After applying either solution, restart the application server for the changes to take effect. The SAML authentication flow should now complete successfully.

Root Cause

  • The root cause of this issue is a misconfiguration in the Undertow subsystem's filter predicates. Modern security standards
    require browsers to enforce SameSite cookie policies. To comply with this, specific filters (saml-response-samesite-filter
    and samesite-cookie-filter) are configured to manage cookie attributes during the SAML workflow.

  • These filters are applied conditionally based on a predicate, which is a rule that matches against the request URL. The
    problem arises when the predicate is too specific and does not match the application's actual deployment path.

  • For example, a predicate like path-prefix('/saml2') will only match requests that begin exactly with /saml2. If your
    application is deployed under a context path (e.g., /MyApplication), the real SAML endpoint will be /MyApplication/saml2/....
    The path- prefix('/saml2') predicate will fail to match, causing the crucial SameSite filter to be skipped. When the filter
    is skipped, the browser does not send the session cookie with the SAML response, breaking the authentication flow and
    resulting in the InResponseTo error. This is especially common in environments where application context paths are dynamic or
    vary between development, QA, and production.

Diagnostic Steps

Observe the following symptoms:

SAML Authentication Fails: Users are unable to log in via SAML and are often redirected back to the login page or an error screen.

InResponseTo Error: Server logs (e.g., server.log) contain errors related to SAML response validation, specifically mentioning a missing or invalid InResponseTo
attribute. This indicates the server cannot correlate the SAML response from the Identity Provider (IdP) with the original authentication request it initiated.

Browser Network Analysis: Using browser developer tools (Network tab), you can inspect the HTTP requests. You will notice that the
POST request from the IdP to your application's Assertion Consumer Service (ACS) URL does not include the required session cookie
(e.g., JSESSIONID). The URL path for this request might be something like /YourApplication/saml2/sso instead of /saml2/sso.

These symptoms collectively point to a failure in applying a necessary filter to the SAML response, preventing the session cookie
from being correctly processed.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments