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.

Comments

[roger]

First of all thanks a lot for this article.

I have a very similar scenario running on JBoss 5.1 GA with a custom jdbc security domain. I define the security domain to be used in jboss.xml instead of using the JBoss specific SecurityDomain annotation. This works nicely as long as I try to run my app with java webstart. I always receive "javax.ejb.EJBAccessException: Caller unauthorized". Does anybody have any ideas to solve that?

[Nursing gowns]

excellent post and that's quite a code there, thanks! this really helps us.

[accounting homework help]

Hi,

I am trying to secure a EJB(based on EJb3 spec) and facing somes issues with it.

[קניית דומיין]

Your work is inventive and valuable. Thank you for this fascinating post! Attractive section of content. Your blog is great for anyone who wants to understand this subject more. This is great stuff.

[payday loan online]

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.

[Sunless Tanning]

This is more than an excellent post
Self Tanning