Announcement Announcement Module
Collapse
No announcement yet.
Acegi Security System in Spring WebFlow Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    There is an issue regarding this. You can vote.

    I did some refactoring by the way, making the strategy plugable. I currently don't have the code at hand, but when I do I'll post it here (and attach it to the issue I mentioned).

    Comment


    • #47
      problem with acegi + webflow

      Hi,

      I have used files from:

      http://opensource.atlassian.com/proj.../browse/SWF-93 (FlowSecurityInterceptor etc...)

      i declared bean:

      HTML Code:
      <bean id="flowSecurityListener" class="org.springframework.webflow.security.FlowSecurityInterceptor">
          	<property name="rejectPublicInvocations" value="false"/>
          	<property name="authenticationManager" ref="authenticationManager"/>
          	<property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>
          	<property name="flowDefinitionSource">
          		<value>
          			platform-role-search-flow=AUTHORITY_USER
          			platform-fake-flow=AUTHORITY_SUPERADMIN
          		</value>
          	</property>
          </bean>
      and:

      HTML Code:
      <flow:executor id="flowExecutor" registry-ref="flowRegistry">
      		<flow:repository type="continuation"/>
      		<flow:execution-listeners>
      			<flow:listener ref="flowSecurityListener"/>
      		</flow:execution-listeners>
      		
      	</flow:executor>
      I have applied corrected version of ExceptionTranslationFilter from mdeinum user (from this thread). And in sum when I enter with user without AUTHORITY_SUPERADMIN into flow: platform-fake-flow, I have

      Code:
      java.lang.IllegalStateException: This flow execution is not active, it has either ended or has never been started.
      	at org.springframework.webflow.engine.impl.FlowExecutionImpl.assertActive(FlowExecutionImpl.java:456)
      	at org.springframework.webflow.engine.impl.FlowExecutionImpl.getActiveSessionInternal(FlowExecutionImpl.java:385)
      	at org.springframework.webflow.engine.impl.FlowExecutionImpl.getActiveSession(FlowExecutionImpl.java:158)
      	at org.springframework.webflow.engine.impl.RequestControlContextImpl.getActiveFlow(RequestControlContextImpl.java:102

      I have correct acegi installation because it secures "regular" files correctly, I have problem only with flow security. My filterChainProxy looks:
      HTML Code:
      <bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
            <property name="filterInvocationDefinitionSource">
               <value><![CDATA[
      		    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      		    PATTERN_TYPE_APACHE_ANT
                  /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,basicProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,switchUserProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
               ]]></value>
            </property>
          </bean>
      I have looked into source of acegi and I think the problem is somewhere with propagating AccessDeniedException, in AbstractSecurityInterceptor, when it comes to attempt to authorization (about line 323):
      accessDecisionManager.decide(authenticated, object, attr);
      it throws AccessDeniedException (I know it because it does not end in line:
      Code:
      if (logger.isDebugEnabled()) {
      			logger.debug("Authorization successful");
      		}
      And in logs there is nothing about AccessDeniedException, so I suppose this is the cause of not invoking exception to message translation, I have:

      Code:
      14:28:13,324 DEBUG AbstractSecurityInterceptor:284 - Secure object: [email protected]f6e66a1c; ConfigAttributes: [AUTHORITY_SUPERADMIN]
      14:28:13,324 DEBUG AbstractSecurityInterceptor:317 - Previously Authenticated: [email protected]b6c662e: Username: brainiac.shared.domain.User@1f6ae4d; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@1c07a: RemoteIpAddress: 127.0.0.1; SessionId: l1vss0lsysxo; Granted Authorities: brainiac.shared.domain.Authority@13d0fea, brainiac.shared.domain.Authority@1dffb78
      
      14:28:13,324 DEBUG DispatcherServlet:915 - Cleared thread-bound request context: org.acegisecurity.wrapper.SavedRequestAwareWrapper@1773a14
      14:28:13,324 DEBUG DispatcherServlet:493 - Could not complete request
      java.lang.IllegalStateException: This flow execution is not active, it has either ended or has never been started.
      Anyone can help me? I want to do this right without doing workarounds and modifying acegi sources

      Comment


      • #48
        hey, i remember having this issue...the problem is that acegi is prohibiting access to the flow before it starts...then the exception gets to the not created flow, and swf blows up. my solution to this was to secure the flow,just in case, and to create a redirection state that is also secured...so insecure->redirection(secured)->secure

        when the security blocks the middle state you are in an active/initialized flow and swf handles the exception and throws you to access denied. and if some smart ass just types in ?_flowId=platform-fake-flow then they get thet tomcat death page.(unless you put in a exception handler)

        Comment


        • #49
          trdyer ,

          thanks for your answer but I think still doing wrong, my modified flow of redirection looks:

          HTML Code:
          <start-state idref="redirectBeforeEnterCriteria" />
          
          	<view-state id="redirectBeforeEnterCriteria" view="redirect:enterCriteria">
          		
          	</view-state>
          	
          	<!-- <start-state idref="enterCriteria" /> -->
          
          	<view-state id="enterCriteria" view="intranet-two-column">
          		<render-actions>
          
          		
          			<!-- search form -->
          			<bean-action bean="platformRoleSearch" method="render">
          				<method-result name="column_left" />
          			</bean-action>
          
          			<!-- details (currently not shown) -->
          			<bean-action bean="commonEmptyDetails" method="render">
          				<method-result name="column_right" />
          			</bean-action>
          		</render-actions>
          
          	</view-state>
          So I have first state that redirects to second state, my security looks like:

          Code:
          <bean id="flowSecurityListener" class="org.springframework.webflow.security.FlowSecurityInterceptor">
              	<property name="rejectPublicInvocations" value="false"/>
              	<property name="authenticationManager" ref="authenticationManager"/>
              	<property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>
              	<property name="flowDefinitionSource">
              		<value>
              			platform-role-search-flow=AUTHORITY_USER
              			platform-fake-flow=AUTHORITY_SUPERADMIN
              		</value>
              	</property>
              </bean>
          And first fragment defines: platform-fake-flow. With this I have the same symptoms that occure before, could you give your samples of security definition with fragment of your real flow? Thanks in advance

          Comment


          • #50
            sorry, i wasnt very clear, in your insecure flow you need...

            Code:
            <subflow-state flow="platform-fake-flow" id="secure">
                <transition to="logout" on="logout"/>
            </subflow-state>
            and in your security you need....
            Code:
            <bean id="flowSecurityListener" class="org.springframework.webflow.security.FlowSecurityInterceptor">
                	<property name="rejectPublicInvocations" value="false"/>
                	<property name="authenticationManager" ref="authenticationManager"/>
                	<property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>
                	<property name="flowDefinitionSource">
                		<value>
                			platform-role-search-flow=AUTHORITY_USER
                			platform-role-search-flow.secure=AUTHORITY_SUPERADMIN
                			platform-fake-flow=AUTHORITY_SUPERADMIN
                		</value>
                	</property>
                </bean>
            that way the security will veto/prohibit you from entering the secure state in the subflow, and the transition to the fake-flow will not have occured

            so in your jsp you will just create a link with ?_flowExectionKey=${flowExecutionKey}&_eventId=sec ure

            so...when you click on the link swf starts to transition you to secure, Acegi intercepts and checks to see if you are authenticated, then authorized. if you are not authorized acegi throws an authorization exception and you hopefully get redirected to "Access Denied".

            If you are authorized then the transition to the subflow occurs, and when you start the subflow Acegi checks again to see if you have permissions, you do since you got through the redirect, so you are able to see all of the superadmin level pages.

            If you are not authenticated, (presumably you are because it looks to me as if you are entering from a AUTHORITY_USER portion of the site) then you will be shown the Acegi login screen. After authenticating you will be authorized, or not, as above.

            If someone types foo.jsp?_flowId=platform-fake-flow, and they arent authorized, then acegi will prohibit the flow from starting. As a result, they have left the last flow, they currently are not in a flow(no flowexecutionkey) so they are in a limbo state that swf cant handle. Any exception handlers defined at the flow level wont work because the swf controller is causing the exception, and cant resolve its own. That means you have to define an exception resolver at the servlet(spring mvc) level.

            ie
            Code:
             
            <bean id="simpleMappingExceptionResolver" class="org.springframework.web.servlet.handler.SimpleMappingException Resolver">
                <property name="exceptionMappings">
                     <props>
            .................
            .................
            .................
                     </props>
                 </property>
            <bean>
            Last edited by trdyer; Nov 28th, 2007, 07:55 AM.

            Comment


            • #51
              thanks trdyer,

              in the meantime I have modified my security to:
              HTML Code:
              <property name="flowDefinitionSource">
                  		<value>
                  			platform-role-search-flow=AUTHORITY_USER
                  			platform-fake-flow=AUTHORITY_USER
                  			platform-fake-flow.state.enterCriteria=AUTHORITY_SUPERADMIN
                  		</value>
                  	</property>
              and my flow definition to simple:
              HTML Code:
              <start-state idref="enterCriteria" />
              
              	<view-state id="enterCriteria" view="intranet-two-column">
              		<render-actions>...
              and it simply works (I can see AccessDeniedException in logs)
              yet another thanks for your help

              Comment


              • #52
                One way

                We actually got around this problem by using the "rest" argument handler within the defined flow controller, the solution is by no way a recommended approach but never-the-less it does work.

                Comment


                • #53
                  Hi there,

                  after a while I finally managed to get it working, the only pitty is that I end up with an exception page because somwhere the Exception is wrapped in A ServletException without a cause. I should mention that I am using JSF. Does anyone have experience where I may hook in to prevent the exception to be wrapped without the causing acegi exception?

                  Regards Jakob

                  Comment


                  • #54
                    RE : Acegi Security System in Spring WebFlow

                    Hi EveryOne ,

                    These are Acegi Security System in Spring WebFlow key feature :-

                    # Stable and mature: Acegi Security 1.0.0 was released in May 2006 after more than two and a half years of use in large production software projects, 70,000+ downloads and hundreds of community contributions. In terms of release numbering, we also use the Apache APR Project Versioning Guidelines so that you can easily identify release compatibility.
                    # Well documented: All APIs are fully documented using JavaDoc, with almost 100 pages of Reference Guide documentation providing an easy-to-follow introduction. Even more documentation is provided on this web site, as shown in the left hand navigation sidebar.
                    # Fast results: View our suggested steps for the fastest way to develop complex, security-compliant applications.
                    # Enterprise-wide single sign on: Using JA-SIG's open source Central Authentication Service (CAS), the Acegi Security can participate in an enterprise-wide single sign on environment. You no longer need every web application to have its own authentication database. Nor are you restricted to single sign on across a single web container. Advanced single sign on features like proxy support and forced refresh of logins are supported by both CAS and Acegi Security.
                    # Reuses your Spring expertise: We use Spring application contexts for all configuration, which should help Spring developers get up-to-speed nice and quickly.
                    # Domain object instance security: In many applications it's desirable to define Access Control Lists (ACLs) for individual domain object instances. We provide a comprehensive ACL package with features including integer bit masking, permission inheritence (including blocking), a JDBC-backed ACL repository, caching and a pluggable, interface-driven design.
                    # Non-intrusive setup: The entire security system can operate within a single web application using the provided filters. There is no need to make special changes or deploy libraries to your Servlet or EJB container.
                    # Full (but optional) container integration: The credential collection and authorization capabilities of your Servlet or EJB container can be fully utilised via included "container adapters". We currently support Catalina (Tomcat), Jetty, JBoss and Resin, with additional containers easily added.

                    Comment

                    Working...
                    X