Sri Hanuman (Migrated from SEC-1320) said:
Fix for SEC-760 causes another bug. If you deploy JAAS login module (application policy) with application, as a service archive, JaasAuthenticationProvider does not see it because of an config reset, which was a fix in SEC-760.
If line "Configuration.getConfiguration().refresh();" is removed everything works ok.
Luke Taylor said:
I'm not quite clear on why this is a bug. Could you explain in more detail why you think the problem lies with the JAAS provider, rather than the use of the service archive (which is JBoss-specific)? As far as I can see it is reasonable for the Provider to perform a refresh of the configuration when the application is started. Could you also pleas explain what the actual issue is that prevents it being seen because of the refresh?.
Note that you can always customize the behaviour by overriding the "configureJaas()" method, which is the intention of having that hook method there to start with.
Sri Hanuman said:
Hm, have not drilled into code deep enough, because of the lack of time, to see the core reason why it does not see jaas login defined in sar. We were using acegi 1.0.6 and switched to spring 2.0.5, when this arose. If you do not refresh, line added in SEC-760, everything works ok (provider can see jaas login module), and if you do provider does not see it and exception arises.
Well, if you think that is a feature, than just close this issue. I just wanted to warn about this....
I dunno about a feature :), but I don't have any experience of using the JAAS provider in this context so it's difficult to know what's going on. I could add a flag to the provider called "refreshJaasConfigurationOnStartup" which would allow you to disable the refresh if required.
And a bit more elaboration. JaasProvider can always see jaas application policies, which were defined application server wide in conf directory. Before JaasProvider refreshes configuration, it can also see application policies which were defined in application (service archive, application wide) - after the refresh it does not see them. Hope this helps...
Sorry about the future part, it sounded much better in my head than when I wrote it....
Calling Configuration.getConfiguration().refresh() is part of the JAAS api, and in theory could be done in some other context (completely external to Spring Security), so it seems to me more likely that this is an issue with the environment or with JAAS itself. Presumably the refresh method is there to allow changes to be made at runtime and the existing unmodified configuration information shouldn't be lost when it's called.
jboss has an option to dynamically deploy/load new jaas domain. Upon refresh it will clear those jaas configurations loaded from apps and just load the default. So it seems there is another understanding of refresh as this is done on purpose by design. It seems easier to give jaasprovider "a flag", than to change jboss architecture. Because in current state they just can not work together in before mentioned case. We have, of course, resolved this by not refreshing, and it seemed a proper thing to do, to go here and post.
startService() adds application configuration to appConfig
clears all application configurations
This is all the data I can give you and I think all the data you need to make a decision. Its on you mate...
I added the flag to the class, so if refreshConfigurationOnStartup=false, the call to Configuration.refresh() won't be made.