Michael Sikora on Java EE

Converting to JBoss-5.0.0.GA - EJB3 Security

In this post I'll describe the conversion of examples of chapter 12, which deals with EJB 3 Security, from Glassfish to JBoss 5.0.0.GA. There are two aspects to EJB 3 security: authentication and authorization. Authorization (namely restricting access to bean methods to a given role or roles) turns out to be completely portable and no code changes were required.

All Java EE compliant application servers support the JAAS standard for authentication (namely checking a user's identity is valid, typically by validating a username and password). So using JAAS is recommended for ensuring portable applications. However JAAS is awkward to use, requiring the creation of a callback handler class with a lot of boilerplate code and rather invasively injecting more boilerplate code into the client class. Consequently application servers either hide the JAAS in a proprietary manner or provide a proprietary work around.

The JBoss solution is for the client to use the non standard org.jboss.security.client.SecurityClient class and associated SecurityClientFactory.

First we need to add the JBoss specific org.jboss.ejb3.annotation.SecurityDomain annotation to the BankServiceBean as follows:

@Stateless

@SecurityDomain("other")

@RolesAllowed("bankemployee")

public class BankServiceBean implements BankService {

"other" indicates that we will use JBoss's default authentication mechanism. JBoss's authentication configuration file is login-config.xml situated in JBOSS_HOME\server\default\conf directory. In the case of "other", login-config.xml invokes a simple JBoss supplied login module which in turn expects 2 properties files: users.properties and roles.properties. The content of users.properties is:

scott=xyz12345

ramon=abc54321

This is a list of usernames and corresponding passwords. The content of roles.properties is:

scott=bankemployee

ramon=bankcustomer

This is a list of usernames and roles to which they have been assigned. Both users.properties and roles.properties need to be in the same directory as the JBoss supplied login-config.xml. After the properties files have been created the JBoss server will need to be restarted.

Alternatively the properties files can be created in the application's directory structure and included in the EJB jar file.

Finally we need to modify the client by first importing JBoss specific classes:

import org.jboss.security.client.SecurityClient;

import org.jboss.security.client.SecurityClientFactory;

Then we need to invoke SecurityClient login methods before invoking the BankServiceBean EJB:

SecurityClient securityClient = SecurityClientFactory.getSecurityClient();

securityClient.setSimple("scott", "xyz12345");

securityClient.login();

InitialContext ctx = new InitialContext();

BankService bank = (BankService) ctx.lookup("BankService/BankServiceBean/remote");

This is the last in the migrating EJB 3 to JBoss 5.0.0.GA series. All the source code should shortly be available for download from the book's website.

Converting to JBoss-5.0.0.GA - Part 3

In this post I'll describe the conversion of the examples from chapter 11, which deals with EJB 3 Web Services, from Glassfish to JBoss 5.0.0.GA. The modifications required were all concerned with deployment: in particular invoking application server specific tools which generate various web service artefacts. These tools are invoked from the build.xml file.

wsprovide is the JBoss equivalent of the Glassfish wsgen tool and the Weblogic jwsc tool. wsprovide takes as input a Java class file with embedded web service annotations and generates all the artefacts, including a wsdl file, required to create a web service. In JBoss explicit use of wsprovide is optional as web service artefacts are generated at deployment time if they have not already been created by wsprovide. (The use of the Glassfish wsgen tool is also optional; however the Weblogic jwsc tool always needs to be explicitly invoked.)

wsconsume is the JBoss equivalent of the Glassfish wsimport tool and the Weblogic clientgen tool. wsconsume generates from an existing wsdl file the client artefacts that client applications use to invoke JBoss and non-JBoss web services.

The client needs to use WS-Security by creating a META-INF/standard-jaxws-client-config.xml file. A sample file can be found in JBOSS_HOME\server\default\deployers\jbossws.deployer\META-INF. This file needs to be copied to the application directory tree. The file is then edited so that only the Standard WSSecurity Client configuration is left. The edited standard-jaxws-client-config.xml file should look as follows:

<jaxws-config xmlns="urn:jboss:jaxws-config:2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="urn:jboss:jaxws-config:2.0 jaxws-config_2_0.xsd">

<client-config>

<config-name>Standard WSSecurity Client</config-name>

<post-handler-chains>

<javaee:handler-chain>

<javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings>

<javaee:handler>

<javaee:handler-name>WSSecurityHandlerOutbound</javaee:handler-name>

<javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerClient</javaee:handler-class>

</javaee:handler>

</javaee:handler-chain>

</post-handler-chains>

</client-config>

</jaxws-config>

This file then needs to be packaged in the client jar file.

There are a large number of jar files that need to be included in the run time classpath. I had quite a job figuring out which jar files these should be only to find the answer in the wsrunclient script which is in the JBOSS_HOME\bin directory.

That's it - the next post will be on JBoss EJB3 security.

.