Happy Birthday!

Bake a cake, take out the forks, brew a cup of coffee and light some candles! This month we are celebrating the 40th birthday of the UNIX operating system as well as the 50th birthday of the COBOL programming language.

These two technologies affected the business world like few others did and to this very day we are still relying on Unix (and Unix-like) installations for our business critical systems and Cobol still processes millions of our banking transactions.

So with no further ado: Happy birthday and thank you Ken Thompson for inventing Unix and thank you Grace Murray Hopper for inventing Cobol.

Are we Java Programmers done for?

I do realize that the continuous stream of Oracle+Sun articles might bore you, however, I feel that I have to add my 2 cents to the subject as the last couple of weeks have been fairly interesting in my professional life.

It started out when one of my former colleagues asked me to check a popular Swedish page on IT. The first article on the page put me in shock: "Oracle buying Sun", it said in bold black letters. Oracle, of all companies? Why oh why! Not that there is anything wrong with the Oracle database or WebLogic, I just hoped that it would be a company with a slightly more open attitude (yes, open as in open source) since the majority of recent advancements in Java were either proposed or contributed by the open source community.

After some hours went by I was starting to reason with myself: Is it so bad? I concluded that it probably is not. What was more damaging to Java were the rumours about Sun possibly going bankrupt (even though we all know now that this was all just trash talk to begin with). We have now one of the largest and richest software companies in the world backing up the technology millions of companies deploy for everything from web pages, mobile games up to mission critical banking and health care systems. These companies can now continue use Java and feel confident that it is not going to disappear anytime soon.

There is another question. Will we end up being locked in to Oracle-only products? I doubt that, too. Oracle may be a closed source company, yet, they know just as well as you and I do that Java's continuing success in the business world is largely based on it's openness and it's community support.

OpenJDK is not going to disappear, JBoss is not going to disappear and Spring is not going to disappear either. Furthermore, more and more languages use Java's mature core (the Java Virtual Machine) to make amazing things possible. Oracle must and will recognize this because despite being a rich company... they don't want to flush more than seven billion dollars down the drain.

I may add that there is one thing that does concern me a little bit. The Oracle and Sun-merger gives Oracle the majority voting power in the Java Community Process. Will they use this power to heavily influence Java EE to their advantage? Possibly, yet, I don't think this is a major concern either. Java is all about freedom of choice and if you or your employer doesn't like the changes in Java EE then you can move to Spring or any other Java-framework which fits your needs without losing the benefits of utilizing a mature platform.

To conclude my post. Yes, Oracle did buy Sun and yes, Oracle is not very known for being open and community-oriented but I do think that Java is strengthened by the merger and that Sun's (soon Oracle's) employees can make a difference at Oracle.

What do you think? I would love to hear your thoughts on my point of view!

Caller identity propagation in JBoss

Recently I was asked by a client of mine how they would go about to propagate a JAAS Principle from one layer of their Java EE application to the next. Basically, the problem they had was that they needed to get some information about the logged on user from the Web Layer to the EJB Layer. Initially I was surprised because I thought that it is rather self-explanatory... apparently, if you haven't worked with JBoss, it isn't.

Anyway, if you should be stuck with the very same issue I will share a quick and easy solution for JBoss with you.

The security domain

First and foremost you have to create a security domain in JBoss' login-config.xml-file, which is located in your configuration's /conf directory.

For instance, add following snippet to the file:

<!-- defines a security domain for your jee application -->
<application-policy name="my-domain">
 <authentication>
  <!-- this login module is used for file based user/role-storage -->
  <login-module flag="required" code="org.jboss.security.auth.spi.UsersRolesLoginModule">
   <!-- these files must be present in {domain}/conf/prop -->

   <!-- contains {user}={password} for each user -->
   <module-option name="userProperties">prop/my-domain-user.properties</module-option>
   <!-- contains {user}={role},... for each user -->
   <module-option name="roleProperties">prop/my-domain-role.properties</module-option>
  </login-module>
 </authentication>
</application-policy>

Naturally you can use any other LoginModule. For the sake of argument, I used a simple one which uses files for users and their roles.

The ClientLoginModule

The security domain, however, is not quite enough. You also need to add an application policy for JBoss' ClientLoginModule, which, in turn, enables security context propagation between the application's layers.

If not already present (depending on your version of JBoss), also add this snippet to the file:

<!-- used by web layer to send login information to ejbs -->
<application-policy name="client-login">
 <authentication>
  <login-module flag="required" code="org.jboss.security.ClientLoginModule"/>
 </authentication>
</application-policy>

Securing your application

Now that you have JBoss prepared, it's time to actually make your application use the security domain which we've just created. You can either do this in each individual EJB- or Web Archive contained in your EAR-file, however, in my example, I do it the easy way and define the security domain for the entire Enterprise Application.

In your EAR-file, you need to add a file called jboss-app.xml, which is placed in the META-INF directory.

If you haven't got a jboss-app.xml already, just copy and paste this into your newly created file:

<jboss-app>
 <-- should point to the JAAS domain in the global JNDI -->
 <security-domain>java:/jaas/my-domain</security-domain>
</jboss-app>

Propagating caller identity to the EJB

You are almost ready to go, however, the EJB invoked by your Web Layer will not yet be able to retrieve the caller's identity from the User Interface.

To get this working, add a ejb-jar.xml to your EJB archive's META-INF directory. You may or may not have this file. In most larger EJB 3.0-projects I've participated in, we eventually added one, even though it is not always necessary due to those nifty annotations.

Anyway, in the ejb-jar.xml, add the security-identity element to your bean's configuration, like so:

<ejb-jar>
 <enterprise-beans>
  <session>
   <!-- replace MyBean with the name of _your_ bean -->
   <ejb-name>MyBean</ejb-name>
   <security-identity>
    <use-caller-identity/>
   </security-identity>
  </session>
 </enterprise-beans>
</ejb-jar>

Wow, finally done. Thanks to all those XML-snippets you are now able to share the Principal between your UI and the business layer.

To wrap this up I just want to add that it doesn't always make sense to have the same identity in your business logic, in many cases you run your code with a narrower collection of roles and the logged on user is irrelevant to the business logic. However, if you need an audit log in your database to see who did what, then this is a fairly convenient way to get your hands on the user name.

As always, enjoy!