Typically, you configure security in the services-config.xml file. However, you can also add security settings specific to other services in the data-management-config.xml, messaging-config.xml, and other configuration files.

You reference the security constraints when you define a destination. Multiple destinations can share the same security constraints. The following example shows a security definition in the services-config.xml file that defines two security constraints:

<services-config>
    <security>
        <login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"> 
            <per-client-authentication>false</per-client-authentication>
        </login-command>
    
        <security-constraint id="trusted">
            <auth-method>Basic</auth-method>
            <roles>
                <role>guests</role>
                <role>accountants</role>
                <role>employees</role>
                <role>managers</role>
            </roles>
        </security-constraint>
    
        <security-constraint id="sample-users">
            <auth-method>Custom</auth-method>
            <roles>
                <role>sampleusers</role>
            </roles>
        </security-constraint>
    </security>    
    ...
</services-config>

This example sets class and server properties for the login-command for the Tomcat server.

The following table describes the properties that you use to configure security:

Using per-client and per-session authentication

By default, authentication is performed on a per-session basis and authentication information is stored in the FlexSession object associated with the Flex application. Therefore, if two client-side applications share the same session, when one is authenticated for the session, the other one is also authenticated. For example, multiple tabs in the same web browser share the same session. If you open a Flex application in one tab, and then authenticate, any copy of that application running in another tab is also authenticated.

Alternatively, you can enable per-client authentication by setting the per-client-authentication property of the login-command to true. Authentication information is then stored in the FlexClient object associated with the Flex application. Setting it to true allows multiple clients sharing the same session to have distinct authentication states. For example, two tabs of the same web browser could authenticate users independently.

Another reason to set the per-client-authentication property to true is to configure the server to reset the authentication state based on a browser refresh. Refreshing a browser does not create a new server session. Therefore, by default, the authentication state of a Flex application persists across a browser refresh. Setting per-client-authentication to true resets the authentication state based on the browser state.

The login commands that ship with BlazeDS rely on authentication information stored in the J2EE session on the server. If you use one of these login commands with per-client authentication, the authentication information for the different clients conflicts in the J2EE session. Therefore, to use per-client authentication, create a custom login command that does not store authentication information in the J2EE session.

Configuring a destination to use a security constraint

Define a security constraint in the security section of the Flex services configuration file and reference it in destinations. The following example shows a security constraint that is referenced in two destination definitions:

<security>
    <login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"> 
        <per-client-authentication>false</per-client-authentication>
    </login-command>

    <security-constraint id="trusted">
        <auth-method>Basic</auth-method>
        <roles>
            <role>employees</role>
            <role>managers</role>
        </roles>
    </security-constraint>
</security>    

<service>
    <destination id="SecurePojo1">
        ...
        <security>
            <security-constraint ref="trusted"/>
        </security>
    </destination>

    <destination id="SecurePojo2">
        ...
        <security>
            <security-constraint ref="trusted"/>
        </security>
    </destination>
    ...
</service>

When a security constraint applies to only one destination, you can declare the security constraint in the destination definition, as shown in the following example:

<destination id="roDest">
    ...
    <security>
        <security-constraint>
            <auth-method>Custom</auth-method>
            <roles>
                <role>roDestUser</role>
            </roles>
        </security-constraint>
    </security>
</destination>

You can set a default security constraint at the service level. Any destination of a service that does not have an explicit security constraint uses the default security constraint. The following example shows a default security constraint configuration:

<service>
...
    <default-security-constraint ref="sample-users"/>
</service>

The following table describes the properties that you use to configure security for a destination:

Restricting method access on a Remoting Service destination

For Remoting Service destinations, you can declare destinations that only allow invocation of methods that are explicitly included in an include list. You can use this feature with or without a security constraint on the destination. Any attempt to invoke a method that is not in the include-methods list results in a fault event. For even more granular security, you can assign a security constraint to one or more methods in the include-methods list. If a destination-level security constraint is defined, it is tested first and method-level constraints are checked second.

The following example shows a destination that contains an include-methods list and a method-level security constraint on one of the methods in the list:

<destination id="sampleIncludeMethods">
    <properties> 
        <source>my.company.SampleService</source>
        <include-methods>
            <method name="fooMethod"/>
            <method name="barMethod" security-constraint="admin-users"/>
        </include-methods>
    </properties>
    <security>
        <security-constraint ref="sample-users"/>
    </security>
</destination>

You can also use an exclude-methods element, which is like the include-methods element, but operates in the reverse direction. All public methods on the source class are visible to clients except for the methods in this list. Use exclude-methods if only a few methods on the source class must be hidden and no methods require a tighter security constraint than the destination.