Before I started this thread, I noticed the JACC provider was configurable in domain.xml. I made a note to look into it and glanced over some of the code for the default one, but it was a little intimidating. I couldn't find much information about it and I wasn't sure if it was key to solving this or not. The In-Memory provider sounds promising. I'll have a closer look at it next week, thank you for pointing it out!
To answer your questions:
1. Yes, the users and their group memberships do change.
2. The set of groups changes also. We install the application with only an administrative group and user. All other groups are defined by the customer using the application and the roles assigned to them are different at every install site. Giving the customer the ability to change the roles for a group is the key issue here. To allow it that relationship has to be dynamic (in our case, it's already represented in the database).
3. The set of available roles is static for each of the modules.
This is where things get a little more complicated. Our application has many different war/ear modules that deploy into a larger application framework, each one has a static set of roles relating to its functionality. When the application starts up a ContextListener registers each one with a central dashboard module (runs at the root context). In some cases, runtime settings can prevent a module from being deployed. If launch conditions aren't met, the module (and its roles) will not be registered. Once the application has fully started, the dashboard will have a master list of all the active roles.
Also, since each module is a different war/ear we have to use the SingleSignOn valve in Catalina. I read somewhere that Glassfish supports a similar behavior but I haven't tried to configure or test this yet. I can't get far enough into the application to even worry about it, if I can't get authorization to work. :)
--pw
[Message sent by forum member 'pwardrip' (pwardrip)]
http://forums.java.net/jive/thread.jspa?messageID=321544