The following issue occurs with spring-boot-starter 2.4.4 - The Scenario is a WildFly 22 or later with Elytron Java Security Manager activated - There are three artifacts deployed: earpart.ear, springclient.war and warpart.war. - All three are deployed in the same server. The wars are independent (not inside the ear). - The war files do contain a permissions.xml with all necessary grants, except permissions which rely on other artifacts content. springclient.war permissions and warpart.war permissions. Clear expectation is that each artifact does only need it's own permissions. - The org.springframework.jndi.JndiObjectFactoryBean in springclient.war looks up a EJB3 bean in EAR earpart.ear. service call and EJB service provider - A remote method in the EJB3 is called which remotely reads a file. The springclient.war needs permissions for this reading: 2021-03-23 18:05:15,688 DEBUG [org.wildfly.security.access] (default task-1) Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/content/earpart.ear/earpart-ejb.jar/net/unckel/jsm/showcase/earpart/resources/file2.properties" "read")" in code source "(vfs:/content/springclient.war/WEB-INF/lib/spring-aop-5.3.5.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.springclient.war" from Service Module Loader")

  • The same call out of warpart.war does not need any permission out of the remote call. javax.ws.rs.core.Application based client
  • Negative effect: The more permissions the ear needs, the more permissions are derived to the war. Two loosely coupled artifacts start to be close coupled by their permissions. Isolation is broken by design.

I have prepared a HelloWorld showcase for the issue: https://github.com/boris-unckel/jsmshowcase The readme explains what to build, deploy and test.

Expected behaviour: The proxy created and looked up by JndiObjectFactoryBean shall do the call successfully without need of permissions in the called EJB method in the same way as this is possible in a plain vanilla JavaEE war.

Comment From: snicoll

The reason why the @EJB call works is because of the thread-bound credentials and permissions that wildfly applies, but it does not for manual code like the one you've shared.

Unfortunately, supporting this use case with a recent version of the Spring Framework is not a priority so I am going to close this now. If someone provides a concrete arrangement that we could apply or document, we will consider it.