Glassfish v3, BlazeDS, and authentication.

Question

Hi,
I'm looking for documentation about how to configure BlazeDS security with Glassfish v3.  I've found this:
http://anachronymous.com/2009/01/flex-blazeds-and-glassfish-part-1.html
...but it's for Glassfish v2.  Most of it should be the same, but some of the TomcatValve stuff has changed for Glassfish v3:
http://blogs.sun.com/jluehe/entry/glassfish_v3_adds_support_for
Should I be able to ignore the valve configuration and simply use TomcatLoginCommand since Glassfish v3 is supposed to support Tomcat style valves?  I tried adding the following to services-config.xml:
<security>
    <login-command class="flex.messaging.security.TomcatLoginCommand" server="all"/>
</security>
...but upon deployment I get the following error:
javax.servlet.UnavailableException: Cannot create class of type 'flex.messaging.security.TomcatLoginCommand'.
Can anyone point me in the right direction?
Ryan

Answer 1

I'll assume you've got Glassfish using the default 'file' realm for authentication.  If not you'll have to adapt my instructions to the realm you're using.
1) Load the glassfish admin console.
2) Navigate to 'Configuration -- Security -- Realms -- file'.
3) Select 'Manage Users' near the top left.
4) Select 'New'
5) Add the user 'tech'.  In the 'Group List' put 'tech'.  Use any password you like.
6) Select 'OK' to save your user.
7) Navigate to 'Configuration -- Security'.
8) Enable 'Default Principal To Role Mapping'.  I can't remember why I have this enabled, so feel free to research it a bit.
9) Select 'Save' to save the changes.
Here is a complete copy of a simple web.xml that I've used:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
         version="2.5">
    <display-name>ITMA Web App</display-name>
    <!-- Http Flex Session attribute and binding listener support -->
    <listener>
        <listener-class>flex.messaging.HttpFlexSession</listener-class>
    </listener>
    <!-- MessageBroker Servlet -->
    <servlet>
        <display-name>MessageBrokerServlet</display-name>
        <servlet-name>MessageBrokerServlet</servlet-name>
        <servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
        <init-param>
            <param-name>services.configuration.file</param-name>
            <param-value>/WEB-INF/flex/services-config.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>MessageBrokerServlet</servlet-name>
        <url-pattern>/messagebroker/*</url-pattern>
    </servlet-mapping>
    <welcome-file-list>
        <welcome-file>itma-flex-ui-blazeds.swf</welcome-file>
    </welcome-file-list>
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>file</realm-name>
    </login-config>
    <security-role>
        <role-name>tech</role-name>
    </security-role>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Flex UI</web-resource-name>
            <url-pattern>/messagebroker/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>tech</role-name>
        </auth-constraint>
    </security-constraint>
</web-app>
Note the MessageBrokerServlet configuration, specifically the <servlet-name>.  You probably have something similar.  The <servlet-mapping> means all requests to urls like 'http://my.domain.com/contextroot/messagebroker/amf' will be processed by the MessageBrokerServlet.   The <security-constraint> configuration restricts all requests to '/messagebroker/*'.  Basically all requests to the MessageBrokerServlet will require authentication.
All of the roles in your application need to get listed in  the <security-role> section.  Each role needs to be mapped to a 'Principal' on the Glassfish server.  I'm not positive, but I think the 'Default Principal To Role Mapping' will automatically map users defined as being of the role 'tech' to the 'tech' user (principal) or possibly the 'tech' group.  I'm a little unclear on how it works with the group list.
The final parts are the <login-config> and <auth-constraint> sections.  The login config defines the realm to use (file in this example).  The auth-constraint section says that access to the listed resources should be restricted to users in the 'tech' role.
The whole process is something like this:
1) Only users in the role 'tech' can access urls that match /messagebroker/*.
2) The role of tech is defined and mapped to a principal (or group of principals) within the file realm on the server.
3) The 'Default Principal To Role Mapping' option in glassfish automatically maps the tech role to the tech principal (user) or group (I'm not actually sure which one).  I think you'd normall need to configure this somewhere and map the roles in your flex application to groups in your security realm.
Try creating a configuration like the above.  Ignore the BlazeDS portion of the configuration to start with and see if you can get it working with just web.xml.  After you get that working and know you can actually authenticate to the container (Glassfish), then you can go back to trying to get the BlazeDS side of things configured / mapped.
I hope that helps,
Ryan