Spring Security
  1. Spring Security
  2. SEC-1937

Support multiple <authentication-manager> elements

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.1.0
    • Fix Version/s: 3.1.1
    • Component/s: Namespace
    • Labels:
      None

      Description

      When multiple <authentication-manager> 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 <authentication-manager> elements. The work around is to create only one AuthenticationManager with the namespace and to create other AuthenticationManager's with standard Spring bean configuration.

        Activity

        Hide
        Enoque Duarte added a comment -

        Tested on 3.1.0 and 3.1.4, dont work on any, simply ignores one manager

        (using id's to identify them)

        Show
        Enoque Duarte added a comment - Tested on 3.1.0 and 3.1.4, dont work on any, simply ignores one manager (using id's to identify them)
        Hide
        Rob Winch added a comment -

        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.

        Show
        Rob Winch added a comment - 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.
        Hide
        Filip Hanik added a comment -

        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

        Show
        Filip Hanik added a comment - 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
        Hide
        Rob Winch added a comment -

        Thanks for the response Filip Hanik. 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.

        Show
        Rob Winch added a comment - Thanks for the response Filip Hanik . 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.
        Hide
        Filip Hanik added a comment -

        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.

        Show
        Filip Hanik added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Rob Winch
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: