|
Added flow security interceptor, much in the same way as the MethodSecurityInterceptor. Works using the same concepts (ObjectDefinitionSource implementation specific for WebFlow flows, states and events).
Configuration as follows: <bean class="....FowSecurityInterceptor"> <property name="flowDefinitionSource"> <value> FLOW_ID.state.STATE_ID=authority1 FLOW_ID=authority1,authority2 FLOW_ID.event.EVENT_ID=authority1 </value> </property> </bean> Ideas for flow-level security constraints defined with the flow definition itself:
Flow security: <flow> <attribute name="requiredAuthorities" value="LOGGED_IN,CHANGE_PASSWORD"/> .... </flow> State security: <flow> <start-state idref="whatev"> <view-state id="whatev" view="form.jsp"> <attribute name="requiredAuthorities" value="LOGGED_IN,CHANGE_PASSWORD"/> </view-state> .... </flow> We use the event based security quite a lot, so you would have to add it to transitions as well!
<flow> <view-state id="whatev" view="form.jsp"/> <transition on="someEvent" to="bla"> <attribute name="requiredAuthorities" value="LOGGED_IN,CHANGE_PASSWORD"/> </flow> However what I like about the current solution is that it is quite non-intrusive, it is simply a matter of configuration. Also we tend to have most of our security-configuration stuff inside 1 xml file. So we have 1 file defining our method, url and flow security. Now the security would be scattered around in the different flow definitions. For a presentation I created a demo for this demo I made some minor improvements in the initial code I also removed the JDK 1.5 constructs to be compatible again with jdk 1.3 and up. I also made it a maven2 project so building it and installing it in a local repository should be a breeze :).
Suppose I wanted to protect an event on a state. With this solution how do I do that?
Does anybody know whether this patch of Keith will be integrated in Acegi or Spring?
I wrote a version of this interceptor using static flowDefinitions (plain type) and regular expressions. If anybody is interested in I would share it with the community - but first I have to make a code review ;) Example configuration: <bean id="flowSecurityInterceptor" class="org.springframework.webflow.security.ExtendedFlowSecurityInterceptor"> <property name="authenticationManager"> <ref bean="authenticationManager" /> </property> <property name="accessDecisionManager"> <ref bean="accessDecisionManager" /> </property> <property name="flowDefinitionSource"> <value> <!-- NOTE: if there is a plain definition for a flow, a matching against regex definitions will not be performed --> <!-- you have to be authenticated as ROLE_CALLER for all flows except for the flows authenticate, startPortal and defaultFlow --> authenticate=ROLE_ANONYMOUS startPortal=ROLE_ANONYMOUS defaultFlow=ROLE_ANONYMOUS regex@.*=ROLE_CALLER </value> </property> </bean> <!-- NOTE : if type is not defined, plain@ is set as default examples : flowId=ROLE_USER flowId.event.eventId=ROLE_USER flowId.event.eventId=ROLE_USER plain@flowId=ROLE_USER plain@flowId.event.eventId=ROLE_USER plain@flowId.state.stateId=ROLE_USER regex@.*=ROLE_USER regex@flowId.event..*=ROLE_USER regex@flowId.state..*=ROLE_USER not supported : regex@.*.event..*=ROLE_USER regex@.*.state..*=ROLE_USER --> Working to add integration with Spring Security based on a SecurityFlowExecutionListener and the new <secured /> entity,
Implemented Spring Security integration via org.springframework.webflow.security.SecurityFlowExecutionListener. Listens on sessionCreating, stateEntering and transitionExecuting events. Looks at 'secured' attribute for org.springframework.webflow.security.SecurityRule and checks if authorized. If not authorized, throws AccessDeniedException exception.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Add support for securing flows
It does exactly what you describe and integrates with Acegi to provide flow-level security, but also more fine-grained control such as security based on state-transitions and events. My guess is this functionality will be used less often, but it certainly is nice.
Anyway, stay tuned!