geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Created: (GERONIMO-632) Create a JACC gbean per application to manage security
Date Fri, 15 Apr 2005 05:30:21 GMT
Create a JACC gbean per application to manage security

         Key: GERONIMO-632
     Project: Geronimo
        Type: Bug
    Versions: 1.0-M3    
    Reporter: David Jencks
 Assigned to: David Jencks 

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)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message