SecurityFlowExecutionListener not compatible with SpEL expressions in Spring Security 3 [SWF-1508] #692
Labels
in: integration
status: waiting-for-feedback
We need additional information before we can continue
type: bug
Koen Serneels opened SWF-1508 and commented
When SecurityFlowExecutionListener is supplied with an AccessDecisionManager, the authorization decision is left over to the AccessDecisionManager.
However, when using Spring Security with SpEL (<security:http use-expressions="true">) a WebExpressionVoter is registered with the AccessDecisionManager.
At the moment, this AccessDecisionVoter is generified and explicitly wants a FilterInvocation as parameter.
The interface of AccessDecisionManager is not adjusted, and still takes Object as parameter (which is a bit strange).
public class WebExpressionVoter implements AccessDecisionVoter<FilterInvocation> {
private SecurityExpressionHandler<FilterInvocation> expressionHandler = new DefaultWebSecurityExpressionHandler();
What happens is that the SecurityFlowExecutionListener passes along a TransitionDefinition, FlowDefinition or StateDefinition to the AccessDecisionManager.
Which is legal, since its contract is Object.
In combination with the WebExpressionVoter this will result in a ClassCastException, as a FilterInvocation is expected.
With the RoleVoter there is no problem, as the type there is <Object>. The role voter also doesn't seem to do anything with the object by default.
Also, wiring in the AccessDecisionManager is a bit of a pain, since it is created by the Spring Security NS configiration and has no 'normal' bean id.
Maybe this could be solved by implemeting a PostProcessor or ApplicationContextAware.
(or it could be solved at Spring Security level making the AccessDecisionManager available under a normal bean name)
The easiest workaround I found at the moment is not to define the AccessDecisionManager, so that the "else" is used an a RoleVoter is created by the SecurityFlowExecutionListener.
This means that it is not possible to use SpEL in flow security.
At that point it is not possible to use 'fullyAuthenticated' or other advantages the SpEL way offers.
The other workaround is a custom SecurityFlowExecutionListener.
I made a first effort to write something, that appears to be working, see attachment.
Affects: 2.3.0
Attachments:
Issue Links:
3 votes, 6 watchers
The text was updated successfully, but these errors were encountered: