Home » Blogs » acoliver's blog

Authenticate via JNDI over HTTP in JBoss and building/feeding JBossAS

In Weblogic you can authenticate for remote EJB authentication via JNDI like this:


Properties p = new Properties();
p.put(Context.SECURITY_PRINCIPAL, "user");
p.put(Context.SECURITY_CREDENTIALS, "password");
...
InitialContext ctx = new InitialContext(p);

In JBoss you have to do this (official verbose explanation for the bored):


UsernamePasswordHandler handler = null;
handler = new UsernamePasswordHandler(username, password);
LoginContext lc = new LoginContext("example", handler);
lc.login();

With a special file called auth.conf or jaas.config in your classpath:


example { org.jboss.security.ClientLoginModule required;};

JBoss did add a special org.jboss.security.jndi.LoginInitialContextFactory which allows you to do this like in WebLogic, however it doesn't work with the HTTP Stack for instance. If you look inside of it, it just does the jaas login above in the getInitialContext. The problem is that you still need a auth.conf or similar in the classpath. Since like 99% of all applications are looking to shove in a username and password this is still goofy. I needed the HttpNamingContextFactory to work, and I really didn't want to change the client's code to do all that JAAS monkey business, so I patched HttpNamingContextFactory to only try to do Jaas for you if you pass in the SECURITY_PRINCIPAL. I also made it work so that if you choose it include the auth.conf/jaas.config -- it is cool with that. If you don't then it does the smart thing and assumes you meant username/password normal authentication junk.


UsernamePasswordHandler handler = new UsernamePasswordHandler(username,
credentials);
Configuration conf = getConfiguration();
// Do the JAAS login
LoginContext lc = new LoginContext(protocol, null, handler, conf);
lc.login();

The magic is in getConfiguration() of course:


private Configuration getConfiguration() {
Configuration conf = null;
try {
conf = Configuration.getConfiguration();
} catch (Exception e) {
if(e.getCause() instanceof IOException) { //no auth.conf or whatever so we make our own dummy
conf = new DummyConfiguration();
}
}
return conf;
}
...
/**
* When no configuration file is found (we get IOException as the cause of a SecurityException),
* we make this dummy that uses the default ClientLoginModule as required with no options.
*
*/
class DummyConfiguration extends Configuration {
public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
return new AppConfigurationEntry[] {
new AppConfigurationEntry("org.jboss.security.ClientLoginModule",AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, new java.util.HashMap())
}; //return a big dummy entry saying use the jboss login module that takes username/password
}
public void refresh() {
//do nothing
}
}

Basically if you pass the principal it tries to JAAS authenticate otherwise it does like normal (not shown). For authentication, it tries to load the configuration the way that LoginContext.login normally does (Configuration.getConfiguration()) and if that fails (with an IOException as the cause of a SecurityException) it passes in a dummy with the login module that just asks for username/password. No file required.

I put the details in here. Since JBoss may or may not put out a JBossAS 4.2.4, you can download the attached jar in the bug and below and follow these instructions:

  1. Do this against JBoss 4.2.3 or similar. This was compiled with JDK 1.6, if you're using an earlier version you'll have to patch it yourself. We'll also be sending 5.0 version to OSIL customers who have requested it.
  2. From the command-line, create a directory, change to it and type "jar -xf patch.jar"
  3. from that directory jar -uf $JBOSS_HOME/client/jbossall-client.jar org/jboss/naming/*.class
  4. NOTE: this assumes you use jbossall-client.jar in your client if you use all the little jars then you will have to figure out which one has HttpNamingContextFactory.class in it

Apparently JBoss's QA server is not public and they noticed a problem shutting down (noted in the bug) (public url warning loads java plugin for some reason). The only similar issue I hit in the test suite is completely unrelated and happens whether or not this patch is applied.

If you're wondering "How the heck do I run these tests now that they did all this Maven business". Maven has advanced the JBoss build to where it can no longer run the tests from the main build. You must:

  1. make sure you build jboss (build/build.sh). Go get coffee, JBoss 5's maven-based build takes 2.5 times as long to build as the 4.2 ant-based build (regardless of the dependencies).
  2. Set JAVA_HOME to wherever your JDK is located. DO NOT SET TO the place where "javac" is located (usually bin subdirectory) but the parent directory of where javac is located
  3. cd to the testsuite subdirectory of your jboss checkout
  4. type "./build.sh tests" or "build.bat tests"...it will start JBossAS by itself, you can go to sleep

This seems to be under-documented. Google found it in an unmaintained and unlinked document here. Apparently, no one ran spell check or bothered to update the document since mid-2007. You will also be wondering "so what do I check out":

On the whole, I was really kind of annoyed at the Appcelerator guys for using "git" which seemed to me to be like the bad headache when people rushed to Subversion for relatively minor benefits compared to the major headaches of the tools sucking and it being slower and project disruption in general. And Git's command line interface was designed by someone who just does not care about other people understanding what is going on. However, after having to make a relatively minor commit in 4 branches and checking out and all that. I'm all about Git. It is a big enough improvement to make the disruption and high learning curve worth it. Who the heck wants to download 4 copies of the JBoss source tree?? Git would have let me switch branches and push seamlessly.

However, as much as the JBoss 5 build annoys me with its lackluster performance, lack of documentation, lack of a single point of entry, it is far nicer than Appcelerator's rake build with that horrible build/config.yml. I got both to work of course, but I won't be converting all my projects to rake or maven anytime soon. I can see a day where I only use "Git" though.

AttachmentSize
patch.jar4.36 KB
patch.5.06 KB