Hi Jim,

The short answer is that TomcatLoginCommand uses Tomcat valve to do
its authentication/authorization but here's a writeup I have on
BlazeDS security that should clarify things.

-Mete

=============================================================
BlazeDS uses the security framework of the underlying application
server via the LoginCommand interface. A few application server
implementations of LoginCommand come with BlazeDS. There are
implementations for Tomcat/JBoss, Websphere, Weblogic, Oracle, JRun
and you can also write your own LoginCommand. In terms of concrete
steps for setting up security, this is what you need (assuming that
you're using Tomcat but the steps are similar for other app servers):

First, you need to tell BlazeDS who will handle
authentication/authorization and this is done via specifying a
LoginCommand. In services-config.xml, under security section,
uncomment a login command for your application server:

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

Second, you need to define a security constraint in BlazeDS that will
be used to secure individual destinations. A security constraint
defines how the credentials will be passed from Flex to BlazeDS (basic
or custom) and what roles the security constraint will expect. Basic
authentication means a browser window pops up asking the user for
username and password when the client tries to access the destination.
Custom authentication means instead of a browser window, the Flex
application itself passes the authentication to BlazeDS. Roles are
application server specific. For example, in Tomcat, they are defined
in conf/tomcat-user.xml file:

  <?xml version='1.0' encoding='utf-8'?>
  <tomcat-users>
    <role rolename="sampleusers"/>
    ...
    <user username="sampleuser" password="samplepassword"
roles="sampleusers"/>
  </tomcat-users>

Now, in BlazeDS, in services-config.xml, under security section,
define a security constraint that your destinations will refer to.
Here's an example of each (custom and basic): 

        <!-- Basic authentication -->
        <security-constraint id="sample-user-basic">
            <auth-method>Basic</auth-method>
            <!-- Roles are defined by the application server. 
                In Tomcat, they are in conf/tomcat-users.xml 
            -->
            <roles>
                <role>sampleusers</role>
            </roles>
        </security-constraint>
        <!-- Custom authentication -->
        <security-constraint id="sample-user-custom">
            <auth-method>Custom</auth-method>
            <roles>
                <role>sampleusers</role>
            </roles>
        </security-constraint>

Now, you can secure your destination in BlazeDS. In your destination
definition (remoting-config.xml, messaging-config.xml,
proxy-config.xml), refer to the security constraint you defined in the
previous step with "<security-constraint ref=""/>" tag. Here's an example:

    <destination id="remoting_AMF_SecurityConstraint_Basic"
channels="my-amf">
        <properties>
            <source>features.remoting.EchoService</source>
        </properties>
        <security>
            <security-constraint ref="sample-user-basic"/>
        </security>
    </destination>

If your destinations are using basic authentication, then no extra
work is required in your Flex application as browser will handle
passing in the credentials. If they are using custom authentication,
then you need to pass the credentials to BlazeDS, preferably using
ChannelSet.login method and listening for authentication success or
failure with AsyncToken pattern, something like this:

            private function login():void
            {
                // Pre-initialize channelSet, so we can login.
                if (remoteObject.channelSet == null)
                    remoteObject.channelSet =
ServerConfig.getChannelSet(remoteObject.destination);

                // Login and handle success or failure of authentication 
                var token:AsyncToken =
remoteObject.channelSet.login("sampleuser", "samplepassword");
                token.addResponder(new AsyncResponder(
                    function(event:ResultEvent, token:Object=null):void 
                    {
                        switch(event.result) 
                        {
                            case "success":
                                Alert.show("Login success");
                            break;
                            default:
                                trace(event.result); 
                        }
                    },
                    function(event:FaultEvent, token:Object=null):void
                    {
                        switch(event.fault.faultCode)
                        {
                            case "Client.Authentication":
                            default:
                                authenticatedCB.selected = false;
                                Alert.show("Login failure: " +
event.fault.faultString);
                        }
                    }));
            }
==============================================================

--- In flexcoders@yahoogroups.com, "Jim Boone" <[EMAIL PROTECTED]> wrote:
>
> Hi,
> 
> I am trying to wrap my brain around the BlazeDS destination security
> model. I have read the "Securing destinations" section in the BlazeDS
> Developer's Guide about 20 times and I have spent the better part of a
> day trying to determine the best way to secure destinations.  I'm sure
> it is simple once you know how it all works. Maybe someone can provide
> a simple explanation before I bang my head on the wall!  My biggest
> question is:
> 
> What is the relationship between BlazeDS channel security and J2EE
> container managed security? Are they independent, complimentary, or
> redundant? 
> 
> I am using JBoss and wish to tap into the JBoss security model. The
> BlazeDS source code download tells you how to do this in a readme.txt
> file. What I am not clear about is what does the Tomcat Valve do? How
> is this related to the TomcatLoginCommand that is configured in the
> services-config.xml file?  Any insights would be appreciated.  Thanks!
> 
> Jim
>


Reply via email to