WebSphere Liberty NoopUserRegistry Add-On

WebSphere Liberty 8.5.5.6 has a bug in the implementation of JASPIC that prevents developers from making their own modules that do not have a user realm that is managed by WebSphere’s UserRegistry.  To work around it I took some hints on Arjan Tijms’ work testing with JASPIC on WebSphere Liberty and combined it with my knowledge of Maven and OSGi.

Suffice to say most of the code is his, I had removed his BundleActivator and used OSGi Declarative Services to do it in addition, I had maven-ized the project and documented the instructions on how to create a WebSphere Liberty Add-on previously.

One key difference was the way groups are handled. In an authorization check scenario the methods that get called in the UserRegistry are as follows:

  1. initialize()
  2. isValidUser(username)
  3. isValidGroup(groupname)
  4. getUniqueGroupIds(username)

The getUniqueGroupIds needs to return the set of group names associated with the user in order for the group to role binding to work correctly. So the main change from Arjan’s code was to make sure it does not return an empty list. To do that, a ThreadLocal Set is created that would keep track of the groups being checked by isValidGroup and add it to the set. then getUniqueGroupIds simply returns the set wrapped in an ArrayList.

ThreadLocal was done with the assumption that the UserRegistry has a limited life span and is recreated as needed for a transaction. It may be that there’s only one, but I didn’t have a test for that in which case any group that was asked would pass. Normally that would be a security hole, but since this is just a work around to begin with the point is moot.

  • Tom McManus

    On Friday 16.0.0.2 of Liberty will be released. This should be resolved for you.. https://developer.ibm.com/wasdev/downloads/. You could probably test this on on the .Java Liberty runtime on bluemix.net, since 16.0.0.2 build pack is available. Just package your application and cf push to Bluemix.

  • Tom McManus

    Correct