Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SecurityFlowExecutionListener not compatible with SpEL expressions in Spring Security 3 [SWF-1508] #692

Open
spring-operator opened this issue Jan 20, 2012 · 2 comments
Assignees
Labels
in: integration status: waiting-for-feedback We need additional information before we can continue type: bug

Comments

@spring-operator
Copy link
Contributor

spring-operator commented Jan 20, 2012

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();

public int vote(Authentication authentication, FilterInvocation fi, Collection<ConfigAttribute> attributes) {

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

@spring-operator
Copy link
Contributor Author

Rossen Stoyanchev commented

Thanks for reporting. If you can put together a minimal project that demonstrates the issue that would be of great help. See these instructions.

@spring-operator
Copy link
Contributor Author

Neil McGuigan commented

Having same bug w Spring security 4.0.2.RELEASE and Web Flow 2.4.2.RELEASE

Created an AffirmativeBased AccessDecisionManager so I can use hierarchical roles. Set this on the SecurityFlowExecutionListener

Get ClassCastException: org.springframework.webflow.engine.Flow cannot be cast to org.springframework.security.web.FilterInvocation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: integration status: waiting-for-feedback We need additional information before we can continue type: bug
Projects
None yet
Development

No branches or pull requests

2 participants