A user has recently found out that JNDIBasedSecurityManagement is ignoring the properties that are set in its configuration (security-jboss-beans.xml). In his particular case, he wanted a specific CallbackHandler to be used but, after setting the CallbackHandler class in the bean declaration, he continued to see the standard JBossCallbackHandler being used.

Some code to make things clear: first the bean declaration:

 <bean name="MyCallbackHandler" class="..."/>

 <bean name="JNDIBasedSecurityManagement"
 class="org.jboss.security.integration.JNDIBasedSecurityManagement">
 <property name="callbackHandler"><inject bean="MyCallbackHandler/></property>
 </bean>

Our problem is that the JNDIBasedSecurityManagement bean is instantiated not only by the MC runtime, but also by the SecurityDomainObjectFactory:

 private JNDIBasedSecurityManagement securityManagement = new JNDIBasedSecurityManagement();

So, whenever a lookup is performed, the security domain that is created by this factory completely ignores the configuration properties that have been set by the user.

One option to fix this would be to make the callbackHandler field static in JNDIBasedSecurityManagement, but then we would need to do that for every field that corresponds to a configuration property. The other option would be to make SecurityDomainObjectFactory an inner class of JNDIBasedSecMgmt. so that the former wouldn't need an explicit reference to the later, just like it is done in JaasSecurityManagerService.

Just as a reminder, we cannot inject the JNDISecurityManagement bean into the SecurityDomainObjectFactory because we don't control the instantiation of the object factory - it is done by the JVM.