11:21 a.m.
Hi!
I've found a strange effect in the JBoss, which can be observed in all versions since
3.2.x until 4.0.5. Since I was not able to find any answer by reading forums, I've
decided to open a new topic.
We are developing a J2EE application using JBoss with embedded Tomcat as Web Container.
The Presentation Tier is Struts-based, the Business Tier is a bunch of stateless session
beans. For access control we use the standard Principal/Crendential model. The user
permissions come from a dabase, using the DatabaseServerLoginModule. Here is our security
domain:
<application-policy name = "dance-mc">
| <authentication>
| <login-module code = "org.jboss.security.ClientLoginModule"
| flag = "required">
| <module-option name =
"multi-threaded">true</module-option>
| <module-option name =
"password-stacking">useFirstPass</module-option>
| </login-module>
| <login-module code =
"org.jboss.security.auth.spi.DatabaseServerLoginModule"
| flag = "required">
| <module-option name =
"dsJndiName">java:/eis/jdbc/DanceUserDS</module-option>
| <module-option name = "principalsQuery">
| SELECT prpw FROM upr WHERE prid=?
| </module-option>
| <module-option name = "rolesQuery">
| SELECT rolid,'Roles' FROM ugrp_rol
| WHERE grpid IN (SELECT grpid FROM upr_grp WHERE prid=?)
| </module-option>
| <module-option name =
"unauthenticatedIdentity">nobody</module-option>
| <module-option name =
"password-stacking">useFirstPass</module-option>
| <!-- security options for password hashing -->
| <module-option name =
"hashAlgorithm">SHA</module-option>
| <module-option name =
"hashEncoding">base64</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
I think that there is nothing unusual in our approach. However, we are experiencing
strange effects when the cache of security credentials expires. An user using the
web-based GUI gets the following exception:
| SecurityException; nested exception is:
| javax.security.auth.login.LoginException: java.lang.NullPointerException
| at org.jboss.security.Util.createPasswordHash(Util.java:407)
| at
org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:415)
| at
org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:204)
| at sun.reflect.GeneratedMethodAccessor187.invoke(Unknown Source)
| 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:601)
| at
org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535)
| at
org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
| at
org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:211)
| at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:158)
| at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
| at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
| at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
| at org.jboss.ejb.Container.invoke(Container.java:954)
| at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source)
| at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at
org.jboss.invocation.local.LocalInvoker$MBeanServerAction.run(LocalInvoker.java:158)
| at java.security.AccessController.doPrivileged(Native Method)
| at
org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:177)
| at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
| at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209)
| at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195)
| at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
| at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
| at
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
| at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
| ...
|
However, if the user reloads the page in his browser, the error message disappears and
everything seems to work fine again. The user does not need to type his user name and
password again. It has definitely something to do with the credential cache, because
we've noticed that changing the DefaultCacheTimeout attribute of the
JaasSecurityManager directly defines the appearance time of this exception. Turning the
cache off by setting this attribute to 0 makes the usage of the application impossible,
because the exception appears on each query.
I would appreciate any help with this issue. An info whether it's a known bug/issue in
JBoss or something else would also help us a lot.
Thanks in advance,
Miran
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986630#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...