NPE in DefaultPolicy

[ctabin]

Hello,

We are trying to update to GlassFish 8 / Payara 7 (embedded-all) but we hit a NPE with the following stack in exousia in both of them:

java.lang.NullPointerException: Cannot invoke "jakarta.security.jacc.PolicyConfiguration.getExcludedPermissions()" because the return value of "jakarta.security.jacc.PolicyConfigurationFactory.getPolicyConfiguration()" is
 null
        at org.glassfish.exousia.modules.def.DefaultPolicy.isExcluded(DefaultPolicy.java:50)
        at jakarta.security.jacc.Policy.implies(Policy.java:53)
        at org.glassfish.exousia.AuthorizationService.checkPermission(AuthorizationService.java:550)
        at org.glassfish.exousia.AuthorizationService.checkWebRoleRefPermission(AuthorizationService.java:463)
        at com.sun.enterprise.security.ee.authorization.WebAuthorizationManagerService.hasRoleRefPermission(WebAuthorizationManagerService.java:436)
        at com.sun.web.security.RealmAdapter.hasRole(RealmAdapter.java:1104)
        at org.apache.catalina.connector.Request.isUserInRole(Request.java:2772)
        at org.apache.catalina.connector.RequestFacade.isUserInRole(RequestFacade.java:814)
        ...

The user is authenticated in a jdbc realm (with httpServletRequest.login(...)) and then we are retrieving the roles with httpServletRequest.isUserInRole(...) and the following NPE shows up. Those calls are done in a remote EJB that is deployed with glassfish/payara-embedded-all.

The JACC provider is configured like this in the domain.xml:

<jacc-provider policy-provider="org.glassfish.exousia.modules.def.DefaultPolicy" name="default" policy-configuration-factory-provider="org.glassfish.exousia.modules.def.DefaultPolicyConfigurationFactory" />

Note that we don't have this exception with GlassFish 7 / Payara 6.

Thanks & best regards,
Cedric

[arjantijms]

Thanks for the report. As a first sanity check, does the same or similar code work on the server variants of both these products?

[ctabin]

Hi @arjantijms,

Thanks for coming back on this issue so quickly.

Not sure about what you're asking but I can affirm that it is working with the exact same code in GlassFish 7 and Payara 6 (we just updated the version and adapted the configuration in domain.xml with the JACC policy).

We are using a custom LoginModule (custom Realm with a fallback to the JDBCRealm) to authenticate a JWT token, but AFAIK this doesn't seem to cause any problem (no change between the version). It works perfectly with a LocalBean (WAR inside EAR) but fails with a @Remote bean (we copy the interface in a WAR deployed on the same glassfish-embedded-all instance and access it with a lookup through InitialContext).

For now, I'm trying to make a reproducer but failed to reproduce the issue (the login in the remote war is working). So I guess we are using some strange pattern with multiple login/logout (like here) but I was unable to properly understand if yet. Maybe you can have a guess ? :-)

[arjantijms]

Not sure about what you're asking

Well, we have GlassFish "server", which is the version you startup and then deploy a war to, and we have GlassFish embedded, which can be started programmatically from java.

Server is the one you download e.g. here https://github.com/eclipse-ee4j/glassfish/releases/download/7.1.0/glassfish-7.1.0.zip

Since you mentioned "embedded-all", I wondered if the problem only happens with embedded or also with server. There are some different code paths in the two, and the class loader for modules are different.

Maybe you can have a guess ? :-)

This type of problem is almost always caused by the context ID (an ID representing the current application) not being set. This ID is set whenever during request processing the code goes from runtime code to application code, and then sets this ID as a thread local.

The thread from which you call isUserInRole likely doesn't have this ID set, or it was set but is cleared. I don't know for sure of course, but that is the most likely cause. A reproducer would absolutely be super handy to fix this :)

[ctabin]

@arjantijms I'm almost there with a reproducer ! Although I do not have the NPE, I have a completely strange behavior where the role is lost. Here is the code snippet:

@WebServlet(urlPatterns = {"/"})
public class EntryPointServlet extends HttpServlet {

    @EJB
    private SimpleBeanRemote remoteBean;
    
    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        String user = req.getParameter("user");
        String password = req.getParameter("password");
        
        req.login(user, password);
        
        System.out.println("## USER: "+req.isUserInRole("USER"));
        remoteBean.getLeaf(0);
        System.out.println("## USER: "+req.isUserInRole("USER"));
        
        req.logout();
    }
}

Output is:

## USER: true
## USER: false

As one can see, the role is lost after a remote EJB call, which is... unexpected at last :-)

Here is a reproducer:

git clone git@github.com:ctabin/gf-test.git
cd gf-test
git checkout glassfish-8-remote-ejb-role-lost
mvn clean package

Hope it helps. I'll continue to try to find out how to get the NPE, but I should not be too far away.

[arjantijms]

I'm going to take a look. EJB remote requests have their own distinct path into the runtime (distinct from HTTP), and that path is not often tested.

Let me know when you have the reproducer available :)