Ruud Senden(Migrated from SEC-1095) said:
Most namespace parsers call ConfigUtils.registerProviderManagerIfNecessary() if they configure beans that require access to an authentication manager. However, GlobalMethodSecurityBeanDefinitionParser doesn’t do this, which may result in exceptions when loading the Spring context.
One use case where this happens is when using hierarchical contexts, where most security configuration (like HTTP filters and such) is done in the (child) web application context, and you want to use the sec:global-method-security element (using a default authentication manager) in some parent context. In this case, a default (or custom) authentication manager is only registered in the child context, to which the parent context doesn’t have access.
In general, I also think that the provider manager should be configurable on all namespace elements that require an authentication manager. This would allow to share a single authentication manager (defined in the most upper context) from multiple child contexts, for example for authentication purposes from multiple web applications in a single ear, or for (re-)authentication purposes from AbstractSecurityInterceptor.
Finally, I never really understood why an authentication manager is always required in authorization-related classes (e.g. AbstractSecurityInterceptor). This is only required if alwaysReauthenticate==true or if the authentication object is not yet authenticated. If you don’t use these features (I’ve never seen use for them in a pre-authenticated scenario), then it makes no sense to require an authentication manager. Making the authentication manager optional would greatly simplify dependency management, especially in the case of hierarchical contexts.
Luke Taylor said:
I've added the call to GlobalMethodSecurityBDP.
Issues such as modifying the namespace, refactoring AbstractSecurityInterceptor and so on are separate issues. I don't think we are currently at the stage where these are justified to facilitate namespace usage. Refactoring of AbstractSecurityInterceptor is something I would like to do, but it will have to wait till a future release. Likewise the ability to define the AuthenticationManager used within a particular part of the namespace. That's also something that will need careful consideration since the registration of an internal instance and the assumption of its availability is currently a core part of the design.
Since the use of the authentication manager is changing because of other issues, I'm reopening this issue as there's a possibility it may superseded. The registerProviderManagerIfNecessary call may be removed completely in favour of assuming the registration of a specific instance using the element.
This should be superseded by SEC-1196. It is now required that the user specify the element somewhere in order to register the AuthenticationManager and providers. So you can choose which context it will appear in. The ConfigUtils class has been deleted.
This issue is related to #1444