You can set security constraints on specific BlazeDS channels using the secured-channel child element of the secured tag. For example:

<flex:message-broker>
	<flex:secured>
		<flex:secured-channel channel="my-amf" access="ROLE_USER" />
	</flex:secured>
</flex:message-broker>
    		

This results in any request being routed to the "my-amf" channel to require the user to be logged in and to have the "ROLE_USER" authority. If either of those is violated, a FaultEvent will be signaled on the client.

You can set security constraints on multiple BlazeDS channels at once using the secured-endpoint-path child element of the secured tag. In this case you specify a URL pattern to be secured instead of a specific channel id. For example:

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

This results in any request being routed to any channel whose endpoint URL contains "/messagebroker/" in the path to require the user to be logged in and to have the "ROLE_USER" authority. If either of those is violated, a FaultEvent will be signaled on the client.

Earlier in this chapter you saw an example of using the BlazeDS XML configuration to secure a BlazeDS-managed destination. Since most of the time you will instead be defining destinations by exporting Spring beans using the remoting-destinationtag, an alternate approach to securing destinations is needed. This is where Spring Security comes in, as all of its existing authorization mechanisms should "just work" when security integration is enabled using the secured tag.

One of the major strengths of Spring Security is the multiple levels of granularity it provides you when securing your Spring services. You can go from securing your entire service layer in one concise statement:

<global-method-security>
    <protect-pointcut expression="execution(* com.mycompany.*Service.*(..))" access="ROLE_USER"/>
</global-method-security>
    		

to controlling access in a more fine-grained manner at the method layer using XML:

<bean id="myService" class="com.mycompany.myapp.MyService">
	<flex:remoting-destination/>
    <security:intercept-methods>
        <security:protect method="set*" access="ROLE_ADMIN" />
        <security:protect method="get*" access="ROLE_ADMIN,ROLE_USER" />
        <security:protect method="doSomething" access="ROLE_USER" />
    </security:intercept-methods>
</bean>
    		

to using a combination of XML and annotations:

<security:global-method-security secured-annotations="enabled" jsr250-annotations="enabled"/>
...
<flex:remoting-destination ref="myBankServiceImpl" />
  

    		

public interface BankService {
  
    @Secured("IS_AUTHENTICATED_ANONYMOUSLY")
    public Account readAccount(Long id);
  
    @Secured("IS_AUTHENTICATED_ANONYMOUSLY")
    public Account[] findAccounts();
  
    @Secured("ROLE_TELLER")
    public Account post(Account account, double amount);
}

    		

to even more fine-grained ACL-based domain object permissions. For more details on the options available, see the Spring Security documentation.