Spring Security
  1. Spring Security
  2. SEC-1185

MethodInvocationPrivilegeEvaluator.isAllowed() Returns True When Authentication is null

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 M2
    • Component/s: Core
    • Labels:
      None

      Description

      The 2.0.4 MethodInvocationPrivilegeEvaluator has the following code block in it:

      if ((authentication == null) || (authentication.getAuthorities() == null)

      (authentication.getAuthorities().length == 0)) {
      return false;
      }

      But I'm getting true returned when authentication is null.

      I'll upload a project containing a AuthorizationServiceTest. The test that shows this is:
      testAuthorization

      The test looks like this:

      public void testAuthorization() throws Exception
      {
      Authentication authentication =
      SecurityContextHolder.
      getContext().
      getAuthentication();

      assertNull(authentication);

      boolean authenticationNotFoundExceptionTriggered = false;

      try

      { needsAuthorizedMethod.returnString(); }

      catch (AuthenticationCredentialsNotFoundException e)

      { authenticationNotFoundExceptionTriggered = true; }

      assertTrue(authenticationNotFoundExceptionTriggered);

      boolean isAllowedResult =
      authorizationService.
      isCallable(
      needsAuthorizedMethod,
      "returnString");

      assertTrue(isAllowedResult);
      }

        Activity

        Hide
        Ole Ersoy added a comment -

        Oh Oh...I just realized "No naming convention" breaks the way we implemented the AuthorizationService here:

        http://jira.springsource.org/browse/SEC-1198

        Since the service has a list of secured object ID's and we use these IDs to lookup the corresponding security interceptors.

        Is there some other way to know which security interceptor corresponds to a specific bean, so that we can create Map<Object, MethodSecurityInterceptor>?

        Show
        Ole Ersoy added a comment - Oh Oh...I just realized "No naming convention" breaks the way we implemented the AuthorizationService here: http://jira.springsource.org/browse/SEC-1198 Since the service has a list of secured object ID's and we use these IDs to lookup the corresponding security interceptors. Is there some other way to know which security interceptor corresponds to a specific bean, so that we can create Map<Object, MethodSecurityInterceptor>?
        Hide
        Luke Taylor added a comment -

        Either use the <global-method-security /> namespace element to apply security (then there is only one interceptor). Otherwise you can configure one explicitly and apply it using Spring AOP, or BeanNameAutoProxyCreator. See SEC-1204 for an example. To use Spring's AOP namespace, you could do something like

        <aop:config>
        <aop:pointcut id='targetMethods' expression='execution(* org.springframework.security.TargetObject.*(..))'/>
        <aop:advisor advice-ref='securityInterceptor' pointcut-ref='targetMethods' />
        </aop:config>

        Show
        Luke Taylor added a comment - Either use the <global-method-security /> namespace element to apply security (then there is only one interceptor). Otherwise you can configure one explicitly and apply it using Spring AOP, or BeanNameAutoProxyCreator. See SEC-1204 for an example. To use Spring's AOP namespace, you could do something like <aop:config> <aop:pointcut id='targetMethods' expression='execution(* org.springframework.security.TargetObject.*(..))'/> <aop:advisor advice-ref='securityInterceptor' pointcut-ref='targetMethods' /> </aop:config>
        Hide
        Ole Ersoy added a comment -

        Thanks for pointing out these options. I think once we upgrade I may miss the simplicity of just adding the <security:intercept-methods> elements directly to the bean definitions. Would it conflict with other implementation efficiencies / designs if the naming convention is kept?

        Show
        Ole Ersoy added a comment - Thanks for pointing out these options. I think once we upgrade I may miss the simplicity of just adding the <security:intercept-methods> elements directly to the bean definitions. Would it conflict with other implementation efficiencies / designs if the naming convention is kept?
        Hide
        Luke Taylor added a comment -

        The interceptor name will be decided by Spring's AbstractInterceptorDrivenBeanDefinitionDecorator, so you can use the convention from there to work it out.

        Show
        Luke Taylor added a comment - The interceptor name will be decided by Spring's AbstractInterceptorDrivenBeanDefinitionDecorator, so you can use the convention from there to work it out.
        Hide
        Ole Ersoy added a comment -

        Super - Thanks!

        Show
        Ole Ersoy added a comment - Super - Thanks!

          People

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

            Dates

            • Created:
              Updated:
              Resolved: