Multiple ear deployment throws "No username found in principals"

[GowriSankar Narayanaswamy]

We have to deploy two instances of same application (.ear files) running in a single jboss server (so that we can use virtual hosting later). We are using jboss 4.0.3 sp1.

Our application has:
. Local EJBs
. Struts accessing the EJBs
. JSPs
using Database authentication.

Each application has its own database, data sources and unique jndi names configured to be accessed properly by the respective application war. Each application is deployed using its own context root. (http://localhost:8080/first and http://localhost:8080/second).

If we deploy application "first" only, it works fine (using say, first.ear). If we deploy application "second" (using say, second.ear) only, it works fine. If we deploy both, then "first" only works. We get a "No username found in principals" exception for second.

We stopped jboss server and renamed "first.ear" to "xyz.ear". Now when we restarted jboss, now "second.ear" works fine. and we get the "no username found in principals" error for the xyz.ear.

We googled and identified that the client login module of Jboss caches user credentials and use it on subsequent invokations of EJB. And both of our deployments use the client login module.

Code snippet from login.conf for one application is below:

-- login-conf.xml start here..
<application-policy name="first">
<authentication>
<login-module code="org.jboss.security.ClientLoginModule" flag="required" />
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="dsJndiName">
java:/firstDS
</module-option>
<module-option name="principalsQuery">
SELECT iu.hash FROM users iu WHERE IsActive=1 and iu.EmailID=?
</module-option>
<module-option name="rolesQuery">
<!-- query trimmed here.. assume it returns a valid set of roles -->
SELECT baa.Roles,'Roles' FROM OurRoles baa
WHERE baa.IsActive=1 and baa.EmailID=?
</module-option>
</login-module>
</authentication>
</application-policy>
-- login-conf.xml ends here..

Configuration code snippet for the other application will be similar to the one above with changes in dsName and policy name.

Is it like client-login is hard-coded in jboss and only one instance of application (first-come-first-served logic) applied ?

Can someone let us know if there are any pointers for us to proceed ?

Thanks in advance

[Jaikiran Pai]

Can you post the entire exception stacktrace?

[GowriSankar Narayanaswamy]

Here is the stack trace i get in jboss console for the second application after invoking the ejb.

21:11:29,574 ERROR [[action]] Servlet.service() for servlet action threw exception
javax.ejb.AccessLocalException: SecurityException; CausedByException is:
No matching username found in Principals
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:366)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:125)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:613)
at org.jboss.ejb.Container.invoke(Container.java:894)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:344)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:118)
at $Proxy284.create(Unknown Source)
at com.xyz.AdminLookup.getXyzUserSessionBean(Unknown Source)
at com.xyz.ui.xyzLogonAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
javax.security.auth.login.FailedLoginException: No matching username found in Principals
at org.jboss.security.auth.spi.DatabaseServerLoginModule.getUsersPassword(DatabaseServerLoginModule.java:126)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:182)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:572)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:506)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:315)
at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:196)
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:120)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:121)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:613)
at org.jboss.ejb.Container.invoke(Container.java:894)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:344)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:118)
at $Proxy284.create(Unknown Source)
at com.xyz.AdminLookup.getXyZUserSessionBean(Unknown Source)
at com.xyz.ui.xyzLogonAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
[ October 31, 2007: Message edited by: GowriSankar Narayanaswamy ]

[GowriSankar Narayanaswamy]

GowriSankar Narayanaswamy wrote:
Here is the stack trace i get in jboss console for the second application after invoking the ejb.
21:11:29,574 ERROR [[action]] Servlet.service() for servlet action threw exception
javax.ejb.AccessLocalException: SecurityException; CausedByException is:
No matching username found in Principals
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:366)

Well, we did four changes:
1. We had to upgrade to Jboss 5.1.0, when we ported our application to FreeBSD. [Guess this upgrade has nothing to do with the issue]
2. When we did that, we found that there is a property in jboss that can be used to tell the class loader to treat classes in each ear file separately. It is in JBOSS_HOME/server/default/deployers/ear-deployer-jboss-beans.xml. [We replaced "default" with our installation specific name, "demo", so that it becomes JBOSS_HOME/server/demo/deployers/ear-deployer-jboss-beans.xml]. Last section in the file normally has:
<bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">
<property name="isolated">false</property>
</bean>
We changed it to
<bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">
<property name="isolated">true</property>
</bean>

3. We made changes to login-config.xml, so that it chains all authentication requests from one EAR's authentication to another.
4. We made application specific changes, which were earlier in global context to .EAR specific (e.g., data source name, JNDI name, etc.,) [I'm pretty sure, this had only minor impact and we knew that this has to be done, anyway].