Archive for May, 2012

JAAS authentication and OSGi

I was looking at how to best do JAAS-based authentication in an OSGi environment, but didn’t really find much useful material, so I’m sharing my findings here in the hope that others will jump in and add anything I may have missed.

Basically what I want to achieve is being able to run the following code unmodified in an OSGi bundle, and have the login() call access the set of JAAS authentication services that are currently available in the OSGi environment. I should be able to deploy and undeploy such authentication services without any changes to this code or the configuration of the containing bundle.

LoginContext context = new LoginContext(...);
try {
    ...; // do something
} finally {

So far the best thing I’ve found is the JAAS support that Guillaume Nodet described a few years ago. If I understand correctly, the relevant code lives in Apache Karaf nowadays, even though also Apache Felix mentions it and Guillaume’s original post refers to Apache ServiceMix. I’ve given up hope trying to identify which Maven dependency I should use to get this code.

However, the trouble I see with the ProxyLoginModule class, that seems like the core piece of glue in the Karaf JAAS support, is that it requires the login() call in the client code to explicitly pass the name of the bundle and the contained LoginModule class that are to be used for authentication. That breaks my expectation of zero code or configuration changes in the client bundle for adding or removing new authentication services. Also, it looks like only a single authentication service can be used at a time.

A more promising solution is described in a presentation that was apparently given by Stefan Vladov in the OSGi Community Event 2011. However, I couldn’t find any references to actual running code that implements that solution.

Please share any relevant pointers or other information in the comments below!

Maven release builds with Jenkins and Git

We have a Jenkins continuous integration server that among other things allows us to run Maven release builds centrally using the M2 release plugin for Jenkins.

This setup worked fine with Subversion, but needed some tweaking after our recent switch to Git and github:enterprise. Here’s what I did to make it work:

  • The release plugin needs write access to the upstream repository, so I had to configure Jenkins to use an ssh key associated with a real account instead of a deploy key that only gives read access.
  • To tie the release commits to the Jenkins server, I configured the global “” and “” settings of the Jenkins account to “Jenkins” and “jenkins@…”.
  • Finally, I hit an “”ref HEAD is not a symbolic ref” error caused by Jenkins by default using a detached HEAD. A quick web search uncovered a solution as described by Stephen Connolly in a related CloudBees user forum thread. The solution was to set the “Checkout/merge to local branch (optional)” option under advanced Git settings on the Jenkins build configuration screen.

With that setup in place, we can again cut new releases with just a single click of the “Schedule Maven Release Build” button. Nice!