Rob Winch (Migrated from SEC-1937) said:
When multiple elements are defined the second one overrides the first one. The only indication is WARNING logged.
WARN org.springframework.beans.factory.parsing.FailFastProblemReporter - Configuration problem: Overriding globally registered AuthenticationManager
It would be better to either fail or better yet support multiple elements. The work around is to create only one AuthenticationManager with the namespace and to create other AuthenticationManager's with standard Spring bean configuration.
Luke Taylor said:
You shouldn't need to use Spring beans. If you don't specify an ID, you will override the "default" instance. That's pretty much the way standard Spring beans work. In the referenced thread, the user is specifying an alias, rather than an ID, so that doesn't create a separate instance. Again that's the way normal bean instances work, so I'm not sure we should deviate from that.
Rob Winch said:
Thanks for pointing this out. I had missed the alias vs the id attribute differences. I assume this will fix the issue in which case the issue can be closed.
Using Spring Security 3.1.4 and this still does not work without using Spring tag. Using "alias" does nothing.
Here is my configuration using the namespace and "id" attribute where the last "formAuthManager" overrides "basicAuthManager":
<!-- Setup for BASIC auth for web services -->
<security:http pattern="/rs/external/**" authentication-manager-ref="basicAuthManager" create-session="stateless">
<!-- Setup FORM basic auth -->
<security:form-login login-page="/login.jsp" authentication-success-handler-ref="successHandler" authentication-failure-handler-ref="failureHandler" />
<!-- In memory auth manager -->
<security:user name="username" password="password" authorities="ROLE_somerole" />
<security:authentication-provider ref="drdAuthenticationProvider" />
I should point out that if I use the Spring namespace to define the "basicAuthManager" everything works fine.
backofthecup - this seems to work just fine for me. Make sure you use id and not alias (alias is just adding another pointer to the bean). I pushed out a commit that demonstrates this works properly. If you are still having problems please produce a test case.
PS I should clarify. If you are still having issues, please create a new JIRA and attach a test case. Without a test case the JIRA will likely be rejected since there is a test demonstrating it works.
Enoque Duarte said:
Tested on 3.1.0 and 3.1.4, dont work on any, simply ignores one manager
(using id's to identify them)
As mentioned in the comments, I was unable to reproduce this and have a test case that demonstrates it works. If you feel this is an issue, please create a new JIRA with a sample of it failing attached to it.
Filip Hanik said:
I just ran into this with the saml login server at cloudfoundry
and modifying one authentication-manager to use id attribute while leaving the other to use ldap, for some reason worked.
I'll work on an isolated test case, I just wanted to second the other commenters.
This was in spring security 3.1.3.RELEASE
Thanks for the response fhanik. Keep in mind that specifying an alias WILL make it so that the AuthenticationManager gets overridden if another AuthenticationManager is specified. If you want multiple, you need to use id (as your commit does). Alias just means whatever the AuthenticationManager is also allow me to refer to it using the specified alias. So if another AuthenticationManager is specified the alias will refer to the second AuthenticationManager that is encountered. Using the id states that you want both values.
Thanks @rwinch for the response. I understand the logic now, and see how the override works, and why it was causing confusion in my setup. When using an ID, it didn't override the default anonymous manager, but when using an alias, it overrode it and authentication got delegated down to the wrong manager. It was a configuration error on my part.