SEC-1937: Support multiple <authentication-manager> elements #2163

Closed
spring-issuemaster opened this Issue Mar 7, 2012 · 11 comments

Comments

Projects
None yet
1 participant

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.

Eric said:

Using Spring Security 3.1.4 and this still does not work without using Spring tag. Using "alias" does nothing.

Eric said:

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">

... omitted
<security:http-basic />
/security:http

<!-- Setup FORM basic auth -->
<security:http authentication-manager-ref="formAuthManager">

...omitted
<security:form-login login-page="/login.jsp" authentication-success-handler-ref="successHandler" authentication-failure-handler-ref="failureHandler" />

</security:http>


<!--  In memory auth manager -->
<security:authentication-manager id="basicAuthManager">
    <security:authentication-provider user-service-ref="myUserService"/>
</security:authentication-manager>

<security:user-service id="myUserService">
    <security:user name="username" password="password" authorities="ROLE_somerole" />
</security:user-service>

<security:authentication-manager id="formAuthManager">
    <security:authentication-provider ref="drdAuthenticationProvider" />
</security:authentication-manager>

I should point out that if I use the Spring namespace to define the "basicAuthManager" everything works fine.

Rob Winch said:

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.

Rob Winch said:

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)

Rob Winch said:

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
https://github.com/fhanik/login-server/commit/3c9579a5b38f3495917e68d6777563fbef178eb3
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

Rob Winch said:

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.

Filip Hanik said:

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.

spring-issuemaster added this to the 3.1.1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment