Basic Auth in Glassfish 7 vs Payara 5

[kbachl]

Hi,

I upgraded an app to deploy on Glassfish 7.0.25 (coming from payara 5); The following snippet in web.xml leads to an basic auth requirement even on the root path of the app:

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>OData access Path</web-resource-name>
            <url-pattern>/odata/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>Users</role-name>
        </auth-constraint>
    </security-constraint>

    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>file</realm-name>
    </login-config>

    <security-role>
        <role-name>Users</role-name>
    </security-role>

I expected only path
https://10.0.0.30:8443/appName/odata
and e.g.
https://10.0.0.30:8443/appName/odata/..

to trigger it, but it also triggers on
https://10.0.0.30:8443/appName/
?

Has there anything changed in that config part?
Exact same works on payara 5 as expected, if I disable the part of

 <web-resource-collection>
            <web-resource-name>OData access Path</web-resource-name>
            <url-pattern>/odata/*</url-pattern>
        </web-resource-collection>

i can access my app under the
https://10.0.0.30:8443/appName/
as expected. Of course no basic auth on the required path then. Anything I miss here?

[OndroMih]

Hello, @kbachl , would you contact us at https://omnifish.ee/contact-us ? I’d like to know more about your decision to kove from Payara to GlassFish and see how we can help you.

[kbachl]

@OndroMih
sorry for my late answer, did just notice the quesiton now. Easy said our experience with payara stopping updates for non paying customers hit us back in 2022 and we tried several times to upgrade our app to jakarta level but only succeded now in 2025. So we dont want to have this once more and thats the reason we returned to glassfish again. Yes, returned. We switched to payara after glassfish 4 and the problematic state of glassfish 5 at the time when it was unclear what the future path of it was.
However, also our struggle with the VMWare Broadcom debacle lead us to mor relying on official open source projects since this also hit us hard. We are a small SMB (so we have to look at every penny) and used to have the essentials bundle. This was stripped from one day to another and the start in price increased by a factor we cant pay. So we learned the lesson to not trust any software companies with anything that we cant replace easily.
And since glassfish nowadays feels equal to payara (yes, some quirks are there - e.g.: reverse proxy support still needs manual work in domain.xml as setting filter isnt enough) and seems to get released quite often and up to date this is something we prefer to use now.

[OndroMih]

Thank you for your encouraging reply. We're glad that Glassfish helps you be productive and address your isuses. If you have issues with GlassFish, such as the reverse proxy issue you mentioned, please raise an issue on GitHub.

If you'd like to get extra assurance from our expert team and support us in improving GlassFish, please talk to us about commercial support options. I understand you need to be careful about finances, but our support prices are affordable and we can talk about discounts. We are also a small company and would use the money wisely, to your benefit and benefit of the community. We strongly believe in free opensource and we want to continue following our policy and never change it, but we also need financial support to continue doing it on a reasonable scale.

[RinZ27]

This is a known behavioral change related to security constraint evaluation in Jakarta EE 10 (Servlet 6.0). Let me break down what is happening and provide the standard solutions.

Why This Is Happening

1. Servlet 6.0 Strictness

Between Servlet 4.0 (Java EE 8) and Servlet 6.0 (Jakarta EE 10), there were major clarifications regarding security constraint matching. In newer containers like GlassFish 7, if a <login-config> is present, the container may apply a stricter posture. If a resource (like /) isn't explicitly defined as "Unprotected", the container might fallback to requiring authentication because it doesn't want to leave "uncovered" resources exposed by accident.

2. Welcome File Interaction

When you access https://.../appName/, GlassFish performs an internal dispatch to a welcome file (e.g., index.html). In Jakarta EE 10, if this internal forward isn't clearly covered by a public constraint, the security engine may intercept it and trigger the BASIC auth requirement defined in your login-config.

---

Solutions

Solution 1: Explicitly Mark Root as Unprotected (Recommended)

The most robust way in Jakarta EE to ensure a path is public is to define a security constraint with NO <auth-constraint> element. This tells the container: "I know about this path, and I explicitly want it to be public."

<!-- 1. Mark Root and Static Assets as Public -->
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Public Area</web-resource-name>
        <url-pattern>/</url-pattern>
        <url-pattern>/index.html</url-pattern>
        <url-pattern>/css/*</url-pattern>
        <url-pattern>/js/*</url-pattern>
    </web-resource-collection>
    <!-- NO auth-constraint here makes this section public -->
</security-constraint>

<!-- 2. Protect OData Path -->
<security-constraint>
    <web-resource-collection>
        <web-resource-name>OData access Path</web-resource-name>
        <url-pattern>/odata/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>Users</role-name>
    </auth-constraint>
</security-constraint>

<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>file</realm-name>
</login-config>

<security-role>
    <role-name>Users</role-name>
</security-role>

Solution 2: Check your web.xml Namespace

When migrating to GlassFish 7, ensure your web.xml header is updated to the Jakarta EE 10 namespace. If you are still using the xmlns.jcp.org (Java EE) namespace, GlassFish may run in a compatibility mode that handles security constraints inconsistently.

Correct Jakarta EE 10 Header:

<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd"
         version="6.0">

Solution 3: Avoid deny-uncovered-http-methods

Check if your web.xml contains the <deny-uncovered-http-methods/> tag. In Servlet 6.0, this is an empty tag used to block any HTTP method not explicitly listed in a collection. If present, it can cause unexpected 403 or 401 errors on paths you thought were public. For a public root, ensure this is NOT applied to your root collection.

---

Verification

You can verify the fix using curl to see the HTTP headers:

# Should return 200 OK
curl -I https://10.0.0.30:8443/appName/

# Should return 401 Unauthorized
curl -I https://10.0.0.30:8443/appName/odata/

By being explicit about your public resources, you satisfy the stricter security requirements of Jakarta EE 10 while maintaining the expected user experience.