FilterSecurityInterceptor and request parameters

[mhowell]

Hi all,

I'm evaluating Acegi for use in a new web project. I've taken a look at the reference docs, and there is an example of using the FilterSecurityInterceptor to perform authorization based on URL regular expressions.

This would almost work for us, except that we need to be able to make authorizaton decisions based on a combination of the URL and some request parameters. Is this possible out of the box? Can you just include some query string elements in the URL regex expressions that are used to configure the FilterSecurityInterceptor? If so, what would happen with parameters contained in a POST? Or is there some other way to do this entirely?

Thanks,

Morley Howell

[Ben Alex]

Your FilterInvocationDefinitionSource implementation is responsible for returning the configuration attributes applicable to any web request being handled by FilterSecurityInterceptor.

The base implementations use the FilterInvocation class' getRequestUrl() method for the comparison. This method looks as follows:

    public String getRequestUrl() {
        String pathInfo = getHttpRequest().getPathInfo();
        String queryString = getHttpRequest().getQueryString();

        return getHttpRequest().getServletPath()
        + ((pathInfo == null) ? "" : pathInfo)
        + ((queryString == null) ? "" : ("?" + queryString));
    }

As such your GET requests will contain the query string. Your POST requests will not, so I wouldn't look to this approach as a solution.

I mentioned the interface as you can write your own FilterInvocationDefinitionSource which iterates POST parameters and considers these in the request. Alternatively, it sounds like you're trying to achieve a little too much with just web request security. Would it be better using the MethodSecurityInterceptor, and/or ACL security for your use case? If you describe your use case I might be able to offer more specific suggestions.

[mhowell]

Ben,

Thanks for the reply. I'm starting to wonder the same thing you are - web request security may not work terribly well.

I'm working on a project that's a combination portal and content management system. Each page in the system is aggregated from components which show different types of content and/or navigation. Users can be granted rights to edit the information displayed by the components, based on the location in the site (ie. the page) and possibly the type of content (ie. the type of component). So when a user is logged in, we need to be able to do the following:

- when displaying a component, check to see if the user has edit rights, and if so, then display an 'Edit' button
- when someone hits an 'Edit' button, we need to double-check that they have edit rights before actually displaying the component's edit mode
- once in edit mode, when the user hits the 'Save' button, we need to double-check again to make sure that the user has edit rights before actually saving the new information

Our thought was to use the URL to indicate the page to display, and to use request parameters to identify a specific component on the page and whether the user had pressed Edit or Save. Thus if we could use both the URL and parameters with the web request security, we could accomplish the 2nd and 3rd requirements above, and we could use the taglib to accomplish the 1st.

Thanks,

Morley

[Ben Alex]

I think the ACL security is more what you need. Each folder and component path in the CMS represented as an object. eg: /welcome/weatherComponent. You can then return a list of authorites, with different authorities for each permission, such as create, write etc. There is an ACL taglib which will make integration simple, and there is a new ACL voter which can enforce the permission at time of method invocation. eg your WeatherController has an "edit" option, which delegates to WeatherManager.edit(Object) and the ACL security would be enforced at that point (at the time of accessing your services layer, not your web layer).

[Ben Alex]

I should mention these new features are only in CVS, so you'll need to check it out and refer to the Contacts Sample which demonstrates them quite well.

[mhowell]

Ben,

What you're saying makes a lot of sense.

Does this mean though that we need to explicitly call out to the security framework from various points in our code? For example, if we had WeatherManager.save(Object), would we write code inside this method that would call out to the security framework to check that the user has write access to the given object? Or is there some kind of Spring/AOP voodoo that we can do to avoid this dependency?

We may someday want to take advantage of the CAS integration capabilities of Acegi. Is there anything in the approach that you've described that would prevent us from doing that in the future?

Also, given that the ACL stuff is only in CVS, how stable is it? Any idea when there might be a release (0.8?) that includes this capability?

One last thing ... does 'Acegi' mean anything, and how do you pronounce it!?!?

Thanks,

Morley

[Ben Alex]

Some details of Acegi's name can be found at http://forum.springframework.org/showthread.php?t=9928.

There are no problems with CAS integration. Acegi Security goes to great lengths to ensure authentication is pluggable and does not impact authorization in any way.

Your services layer would be protected by AOP magic. :-) Seriously, the improved ACL capabilities are applied via "configuration attribute" declarations on the MethodSecurityInterceptor. These will prevent the method being called if the user does not hold the required ACL permission. Indeed there is even support to modify the returned object, such as filtering out unauthorised Collection elements or throwing an AccessDeniedException.

The ACL support is pretty robust. The AclManager has been around since 0.6. The MethodSecurityInterceptor is absolutely a core class and has existed forever. The "after secure object invocation" is new (maybe three weeks old), but it will be in 0.7 and it is comprehensively used in the Contacts sample application. As such there isn't much truly new code there - only perhaps four classes - so it's fairly reasonable to use it out of CVS in your particular case as ACL is the most appropriate way to handle your requirements.

Official release 0.7 is expected within two weeks. I've just been so busy lately and I have a fairly long list of polishing to complete, along with a refactoring of how the filter security interceptor stores its configuration attributes and better transparent remoting integration for some of the web services protocols.

[mhowell]

Ben,

Thanks for all your help! It looks like Acegi does everything that we need it to do, and more. Based on this thread, I'd say there's also solid support behind it, which is just as important in my mind. I think my evaluation is done. Thanks again!

Morley