Spring Security
  1. Spring Security
  2. SEC-1400

Support composition of intercept-url lists

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.0.2
    • Component/s: Namespace
    • Labels:
      None

      Description

      I would like the security namespace to be able to specify lists of <url-interceptor> elements separately from the <http> element, and then wire them into the active <http> element depending some configuration property.

      This is illustrative of the kind of thing I would like to be able to do:

      <sec:http>
      <sec:intercept-url pattern="/images/*" filters="none" />
      <sec:include-intercept-url-list ref="$

      {param}

      " />
      <sec:intercept-url pattern="/*.gif" filters="none" />
      ...
      </sec:http>

      ... and in a different file ...

      <sec:intercept-url-list id="some-id">
      <sec:intercept-url pattern="/annotea/admin/*" access="ROLE_ADMIN" />
      <sec:include-intercept-url-list ref="some-other-id" />
      </sec:intercept-url-list>

      ... and in a Java properties file

      param=some-id

      Ideally, intercept url lists would be configurable to the same extent that regular spring beans are configurable; e.g. using <bean:import>, <bean:alias>, the new Spring EL, PropertyPlaceholderConfigurer and so on. But I'd be happy with anything that allows me to factor out the interceptor lists and compose them under the control of the System properties.

        Activity

        Hide
        Luke Taylor added a comment -

        I think if you want something like this, you're going to have to write your own customization code. It is not something that is likely to be a common requirement. You could use individual FilterSecurityInterceptor instances (and select them based on your requirments) or use your own custom namespace.

        Show
        Luke Taylor added a comment - I think if you want something like this, you're going to have to write your own customization code. It is not something that is likely to be a common requirement. You could use individual FilterSecurityInterceptor instances (and select them based on your requirments) or use your own custom namespace.
        Hide
        Stephen Crawley added a comment -

        The first alternative that you suggest amounts to abandoning the use of the security namespace, and distributing SpringSecurity wiring files that rely solely on generic Spring bean wiring syntax. I could probably cope with that, but I don't think that people deploying / tailoring my software would appreciate this ... especially since the current SS documentation no longer covers that approach to SS wiring to the extent that would required by a SS newbie.

        The second alternative amounts to creating a semi-private fork of the SS config module. That's going to create a long term maintenance problem for me/my successors, not to mention version conflict problems for downstream folks who may need to mix and match with official Spring / SpringSecurity modules; e.g. pulled in by Maven.

        Instead of those, suppose that I developed some patches that implemented the minimal extensions I need. Would you consider reviewing those patches, and once they were in a satisfactory state, integrating them back into the main SS codebase? Are there any prerequisites that would need to be fulfilled before you could accept contributions?

        (BTW, I'm also working on Shibboleth authentication and other SS extensions that I'd eventually like to contribute.)

        Show
        Stephen Crawley added a comment - The first alternative that you suggest amounts to abandoning the use of the security namespace, and distributing SpringSecurity wiring files that rely solely on generic Spring bean wiring syntax. I could probably cope with that, but I don't think that people deploying / tailoring my software would appreciate this ... especially since the current SS documentation no longer covers that approach to SS wiring to the extent that would required by a SS newbie. The second alternative amounts to creating a semi-private fork of the SS config module. That's going to create a long term maintenance problem for me/my successors, not to mention version conflict problems for downstream folks who may need to mix and match with official Spring / SpringSecurity modules; e.g. pulled in by Maven. Instead of those, suppose that I developed some patches that implemented the minimal extensions I need. Would you consider reviewing those patches, and once they were in a satisfactory state, integrating them back into the main SS codebase? Are there any prerequisites that would need to be fulfilled before you could accept contributions? (BTW, I'm also working on Shibboleth authentication and other SS extensions that I'd eventually like to contribute.)
        Hide
        Luke Taylor added a comment -

        You wouldn't have to stop using the namespace or fork the codebase.

        There no reason why you can't configure the namespace to allow all requests by default and insert a separately configured FilterSecurityInterceptor at the end of the stack, selected as you've defined. There are probably other ways you could do it too, possibly replacing the default interceptor by using a PostProcessor, or using re-injecting it with a custom FilterInvocationDefinitionSource. Or you could define your own separate namespace which is independent of the security one, but takes account of the beans it creates and satisfies your specific configuration needs. This is not uncommon amongst Spring power users. It could be responsible for adding a BeanPostProcessor to the app context, for example.

        The point is that this is just one out of many corner cases. There are lots of different ways to configure things and it doesn't make sense for the namespace to support them all. Apart from that it would be very difficult to implement (and maintain) what you are suggesting using namespace parsing. It is much easier to deal with the parsed beans in a post-processor and make modifications to the configuration at that point.

        Show
        Luke Taylor added a comment - You wouldn't have to stop using the namespace or fork the codebase. There no reason why you can't configure the namespace to allow all requests by default and insert a separately configured FilterSecurityInterceptor at the end of the stack, selected as you've defined. There are probably other ways you could do it too, possibly replacing the default interceptor by using a PostProcessor, or using re-injecting it with a custom FilterInvocationDefinitionSource. Or you could define your own separate namespace which is independent of the security one, but takes account of the beans it creates and satisfies your specific configuration needs. This is not uncommon amongst Spring power users. It could be responsible for adding a BeanPostProcessor to the app context, for example. The point is that this is just one out of many corner cases. There are lots of different ways to configure things and it doesn't make sense for the namespace to support them all. Apart from that it would be very difficult to implement (and maintain) what you are suggesting using namespace parsing. It is much easier to deal with the parsed beans in a post-processor and make modifications to the configuration at that point.
        Hide
        Luke Taylor added a comment -

        Regarding shibboleth integration, that would be an interesting submission for the Security extensions project. Contributors need to sign an agreement (similar to an Apache-style one, I believe).

        Show
        Luke Taylor added a comment - Regarding shibboleth integration, that would be an interesting submission for the Security extensions project. Contributors need to sign an agreement (similar to an Apache-style one, I believe).
        Hide
        Stephen Crawley added a comment -

        I'm trying your suggestion about adding an extra FilterSecurityInterceptor.

        Show
        Stephen Crawley added a comment - I'm trying your suggestion about adding an extra FilterSecurityInterceptor.
        Hide
        Stephen Crawley added a comment -

        Well it works, though there are a couple of gotchas:

        1) It is not possible use the filter="none" form of an <intercept-url> in a separate FilterSecurityInterceptor. That means I cannot use config switch tricks to select the URL patterns for which the security filters are bypassed.

        2) In order to wire the FilterSecurityInterceptor, you have to set the "authenticationManager" and "accessDecisionManager" properties. The authenticationManager I can name using the "alias" attribute on my <authentication-manager> element, but there is no advertised id or alias for the AccessDecisionManager that the <http> namespace creates by default. So I have to explicitly configure and wire in an AccessDecisionManager bean that is identical to the one I'd use by default.

        Show
        Stephen Crawley added a comment - Well it works, though there are a couple of gotchas: 1) It is not possible use the filter="none" form of an <intercept-url> in a separate FilterSecurityInterceptor. That means I cannot use config switch tricks to select the URL patterns for which the security filters are bypassed. 2) In order to wire the FilterSecurityInterceptor, you have to set the "authenticationManager" and "accessDecisionManager" properties. The authenticationManager I can name using the "alias" attribute on my <authentication-manager> element, but there is no advertised id or alias for the AccessDecisionManager that the <http> namespace creates by default. So I have to explicitly configure and wire in an AccessDecisionManager bean that is identical to the one I'd use by default.
        Hide
        Luke Taylor added a comment -

        There are always other ways to do things. For example, you can write your own bypass filter and select that in DelegatingFilterProxy rather than "springSecurityFilterChain", having it skip the FilterChainProxy for URLs you don't want to be secured but direct everything else through it.

        Show
        Luke Taylor added a comment - There are always other ways to do things. For example, you can write your own bypass filter and select that in DelegatingFilterProxy rather than "springSecurityFilterChain", having it skip the FilterChainProxy for URLs you don't want to be secured but direct everything else through it.
        Hide
        Enrico Giurin added a comment -

        Even I'd be interested to have this feature, which is to have the list of intercept-url in a separated file, out of the http section. I would like to put the list of the intercept-url in the application file while having the general configuration section, in another product configuration file to be reused in many application.

        Show
        Enrico Giurin added a comment - Even I'd be interested to have this feature, which is to have the list of intercept-url in a separated file, out of the http section. I would like to put the list of the intercept-url in the application file while having the general configuration section, in another product configuration file to be reused in many application.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: