Spring Security
  1. Spring Security
  2. SEC-1768

Using the "*" wildcard in intercept-method does not include implemented interfaces

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.5
    • Fix Version/s: 3.0.6, 3.1.0.RC3
    • Component/s: CAS, Core
    • Labels:
      None
    • Environment:
      All

      Description

      Created on behalf of client, with the following use case:

      1. Bean is secured via the intercept-methods tag.
      2. The method attributed of the protect tag is set to "*"
      3. Bean implements an interface and is annotated with @Transactional.
      4. None of the methods on the interface are protected unless the interface is explicitly defined in the method attribute.

      In this case only the methods on the bean, not the interface are secured when the method is "". They feel that in addition to the methods declared on the bean, all implemented interface methods should also be secured when the "" is specified for the method.

      Attached is a sample test case illustrating the behavior.

        Activity

        Hide
        Luke Taylor added a comment -

        The problem here is essentially that two types of Spring AOP proxying are being used - the traditional ProxyFactoryBean approach (which intercept-methods uses) and the auto-proxying approach used by tx:annotation-driven. It's generally a good idea to stick to one or the other, rather than mixing them, otherwise you can end up with two proxies for the same target bean.

        I've added a fix to AbstractMethodSecurityMetadataSource to use AopProxyUtils.ultimateTargetClass to test for the case where the security interceptor has been applied to a proxy when it is identifying the target class of the invocation. A better solution might be to use <global-method-security /> as an alternative:

        <sec:global-method-security>
        <sec:protect-pointcut expression='execution(* com.bsb.incubator.interceptor..(..))' access='ROLE_USER'/>
        </sec:global-method-security>

        as this will result in a single proxy being used, which is more compatible with the <aop:config /> approach..

        Show
        Luke Taylor added a comment - The problem here is essentially that two types of Spring AOP proxying are being used - the traditional ProxyFactoryBean approach (which intercept-methods uses) and the auto-proxying approach used by tx:annotation-driven. It's generally a good idea to stick to one or the other, rather than mixing them, otherwise you can end up with two proxies for the same target bean. I've added a fix to AbstractMethodSecurityMetadataSource to use AopProxyUtils.ultimateTargetClass to test for the case where the security interceptor has been applied to a proxy when it is identifying the target class of the invocation. A better solution might be to use <global-method-security /> as an alternative: <sec:global-method-security> <sec:protect-pointcut expression='execution(* com.bsb.incubator.interceptor. . (..))' access='ROLE_USER'/> </sec:global-method-security> as this will result in a single proxy being used, which is more compatible with the <aop:config /> approach..

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Greg Nieman
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: