Authentication policies conflict

[tremalnaik]

Hello,
I'm using Jboss version 4.0.5.GA. My EJB application accepts 2 kinds of client:

1. Http clients users connect using a web browser and authenticate with respect to the policy "bitastarRealm" (see below for the details)
2. JaxRpc clients connect through (servlet-like) Web Services and authenticate on the policy "bitastarRealm_noDisable"

The authentication is performed against login/passwords saved in a common database. This means users will be able to connect through the web browser and the web services using the same login/password

The two policies are defined as follows:

<application-policy name = "bitastarRealm">
 <authentication>
 <login-module code = "com.bitaplus.bitastar.web.security.auth.jboss.JbossEjbLoginModule" flag = "required">
 <module-option name="hashAlgorithm">MD5</module-option>
 <module-option name="hashEncoding">base64</module-option>
 <module-option name="disableOnLoginFailure">true</module-option>
 </login-module>
 </authentication>
 </application-policy>

 <application-policy name = "bitastarRealm_noDisable">
 <authentication>
 <login-module code = "com.bitaplus.bitastar.web.security.auth.jboss.JbossEjbLoginModule" flag = "required">
 <module-option name="hashAlgorithm">MD5</module-option>
 <module-option name="hashEncoding">base64</module-option>
 <module-option name="disableOnLoginFailure">false</module-option>
 </login-module>
 </authentication>
 </application-policy>

The second one is set up s.t. the users are not disable despite of the number of failed log ons.

The problem is the authentication caching, the one defined through the parameter "DefaultCacheTimeout":

<attribute name="DefaultCacheTimeout">172800</attribute>

When the JaxRpc clients authenticate in the web tier everything is fine, they authenticate in the "bitastarRealm_noDisable" policy. But when the app accesses the business tier the same session is re-authenticated using the cached "bitastarRealm" policy, if the user previously logged in using the web browser. I can fix this temporarily setting the DefaultCacheTimeout equals to zero.
I'd like to find a better solution.

Do you have any suggestion?

Thanks,

[ragavgomatam]

can you post the

<security-domain>

element of jboss-web.xml and jboss.xml ?

[tremalnaik]

Sure, the jboss-web.xml security configuration for the application WAR is:

<security-domain flushOnSessionInvalidation="true">java:/jaas/bitastarRealm</security-domain>

the the jboss-web.xml security configuration for the WAR of the web services is:

<security-domain>java:/jaas/bitastarRealm_noDisable</security-domain>

and the application jboss.xml conf is

<jboss>
 <enterprise-beans>
 <session>
 <ejb-name>StarAccess</ejb-name>
 <jndi-name>StarAccess</jndi-name>
 </session>
 <session>
 <ejb-name>StarClientData</ejb-name>
 <jndi-name>StarClientData</jndi-name>
 <configuration-name>Secured Stateless SessionBean</configuration-name>
 </session>
 <session>
 <ejb-name>StarUserAdmin</ejb-name>
 <jndi-name>StarUserAdmin</jndi-name>
 <configuration-name>Secured Stateless SessionBean</configuration-name>
 </session>
 </enterprise-beans>
 <container-configurations>
 <container-configuration extends="Standard Stateless SessionBean">
 <container-name>Secured Stateless SessionBean</container-name>
 <security-domain>java:/jaas/bitastarRealm</security-domain>
 </container-configuration>
 </container-configurations>
</jboss>

The clients are authenticated by means of a EJB: the application Login Module invokes a method on the unsecured StarAccess (see above).

So, when the web services client accesses the main application web tier, the first time it is authenticated using the correct security domain (bitastarRealm_noDisable). But then, when the main application accesses the business tier cached domain informations, it uses the security domain configured in its own jboss.xml for the EJBs (bitastarRealm).

That is the problem, isn't it? Can you suggest any method to circumvent this? At the moment, as I told you, I simply disabled the caching (DefaultCacheTimeout set to 0), but this is not very satisfactory.

Thank you very much