Spring Security
  1. Spring Security
  2. SEC-1196

Change use of <authentication-manager> to actually register the global ProviderManager instance

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0 M1
    • Fix Version/s: 3.0.0 M2
    • Component/s: Namespace
    • Labels:
      None

      Description

      For better tooling support, it would make sense to follow the approach used in SEC-1186 for filters and apply the same logic to authentication providers. <authentication-manager> would register the ProviderManager and the contents would be parsed as a list of providers and references to provider beans.

      <authentication-manager>
      <authentication-provider ref="someProvider" />
      </authentication-manager>

      etc. This would improve the context by keeping all providers together and ordered and would allow for proper tooling support. The bean decoration approach could still be partially supported by generating a list of providers from the decorated beans. A post-processor would check the context for the presence of the standard AuthenticationManager and if one wasn't found, it would be created from the provider list. Otherwise an error would be reported and a message produced suggesting that provider elements be placed within the <authentication-manager /> element. The internal AuthenticationManagers produced in SEC-1195 would delegate to the one created by this element (using the standard bean name). It could thus be placed anywhere in the application context

        Issue Links

          Activity

          Hide
          Luke Taylor added a comment -

          The suggested changes have been made, with the exception that the original approach (using the decorator element, <custom-authentiction-provider />) is no longer supported. It is now required that the user include the <authentication-manager /> element somewhere in their configuration (thus fixing the location of the AuthenticationManager bean, in terms of which application context it appears in). The <authentication-provider /> (or <ldap-authenticaton-provider />) elements must be children of the <authentication-manager />.

          Show
          Luke Taylor added a comment - The suggested changes have been made, with the exception that the original approach (using the decorator element, <custom-authentiction-provider />) is no longer supported. It is now required that the user include the <authentication-manager /> element somewhere in their configuration (thus fixing the location of the AuthenticationManager bean, in terms of which application context it appears in). The <authentication-provider /> (or <ldap-authenticaton-provider />) elements must be children of the <authentication-manager />.

            People

            • Assignee:
              Luke Taylor
              Reporter:
              Luke Taylor
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: