I cannot give you an out - of - the - box solution, but I was messing with authentication / authorization issues in combination with servlets myself, so maybe I can give you some hints.
First of all, there is a rather straight - forward article on JAAS - based authorization / authentication in combination with struts on theserverside:
I would recommend to read it. The article is based on struts, but the general techniques can be applied to any servlet, filter etc.
Second, I think you cannot really avoid working with the SecurityManager, invoked indirectly by Subject.doAsPrivileged. I was able to make a working example with JBoss LoginModules and authorization based on a JAAS - policy - file and the standard JAAS authorization methods.
If you do not want to work with policy files, you can implement your own policy provider which is responsible for reading the principals permissions. Quote from the article:
'Note: Example 8 is an example of a file based implementation of the policy. It canbe replaced with a RDBMS implementation by changing the value of the auth.policy.provider variable in the java.security file.'
But I have not tried that myself, so I cannot give you more details on this specific issue.
hope it helped,
Thanks very much for the reply.
I've read the article to which you refer many times, as I'm using Struts ;)
I'm aware that I can change the policy provider as a command line argument to java (by editing the run.sh file in the $JBOSS_HOME/bin directory). The problem that I have with that, is it bypasses the JBoss configuration for JAAS.
I was hoping JBoss (or any other J2EE server) would have some sort of hook that allowed a developer to specify a dynamic policy implementation. This would allow developers/deployers to specify that information in a jboss.xml file in an ear, deploy, and have everything work.
The approach you recommend does not allow pure ear-based deployment...you have to mess with JBoss internals (run.sh) before even starting up the server. That just adds to configuration issues for every machine I have to deploy to, which I _really_ want to avoid if possible.
Anyone know if there is a solution out there?