Announcement Announcement Module
Collapse
No announcement yet.
How to break @Secured Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to break @Secured

    Hi,

    How would you break @Secured annotations in such a way that it appears as if it's being ignored completely? And how would you verify this in some other way besides system testing? Using for example logging.

    You see my @Secured annotations appear to be ignored completely when calling from controllers to the service side and I've been browsing dozens of forum threads on things to check and always the result is the same: they don't work. So this time I'm taking another approach: how would I break them in a way that leads to the exact same end result.

    At this point even long shot suggestions are welcome.

    Environment:
    Maven is used for building.
    I'm using 3.1.0.RELEASE for all Spring libraries.
    I'm not using aspectJ, the spring beans appear to be proxied with CGLib.
    The methods where the @Secured is used are all public.
    Security annotations are enabled: <security:global-method-security access-decision-manager-ref="accessDecisionManager" secured-annotations="enabled" />
    I include the rest of the Spring configuration from the servlet (including the "secured" beans).

  • #2
    1) Check that you aren't scanning for the same components twice (i.e. if your security is in the ContextLoaderListener this doesn't get added to components in the DispatcherServlet and vice-versa)
    2) Make sure that your global-method-security is defined in the same context as the components you want to secure else it won't work.

    Comment


    • #3
      Authorization

      This problem is a long term battle and I've been trying to solve it every now and then. I took a look at the logs and thought that the method security is actually working, it's just authorizing people it shouldn't. Am I correct? The logs:
      2013-02-11 09:12:49,052 [btpool0-4] DEBUG btpool0-4 org.springframework.security.access.intercept.aopa lliance.MethodSecurityInterceptor - Secure object: ReflectiveMethodInvocation: public java.lang.String com.waco.mc.service.report.ReportServiceImpl.getEx portReportsToXml(java.util.List,com.waco.mc.domain .user.User); target is of class [com.waco.mc.service.report.ReportServiceImpl]; Attributes: [AUTH_REPORT_VIEW, AUTH_REPORT_EXPORTXML]
      2013-02-11 09:12:49,053 [btpool0-4] DEBUG btpool0-4 org.springframework.security.access.intercept.aopa lliance.MethodSecurityInterceptor - Previously Authenticated: org.springframework.security.authentication.Userna mePasswordAuthenticationToken@d8ada90f: Principal: org.springframework.security.core.userdetails.User @6a68e03: Username: usern; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: AUTH_GROUP_CREATE,AUTH_GROUP_DELETE,AUTH_GROUP_EDI T,AUTH_LICENSE_ACTIVATE,AUTH_LICENSE_CONSUME,AUTH_ LICENSE_EXPORT,AUTH_LICENSE_VIEW,AUTH_PROCESS_MANA GEMENT,AUTH_REPORT_CREATE,AUTH_REPORT_DELETE,AUTH_ REPORT_EMAIL,AUTH_REPORT_IMPORT,AUTH_REPORT_PRINT, AUTH_REPORT_VIEW,AUTH_STATISTICS_STATISTICS,AUTH_S YSTEM_CONFIGURATION,AUTH_SYSTEM_LOGIN,AUTH_USER_CR EATE,AUTH_USER_DELETE,AUTH_USER_EDIT,AUTH_USER_LIS T,AUTH_USER_ROLE_CREATE,AUTH_USER_ROLE_DELETE,AUTH _USER_ROLE_EDIT,AUTH_WIDGET_CUSTOMIZE_WIDGETS; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.We bAuthenticationDetails@957e: RemoteIpAddress: 127.0.0.1; SessionId: null; Granted Authorities: AUTH_GROUP_CREATE, AUTH_GROUP_DELETE, AUTH_GROUP_EDIT, AUTH_LICENSE_ACTIVATE, AUTH_LICENSE_CONSUME, AUTH_LICENSE_EXPORT, AUTH_LICENSE_VIEW, AUTH_PROCESS_MANAGEMENT, AUTH_REPORT_CREATE, AUTH_REPORT_DELETE, AUTH_REPORT_EMAIL, AUTH_REPORT_IMPORT, AUTH_REPORT_PRINT, AUTH_REPORT_VIEW, AUTH_STATISTICS_STATISTICS, AUTH_SYSTEM_CONFIGURATION, AUTH_SYSTEM_LOGIN, AUTH_USER_CREATE, AUTH_USER_DELETE, AUTH_USER_EDIT, AUTH_USER_LIST, AUTH_USER_ROLE_CREATE, AUTH_USER_ROLE_DELETE, AUTH_USER_ROLE_EDIT, AUTH_WIDGET_CUSTOMIZE_WIDGETS
      2013-02-11 09:12:49,053 [btpool0-4] DEBUG btpool0-4 org.springframework.security.access.vote.Affirmati veBased - Voter: org.springframework.security.access.vote.RoleVoter @2e51779, returned: 1
      2013-02-11 09:12:49,053 [btpool0-4] DEBUG btpool0-4 org.springframework.security.access.intercept.aopa lliance.MethodSecurityInterceptor - Authorization successful
      2013-02-11 09:12:49,053 [btpool0-4] DEBUG btpool0-4 org.springframework.security.access.intercept.aopa lliance.MethodSecurityInterceptor - RunAsManager did not change Authentication object

      Comment


      • #4
        Originally posted by Marten Deinum View Post
        1) Check that you aren't scanning for the same components twice (i.e. if your security is in the ContextLoaderListener this doesn't get added to components in the DispatcherServlet and vice-versa)
        2) Make sure that your global-method-security is defined in the same context as the components you want to secure else it won't work.
        I'm not sure on how to check the first one, but the second should be easy: define bean with the same ID in several places. If there's no errors, the contexts are separate. Correct?

        Comment


        • #5
          Originally posted by Marten Deinum View Post
          1) Check that you aren't scanning for the same components twice (i.e. if your security is in the ContextLoaderListener this doesn't get added to components in the DispatcherServlet and vice-versa)
          2) Make sure that your global-method-security is defined in the same context as the components you want to secure else it won't work.
          I just noticed the following in the logs:
          Code:
          org.springframework.security.access.vote.AffirmativeBased - Voter: org.springframework.security.access.vote.RoleVoter@4d051922, returned: 1
          To me that sounds like the @Secured annotation is actually working. Therefore the bean and the global-method-security definitions must be in the same context. The problem is then somewhere else?

          Comment

          Working...
          X