switchUserProcessingFilter not authorizing based on securityEnforcementFilter

[jeromatron]

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?

[jeromatron]

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.

[jeromatron]

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.

[jeromatron]

Has anyone experienced this specific problem before?

[jeromatron]

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.

[badlydrawntoy]

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

[Vishal Puri]

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.