Pros/Cons to approach: filters none, but access set on remote bean?

[rickcr]

All my business methods have to go through a remote blazeds object. What's the drawback to just declaring no filtering in my spring-security:

<intercept-url pattern='/**/*' filters='none' />

But then in my remote bean definition just declare the roles allowed there? (Also this is probably in the docs and should look before asking, but while I'm typing... is there a way to declare "access=ANY" In other words, the user has to have some authority role in the DB, but any role returned is ok.)

<bean id="flexDelegate" class="com.clevertide.empmaint.delegate.FlexDelegate">
        <security:intercept-methods>
            <security:protect method="*" access="ROLE_USER, ROLE_ADMIN, ROLE_MANAGER"/>
        </security:intercept-methods>
    </bean>

What are the cons to using this approach? TIA

[rickcr]

Sorry to bump- just been quite a while, and am still interested in knowing if this approach is ok?

[jeremyg484]

filters='none' is only going to work correctly if you are using per-client-authentication rather than the default. The filters are necessary otherwise in order to ensure proper storage of the SecurityContext in the HttpSession.

The simplest way to have something akin to your "access=ANY" case is to have a common base role that you give to all known users (remember, they can have multiple roles) like the "ROLE_USER" frequently used in examples. If you want to secure essentially all communication with the MessageBroker to require login no matter what, that is essentially the intended use of the "secured-endpoint-path" config tag. For example:

<flex:message-broker>
    <flex:secured>
        <flex:secured-endpoint-path access="ROLE_USER"/>
    </flex:secured>
</flex:message-broker>

This is similar to Spring Security's path based security except that it results in a proper FaultEvent instead of a 403 (which Flex doesn't handle gracefully). It defaults to a path pattern of "**/messagebroker/*", but of course that can be customized as well.

[rickcr]

Thanks Jermey for the reply, maybe then if you get a chance you can then double check if things are ok with this set up...

First the architecture:
1) There is only swf file that needs to be accessed by anyone since it holds the login form within flex
2) It's ok if all remote calls through the broker have at least a ROLE_USER after log in as successful.

Would this approach then be ok? (If not, what's a better approach. I did read over the docs here http://static.springsource.org/sprin...0.x/reference/ but it seems a bit sparse on 'best approaches' so appreciate the suggestions):

    <http auto-config="true"> 
         <intercept-url pattern='/messagebroker/**' access='ROLE_USER' />
         <intercept-url pattern='/**/*' filters='none' />
    </http auto-config="true">

Then I also set up:

<flex:message-broker>
    <flex:message-service default-channels="emp-maint-amf" />
    <flex:secured>
        <flex:secured-endpoint-path access="ROLE_USER"/>
    </flex:secured> 
</flex:message-broker>

Then I have my one bean (my single remote object that all access goes through):

<bean id="flexDelegate" class="com.clevertide.empmaint.delegate.FlexDelegate">
    <security:intercept-methods> 
        <security:protect method="save*" access="ROLE_ADMIN,ROLE_MANAGER" />  
    </security:intercept-methods> 
</bean>

Would my session by ok with the above? It seems simple, but not sure if I'm missing something.

Thanks for your time.

[jeremyg484]

I think that may end up working, but somewhat for the wrong reasons. I would suggest simplifying further.

First off, get rid of auto-config="true". It sets up a few things that you really don't need in your scenario. (I realize the 1.0.0 version of the sample has auto-config="true", but that was something the Adobe folks did and I've since changed it.)

Second, I suggest not using <intercept-url> at all in your case. You would likely end up getting 403 responses from the /messagebroker calls, and as I mentioned the Flex client doesn't handle this well. Using the <secured-endpoint-path> as you are should be enough to protect all calls to BlazeDS endpoints (assuming they are using the common /messagebroker URLs).

Lastly, if you do take out auto-config="true", you've got to specify an entry point. I find the PreAuthenticatedProcessingFilterEntryPoint works well. (The sample shows this now as well.)

So in summary, I think you'd be better off with:

<http entry-point-ref="preAuthenticatedEntryPoint" />

<beans:bean id="preAuthenticatedEntryPoint" class="org.springframework.security.ui.preauth.PreAuthenticatedProcessingFilterEntryPoint" />

and the rest of your setup as you currently have it.

[rickcr]

Wow. This is awesome Jeremy. I'm really glad you followed up with the code above. The code is so much cleaner now, without even having to use the intercept url section. Love it (even though I admit, being new to both blazeDS and SpringSecurity, that I don't fully grasp all the concepts.)

If others run across this post, hopefully this will help others in securing their flex apps. I'd suggest blogging about this approach (or even having it in the blazeds-security docs somewhere?), since I believe it would be a common practice - where your flex app is a standalone application that only needs the remote calls secured and you have your login form built within the flex app itself.

Please do announce in this forum when the release of the 1.0.1 code and sample app is complete, I really look forward to checking it out and working on understanding how all this works better.

Thanks again!

[jeremyg484]

Wow. This is awesome Jeremy. I'm really glad you followed up with the code above. The code is so much cleaner now, without even having to use the intercept url section. Love it (even though I admit, being new to both blazeDS and SpringSecurity, that I don't fully grasp all the concepts.)

Spring Security, even with the great simplifications in configuration over its predecessors, still takes awhile to fully grasp in part due to its tremendous flexibility, but it's that flexibility that makes it well worth the effort.

If others run across this post, hopefully this will help others in securing their flex apps. I'd suggest blogging about this approach (or even having it in the blazeds-security docs somewhere?)

This is actually how we show the security configuration in the docs, but admittedly it could use some explanation as to why we think that's the most commonly useful approach. Duly noted that we should add this. I'll see if I can squeeze it into 1.0.1.