Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0-M3
-
None
-
None
Description
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.
(copied from a dev-list message)
Attachments
Issue Links
- duplicates
-
-
- Closed
-