Configuration of Spring Security 3.0M1 Expression Handler - bug?

[pmularien]

Hopefully Luke can answer this

I am playing on the bleeding edge and doing research with Spring Sec 3.0M1. I'm trying to figure out if it's possible to write my own WebSecurityExpressionHandler class.

Looking at the source for HttpSecurityBeanDefinitionParser, it looks like I should be able to add the following within my <http> declaration:

<expression-handler ref="myBean"/>

... where myBean is a bean of the appropriate class. However, if I try this, I get a complaint from the SAX parser. Based on how the code is written, it looks like this is where it's expecting the element, however:

        if (useExpressions) {
            Element expressionHandlerElt = DomUtils.getChildElementByTagName(element, Elements.EXPRESSION_HANDLER);
            String expressionHandlerRef = expressionHandlerElt == null ? null : expressionHandlerElt.getAttribute("ref");

Is this a bug? Thanks in advance!

[pmularien]

As a follow-up, I was able to create my own WebSecurityExpressionHandler and SecurityExpressionRoot and wire these into the WebExpressionVoter. This let me create my own, custom SpEL methods. This was somewhat difficult than it had to be due to the way some of the classes in this area are written.

Given that what I did worked, do I need the expression-ref at all? It still seems like there's a dependency between the default WebSecurityExpressionHandler and the FIMDS that I can't fiddle with. Any thoughts are appreciated. Thanks!

[Luke Taylor]

Hi,

As you've worked out, the code is potentially able to support the use of an alternative expression handler but it isn't actually supported because the namespace doesn't include the element . The main focus on the expression-based stuff has been on method security since that is where it will be most useful and I'm not sure to what extent being able to customize the web-expression code is really of much practical benefit.

It would be useful if you could expand on statements like "the way some of the classes in this area are written", because we can't actually improve things unless you can be more specific about what the actual problems are. Also I'm not sure what you mean by "It still seems like there's a dependency between the default WebSecurityExpressionHandler and the FIMDS that I can't fiddle with".

[pmularien]

Hi Luke,

Thanks for your quick and thorough response. I'll try to respond in kind.

As you've worked out, the code is potentially able to support the use of an alternative expression handler but it isn't actually supported because the namespace doesn't include the element .

If this is as simple as adding the missing element to the schema / Relax NG spec, I'd say go for it. Basically because I disagree with the following...

The main focus on the expression-based stuff has been on method security since that is where it will be most useful and I'm not sure to what extent being able to customize the web-expression code is really of much practical benefit.

Actually, this is IMO one of the most exciting features of Spring Security 3! Bringing in the power of Spring 3 EL and being able to apply it to authorization criteria in a clear and concise manner is a great feature. It's especially great because it can be relatively easily extended (except the point I raise below) by providing my own implementation of SecurityContextRoot. If I do this, I can provide my own set of expressions that can be used to very precisely tie features of my application to authorization rules in configuration. Some possible examples off the top of my head: hasOrderedBefore() check before allowing a user to access the order history or order status page, geolocation filtering, device profile filtering (isMobileUser()), etc. There are lots of ways users could extend this functionality! Granted, there are other ways to implement almost all of what I described, but for some use cases, it feels very natural to be able to write custom authorization checks that tie into business rules.

It would be useful if you could expand on statements like "the way some of the classes in this area are written", because we can't actually improve things unless you can be more specific about what the actual problems are. Also I'm not sure what you mean by "It still seems like there's a dependency between the default WebSecurityExpressionHandler and the FIMDS that I can't fiddle with".

OK, I'll get specific

A couple points that made it hard to do what I wanted:

• WebSecurityExpressionRoot is package protected. This meant that I couldn't extend it (and retain the hasIpAddress functionality) and had to instead extend SecurityExpressionRoot. It would be convenient if this class were public.
• DefaultWebSecurityExpressionHandler directly instantiates WebSecurityExpressionRoot. This meant that I couldn't substitute my own implementation of SecurityExpressionRoot, but instead had to write my own WebSecurityExpressionHandler just to resolve this dependency to my custom class. It would be great if the SecurityExpressionRoot implementation were an injectable dependency.
• I don't know if this is possible with the way Spring 3 EL contexts are implemented, but it would be nice if, instead of requiring me to subclass SecurityExpressionRoot, SecurityExpressionRoot could be provided with a Collection (List?) of classes that provide additonal methods that could be bound into the EL context. This way I wouldn't have to touch any of these classes directly to expose custom EL methods used for access control.

Hope that clarifies things. The more I dig into Spring Sec 3, the more I appreciate the great OO design that you and Ben have done. I hope this input helps!

[Luke Taylor]

Hi Peter,

Thanks very much for your feedback. It is really very useful to have someone else trying this stuff out and looking at how it can be improved.

You are probably right about the web expression handler. I tend to be conservative about namespace additions and prefer to delay something rather than adding it and finding out later that I'd prefer to have done it differently. There are already quite a few things I wish I'd done differently and which I will change for 3.0, but there would be a lot more if I had added everything that was ever requested into the namespace . I will probably add the web handler soon, but again it is something that can be done at any point (even a minor release), and there are a lot of things I have to get in place for 3.0 which can't be changed afterwards. So I've been focussing on those. On the EL front, this has mainly been the method-security code, as it is much more complicated.

Don't forget that Spring EL allows you to do may things (e.g. calling static methods on classes) so you don't necessarily have to use a custom SecurityContextRoot to add extra functionality. Since you can call class methods like this I'm not sure that passing in a list of classes would be useful. However, a list of references to other beans in the app context might be a good idea, since that would allow you to query other services (potentially with database access etc).

Things like package-protected classes are again a result of a conservative approach and the fact that we like to be free to change and redesign code as much as possible (especially when it's still actively being developed ).

WebSecurityExpressionRoot could probably be made public without much impact, thus allowing its reuse. It is just more convenient from an internal maintenance perspective to realize immediately that it is only ever instantiated in one package.

DefaultWebSecurityExpressionHandler is a very small class, so it shouldn't be too onerous to implement WebSecurityExpressionHandler . It also injects the AuthenticationTrustResolver into the SecurityExpressionRoot. If the latter was a custom class this might not necessarily be possible (in theory the root object can be just about anything). Some factory mechanism would be required to generated the root object which starts to get quite complicated when you can just implement WebSecurityExpressionHandler directly. So I'd prefer to leave that as it is for the time being.

Come 3.1, we may have a clearer idea of how best to improve things but for now I'm not really sure how a lot of this will actually be used. People invariable come up with scenarios you don't expect and new ideas come from there. I hope you can see that a conservative (YAGNI) approach is usually the best starting point.

I am still trying to work out the best architecture for allowing much more than customizing the expression-handling when it comes to method security. The annotation handling code (Pre,Pose etc) is separate from the code that generates the attributes (the EL expressions), so in theory you don't need to use EL at all. So someone can plug in a custom external authorization engine. There is a test somewhere in the itest module that fires up a Jython script, for example, as a proof of concept. Ideally I would like to be able to support multiple mechanisms simultaneously, which is still something that needs to be clarified. So if you have some spare time one your hands ...

Thanks again for your input.

[split3]

Are there examples or documentation of customizing the security expression used via SpEL?

For instance if I want to add a custom SpEL expression for checking security like

@PostAuthorize("customAuthCheck(returnObject)")
public Object findBySomeField(String somefield);

What exactly is the best practice for providing this extended behavior in Spring Security 3.

Thanks and great work on all the kicking additions to Spring Security 3 looking great!

Daniel

[Luke Taylor]

One option is to code your "customCheck" in Java as a static method and call it through the expression. At some point in the future we may add some way of configuring beans from the context that you want to add in and have available, but that will probably be in a future release.

I also added a section on EL support to the reference manual recently.

[split3]

Would the other option be to just extend WebSecurityExpressionRoot and add the various additional checks and configure it as mentioned in this thread?

Because I will need to inject various @Service for the security check to meet the business requirements so using static method just feels awkward in this context.

Thanks for the quick reply

[Luke Taylor]

WebSecurityExoressionRoot only applies to the web part. If you are securing methods, as in the example you gave, then you would have to customize the method expression handling. The approach is similar though. Have a look at the Contacts sample code which customizes method security to add the ACL support.

[namero999]

This is a very interesting topic.

Please take a look at my reply to this thread. I think that using the very flexible <sec:authorize access=""/> with expressions is the way to go, but still I need to access some beans to perform my security checks.

So I ask you if this could be ok for my needs.

- Declare WebSecurityExpressionRoot as Bean, so that I can inject my dependencies
- Extend WebSecurityExpressionRoot adding method to perform my checks (use injected dependecies)
- Use <sec:authorize access=""/> calling the new methods

Of course I just have to try to find out if this works, but I'm also interested to hear from you if this is the correct way to achieve this.

Thank you for your work on SpringSecurity, a very neat piece of code!