geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: [jira] Reopened: (GERONIMO-632) Create a JACC gbean per application to manage security
Date Fri, 15 Apr 2005 17:27:28 GMT

Can you open a Tomcat JIRA issue and I will run with it?



David Jencks (JIRA) wrote:
>      [ ]
> David Jencks reopened GERONIMO-632:
> -----------------------------------
>>Create a JACC gbean per application to manage security
>>         Key: GERONIMO-632
>>         URL:
>>     Project: Geronimo
>>        Type: Bug
>>    Versions: 1.0-M3
>>    Reporter: David Jencks
>>    Assignee: David Jencks
>>     Fix For: 1.0-M4
>>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
>>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)

Jeff Genender

View raw message