Spring Security
  1. Spring Security
  2. SEC-1322

Spring Security documentation does not explain precedence of <intercept-url> elements

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.5, 3.0.0.RC2
    • Fix Version/s: 3.0.0
    • Component/s: Docs and Website
    • Labels:
      None

      Description

      The SpringSecurity reference does not explain how the <intercept-url> elements are mapped to filters. Fore example:

      • It should describe the significance the order of these elements.
      • It should mention that an element with a "method='...'" takes precedence over any element with out this attribute.
      • It should mention that the "filter='none'" causes all other attributes to be silently ignored ... including "requires-channel".
      • It should say whether "access='ROLE_A,ROLE_B'" means "ROLE_A or ROLE_B" or "ROLE_A and ROLE_B".
      • It should explain why "access='' requires_channel='https'" does not work.
      • It should document "ROLE_ANONYMOUS" and "IS_AUTHENTICATED_ANONYMOUSLY", what they (respectively) mean, where/how they should be used.

        Activity

        Hide
        Luke Taylor added a comment -
        • It should describe the significance the order of these elements.

        The namespace chapter already explains that they are evaluated in order and hence the most specific matches must go at the top. I've expanded the description a bit.

        • It should mention that an element with a "method='...'" takes precedence over any element with out this attribute.

        Added to the namespace chapter.

        • It should mention that the "filter='none'" causes all other attributes to be silently ignored ... including "requires-channel".

        I've expanded the part where it describes the bypassing of the security filter chain to make this more obvious.

        • It should say whether "access='ROLE_A,ROLE_B'" means "ROLE_A or ROLE_B" or "ROLE_A and ROLE_B".

        It doesn't necessarily mean either. I've added a basic description of the default configuration (where the attributes are effectively roles, any of which will grant access). Also added links to the appropriate sections which expand on authorization and customization of the AccessDecisionManager.

        • It should explain why "access='' requires_channel='https'" does not work.

        Please expand on "does not work". Fails to parse? Fails to start up? Application runs, but doesn't produce the expected behaviour?

        • It should document "ROLE_ANONYMOUS" and "IS_AUTHENTICATED_ANONYMOUSLY", what they (respectively) mean, where/how they should be used.

        This is already documented in the chapter on "Anonymous Authentication" and linked from the namespace chapter. I've also added a cross-reference to information on the AuthenticatedVoter.

        Show
        Luke Taylor added a comment - It should describe the significance the order of these elements. The namespace chapter already explains that they are evaluated in order and hence the most specific matches must go at the top. I've expanded the description a bit. It should mention that an element with a "method='...'" takes precedence over any element with out this attribute. Added to the namespace chapter. It should mention that the "filter='none'" causes all other attributes to be silently ignored ... including "requires-channel". I've expanded the part where it describes the bypassing of the security filter chain to make this more obvious. It should say whether "access='ROLE_A,ROLE_B'" means "ROLE_A or ROLE_B" or "ROLE_A and ROLE_B". It doesn't necessarily mean either. I've added a basic description of the default configuration (where the attributes are effectively roles, any of which will grant access). Also added links to the appropriate sections which expand on authorization and customization of the AccessDecisionManager. It should explain why "access='' requires_channel='https'" does not work. Please expand on "does not work". Fails to parse? Fails to start up? Application runs, but doesn't produce the expected behaviour? It should document "ROLE_ANONYMOUS" and "IS_AUTHENTICATED_ANONYMOUSLY", what they (respectively) mean, where/how they should be used. This is already documented in the chapter on "Anonymous Authentication" and linked from the namespace chapter. I've also added a cross-reference to information on the AuthenticatedVoter.
        Hide
        Stephen Crawley added a comment -

        Thanks for your work on this.

        I was scanning the diffs and I noticed this new sentence in respect to <intercept-url> with/without a methods attribute:

        "For a pattern defined both with and without a method, the method-specific match will take precedence regardless of ordering."

        This only talks about a single pattern. In fact (at least for 2.5.6), the method-specific match takes precedence even when there are multiple patterns. For example

        pattern="/*.html" method="GET"

        takes precedence over

        pattern="/specific.html"

        Re: * It should explain why "access='' requires_channel='https'" does not work.

        I was trying to express a rule like "pattern='/secure/' requires_channel='https'" and separate rules to specify the access for subpatterns of '/secure/'. IIRC, it objected to the missing access attribute, so I added "access=''", which (to my surprise) removed all access. Perhaps I'm just expecting too much from <intercept-url> ...

        Finally, re: "ROLE_ANONYMOUS" versus "IS_AUTHENTICATED_ANONYMOUSLY". I've now read the material in the anonymous authentication section, and (perhaps I'm dumb but ...) it doesn't answer my questions in terms that a SpringSecurity newbie (like me) would understand; e.g. in practical terms, what is the difference between the two approaches, and why would I use one or the other?

        Show
        Stephen Crawley added a comment - Thanks for your work on this. I was scanning the diffs and I noticed this new sentence in respect to <intercept-url> with/without a methods attribute: "For a pattern defined both with and without a method, the method-specific match will take precedence regardless of ordering." This only talks about a single pattern. In fact (at least for 2.5.6), the method-specific match takes precedence even when there are multiple patterns. For example pattern="/*.html" method="GET" takes precedence over pattern="/specific.html" Re: * It should explain why "access='' requires_channel='https'" does not work. I was trying to express a rule like "pattern='/secure/ ' requires_channel='https'" and separate rules to specify the access for subpatterns of '/secure/ '. IIRC, it objected to the missing access attribute, so I added "access=''", which (to my surprise) removed all access. Perhaps I'm just expecting too much from <intercept-url> ... Finally, re: "ROLE_ANONYMOUS" versus "IS_AUTHENTICATED_ANONYMOUSLY". I've now read the material in the anonymous authentication section, and (perhaps I'm dumb but ...) it doesn't answer my questions in terms that a SpringSecurity newbie (like me) would understand; e.g. in practical terms, what is the difference between the two approaches, and why would I use one or the other?
        Hide
        Luke Taylor added a comment - - edited

        Ok, I've changed the sentence on the matching to "If a request matches multiple patterns, the method-specific match will take precedence regardless of ordering."

        The intercept-url elements are parsed separately for the channel (HTTP/S) and security interceptor requirements, so it should be possible to have one without an access attribute. The schema doesn't require it and the parser will treat an empty and missing attribute identically. I just tried it with the sample app and it worked OK. If can come up with a specific example where this is rejected, please open a separate issue and I will look into it.

        The anonymous access issue is partly historical. Anonymous tokens were introduced initially (i.e. ROLE_ANONYMOUS) which would allow you to use a "secure-by-defaul" configurations with specific exceptions. At a later stage the AuthenticatedVoter was introduced to allow you to differentiate between different levels of authentication - anonyous, remember-me and fully-authenticated (i.e. logged in during the current session). I've added an extra bit to the anonymous chapter to explain that they are the same unless you require the extra functionality offered by the AuthenticatedVoter.

        Thanks for your feedback, BTW. It is useful to get someone (who has obviously actually spent some time looking at the docs) picking up on specific trouble spots.

        Show
        Luke Taylor added a comment - - edited Ok, I've changed the sentence on the matching to "If a request matches multiple patterns, the method-specific match will take precedence regardless of ordering." The intercept-url elements are parsed separately for the channel (HTTP/S) and security interceptor requirements, so it should be possible to have one without an access attribute. The schema doesn't require it and the parser will treat an empty and missing attribute identically. I just tried it with the sample app and it worked OK. If can come up with a specific example where this is rejected, please open a separate issue and I will look into it. The anonymous access issue is partly historical. Anonymous tokens were introduced initially (i.e. ROLE_ANONYMOUS) which would allow you to use a "secure-by-defaul" configurations with specific exceptions. At a later stage the AuthenticatedVoter was introduced to allow you to differentiate between different levels of authentication - anonyous, remember-me and fully-authenticated (i.e. logged in during the current session). I've added an extra bit to the anonymous chapter to explain that they are the same unless you require the extra functionality offered by the AuthenticatedVoter. Thanks for your feedback, BTW. It is useful to get someone (who has obviously actually spent some time looking at the docs) picking up on specific trouble spots.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: