Proposed changes in security architecture

[David Jencks <da...@yahoo.com>]

It's become apparent recently that there are some deficiencies in the 
current security system, currently manifested by difficulty in 
implementing some requirements:

*  the PolicyConfigurations for the modules in an ear need to be linked
* After linking, each PolicyConfiguration needs to be committed and the 
policy refreshed
* Only after the refresh should requests be allowed to get to the new 
application.

In addition, the code to set up security is more or less duplicated in 
several places where it doesn't seem to fit very well.

After a lot of discussion and attempts to identify what was wrong Alan 
Cabrera, Jeff Genender and I have come up with a design we think will 
satisfy all the requirements and considerably simplify the code.   
Since I'm in the westernmost time zone I got elected to document it :-) 
  So, I'll try to describe it here and expect to start implementing it 
shortly.  Of course, comments and suggestions would be greatly 
appreciated.

The center of the idea is to have a new JACC gbean for each application 
or standalone module.  This will be configured by various builders at 
deploy time with all the security info for the entire application: the 
permissions for each module indexed by contextID, and the permission to 
role mappings for the entire application.  When this gbean starts it 
will create the PolicyConfiguration instances for each module, 
configure them with the appropriate permissions, add the 
application-wide permission-role mapping to each, link them all 
together, commit them, and refresh the policy.

Each module in the application or standalone module will have a 
reference to the appropriate JACC gbean, so it cannot start until after 
the JACC gbean has started: thus there is no possibility that any 
requests could get to the module before security is completely set up.

Each module will now need only to know its contextID so as to set the 
threadlocal in PolicyContext.

At least on the runtime side this will allow as a side effect complete 
pluggability of the security system.

One of the side effects of this design is that linking will have no 
effect, since the principal to role mapping will be set up for the 
application as a whole and supplied to each PolicyConfiguration for the 
app as a whole.  If there are unanticipated problems with this approach 
we can revert to having principal-role mappings per module and linking 
them.  I can't see how problems could arise since we would essentially 
be linking at deploy time rather than run time.

On the builder side of things, we will have to do two steps:
1. collect a map of contextID to permissions from the spec-dd security 
info for each module.
2. extract the principal-role mappings from either the application plan 
or the individual module plan.  We are thinking that we should allow 
only one principal - role mapping configuration either at the top level 
of an application plan or in a standalone module plan.

These would be stuffed into a GBeanData after the modules are 
configured.  Since all the module builders are run off the 
EARConfigBuilder it should be able to construct the gbeandata for both 
applications and standalone modules.

many thanks,
david jencks