I recently had to install OpenAM 10 over Jboss 5. While a priori easy, it turned out to be somewhat more complex than expected. First of all, the default Jboss 5 configuration must be modified in order to successfully run the OpenAM 10 wizard. On one side, there’re no special instructions neither in the official OpenAM 10 installation guide nor in the release notes, to use Jboss 5. So, I was just expecting the installation wizard to complete successfully but it was actually always failing for different reasons, with several error messages. Looking at the problem closer, it became clearer that the OpenAM 10 war file deployment was producing abnormal warnings and errors, even before executing the configuration wizard.
The fix was to modify the Jboss class loader behaviour, as documented here: OpenAM 10 deployment with Jboss 5
The second problem I met occured when trying to use a non default context root for the OpenAM configuration repository. At least, using « cn=openam » produced parsing errors later near the end of the wizard and I didn’t find any solution other than using the default « dc=java,dc=opensso,dc=net » suffix. By the way, also keep in mind that deploying OpenAM at the root of your application server (that is with a context of « / ») is not supported, while not clearly documented yet.
Let me finally mention a couple of best practices when deploying OpenAM: firstly, always leave the root realm unchanged (unless it really makes sense to customize it slightly), and rather create and customize your own sub-realm(s), in order to split the administrative tasks and configurations from your business needs. It also makes it easier to recover from a misconfiguration. Secondly, leave the agents definitions at the top realm, because they’re better managed by top level security administrators, and use referral policies to delegate access control to sub-realms.