• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Multiple ear deployment throws "No username found in principals"

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can you post the entire exception stacktrace?
 
GowriSankar Narayanaswamy
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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].
 
reply
    Bookmark Topic Watch Topic
  • New Topic