Announcement Announcement Module
Collapse
No announcement yet.
switchUserProcessingFilter not authorizing based on securityEnforcementFilter Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • switchUserProcessingFilter not authorizing based on securityEnforcementFilter

    I'm implementing an app that uses acegi's securityEnforcementFilter as well as the switchUserProcessingFilter. I lock down an admin directory. However, the admin/j_acegi_switch_user is what I use for the switchUserProcessingFilter and if I type that url directly, it doesn't authorize the user so that it only lets in users with the proper role.

    So to be as clear as I can, I have a rule in the filterInvocationInterceptor of:
    /other/directories/admin/**=ROLE_ADMIN,ROLE_PREVIOUS_ADMINISTRATOR
    and the switch_user thing set to:
    /other/directories/admin/j_acegi_switch_user
    However a non-admin and non-previous_admin can call that j_acegi_switch_user directly and it even forwards to another admin page.
    It doesn't allow them to get to that other admin page directly but it does by means of the j_acegi_switch_user forward.

    Anyway, it's an odd problem and I wondered if there was a hole in the acegi stuff for the switch user stuff or if I'm just configuring it incorrectly. I understand that the securityEnforcementFilter needs to be referenced last in the list, but I thought that might be why something might happen - because the switch user filter comes before the securityEnforcementFilter?

    By the way, I'm using acegi version 0.9.

    Anyway, any thoughts?
    Last edited by jeromatron; Sep 27th, 2006, 05:00 PM. Reason: Specified the version of acegi

  • #2
    Half the problem fixed

    So I fixed part of the problem when I tried to upgrade to the latest version of acegi (1.0.1) as of right now. I noticed that I had halfway used the filterBeanToProxy, but I didn't remove the use of the securityEnforcementFilter in the security.xml file. So I got rid of that as I was converting the class paths to org. from net.sf. especially since securityEnforcementFilter doesn't exist in 1.0.1.

    However, with my filterInvocationInterceptor, I am using the convert-to-lowercase and the apache-ant syntax and it is giving an error on startup:
    Line appears to be malformed: CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT
    but they are on two lines in my editor (eclipse with xml buddy).

    It looks like this was something that was addressed in a bug found at
    http://opensource.atlassian.com/proj...browse/SEC-204
    but I don't know what else to do to separate the two lines. I saw a comment on that bug that indicates that he/she has the same problem and had to revert back to RC 2.

    I could go back to version 0.9.0, but it just seems a waste if we could upgrade at the same time as resolving this issue.

    Comment


    • #3
      Updated and works as before

      I guess I was lame and didn't update *both* the instances where there needs to be a newline between the convert-to-lowercase and the apache-ant syntax statements. I did it for the filterInvocationInterceptor but not for the filterChainProxy. I also saw that the securityEnforcementFilter changed so that you could simply put the filterInvocationInterceptor at the end of the filter list by itself and that I need to use an exceptionTranslationFilter with an entry point for the securityEnforcementFilter functionality instead, which I'm doing now.

      In any case, the original issue with the switchUserProcessingFilter remains. Everything else seems to follow the rules of the filterInvocationInterceptor except the j_acegi_switch_user, and then those things that it forwards to.

      So now I'm on version 1.0.1 and the switchUserProcessingFilter seems to be ignoring the rules defined in the filterInvocationInterceptor so that any authenticated user can switch users. Again, that shouldn't happen because I restrict access to an admin directory to those of role admin or previous_admin and I define the url of the j_acegi_switch_user to be in that directory.

      Am I missing something about the j_acegi_switch_user url definition?

      Thanks in advance.

      Comment


      • #4
        Has anyone experienced this specific problem before?

        Comment


        • #5
          I just tried downloading version 1.0.2 and trying it. I thought it might be fixed because the bug found at
          http://opensource.atlassian.com/proj...browse/SEC-339
          was fixed with 1.0.2. That describes a way with 1.0.1 that users could bypass the URL filter.
          Unfortunately, my problem still persists. I can perform
          j_acegi_switch_user?j_username=...
          with a non-admin user and it still does it even though the j_acegi_switch_user's path is in the url restricted area and the forwarding location of the switch user component is also in the restricted area - but it still forwards there.

          Comment


          • #6
            Hi jeromatron

            Yes. I can also replicate this issue with release 1.0.2

            protected url is e.g. using /j_acegi_switch_user=SUPERUSER

            Yet it is still possible to hand craft a URL such as

            http://localhost:9090/my-app/j_acegi...name=some.user

            Seems like a bug to me. I've raised it on JIRA.

            http://opensource.atlassian.com/proj...browse/SEC-376

            Comment


            • #7
              The issue is that SwitchUserProcessingFilter appears in FilterChainProxy before the FilterSecurityInterceptor. Move the SwitchUserProcessingFilter to AFTER the FilterSecurityInterceptor. Acegi reference guide section 6.1 has been updated and Jira issue is closed now.

              Comment

              Working...
              X