Spring Security
  1. Spring Security
  2. SEC-1094

Simplify J2eePreAuthenticatedProcessingFilter configuration by providing sensible defaults

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 M2
    • Component/s: Core
    • Labels:
      None

      Description

      I think that many people that use the J2eePreAuthenticatedProcessingFilter, will use it in combination with the J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource, with mappable roles read from web.xml. As such, I think it would make sense to make this the default behavior, or at least simplify configuration for this use case.

      To start with, I think configuration of WebXmlMappableAttributesRetriever and its superclass should be simplified. Instead of an InputStream (which requires fiddling around with ServletContextFactoryBean, ServletContextResource, etc), these classes should take a Spring Resource interface as input.

      Using automatic type conversion, one can then just inject a String pointing to the XML resource. Also, WebXmlMappableAttributesRetriever should default to '/WEB-INF/web.xml'. To do so, this class probably needs to implement ResourceLoaderAware in order to manually create a Resource object.

      Further on, in order to make WebXmlMappableAttributesRetriever the default mappable roles retriever in J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource, the latter needs to inject the current ResourceLoader into WebXmlMappableAttributesRetriever. As such, J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource would probably also need to implement ResourceLoaderAware.

      The same is true for J2eePreAuthenticatedProcessingFilter, which should inject the ResourceLoader into its default J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource.

      So in short; J2eePreAuthenticatedProcessingFilter defaults to J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource, which in turn defaults to WebXmlMappableAttributesRetriever, which in turn defaults to /WEB-INF/web.xml, which is loaded using the current (ServletContext)ResourceLoader that was injected via the ResourceLoaderAware interface.

        Activity

        Hide
        Luke Taylor added a comment -

        A patch would be useful

        Show
        Luke Taylor added a comment - A patch would be useful
        Hide
        Luke Taylor added a comment -

        I've removed the jaxen-based generic XML attribute retriever (YAGNI) and implemented the functionality directly in WebXmlMappableAttributesRetriever using simple DOM traversal. I've used the ResourceLoader to load "/WEB-INF/web.xml" as suggested. If someone wants a more esoteric attribute retrieval strategy then they can implement the interface, but I don't think we need something as complicated in the codebase. This also allows us to remove the XML dependencies from the (new) core module. Minimizing core dependencies is something we want to strive for in future.

        I've updated the sample and the configuration isn't too heavy, especially using nested beans, so I haven't gone for the suggestion where everything implements ResourceLoaderAware and passes the resource loader on to their default delegate. We may implement a namespace option for this in future and that can act as the basis for providing a simple default configuration.

        Show
        Luke Taylor added a comment - I've removed the jaxen-based generic XML attribute retriever (YAGNI) and implemented the functionality directly in WebXmlMappableAttributesRetriever using simple DOM traversal. I've used the ResourceLoader to load "/WEB-INF/web.xml" as suggested. If someone wants a more esoteric attribute retrieval strategy then they can implement the interface, but I don't think we need something as complicated in the codebase. This also allows us to remove the XML dependencies from the (new) core module. Minimizing core dependencies is something we want to strive for in future. I've updated the sample and the configuration isn't too heavy, especially using nested beans, so I haven't gone for the suggestion where everything implements ResourceLoaderAware and passes the resource loader on to their default delegate. We may implement a namespace option for this in future and that can act as the basis for providing a simple default configuration.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: