The multiple AuthenticationManagers is because we have 3 different providers, but we cannot just register them all in one manager because it can't just spin through them all (user Ids are not unique) and attempt a valid login...
which is what causes the need to have multiple AuthenticationManagers, which in turn causes the need to have multiple SecurityInterceptors. I was trying to simplify the spring-security-config by only having 1 AuthenticationProcessingFilter and 1 FilterSecurityInterceptor, which could be injected with the 3 AuthenticationManagers and dynamically switched.
You are correct in that I would have an issue knowing which one to return from my getAuthenticationManager() method without any contextual information. I actually discovered that during the time I opened the issue and the time you commented on it and started down a slightly different path. I think the way I would need to do it is to override the beforeInvocationMethod(), which has a FilterInvocation and thus the Request object (for contextual), and then set the AuthenticationManager before delegating back to the super impl. However, I found another problem that prevents that from working:
FilterSecurityInterceptor line 106: http://static.springframework.org/spring-security/site/xref/index.html
It forces the "super" method to be called:
InterceptorStatusToken token = super.beforeInvocation(fi);
I don't think we can delegate to the AccessDecisionManager because I am trying to intercept the "authentication" calls.
I understand your point about not being extension points and would welcome any other suggestions. Worst case we could just configure 3 of everything and then make sure all the FilterChainProxy configuration handles them correctly, but it was starting to get a bit messy.
Anyway, I think that the line 106 of FilterSecurityInterceptor is still a bug, since that does seem like a valid extension point??...even if we end up throwing my craziness away...
and thanks Luke!