geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <...@geronimo.apache.org>
Subject [jira] Reopened: (GERONIMO-632) Create a JACC gbean per application to manage security
Date Fri, 15 Apr 2005 05:41:18 GMT
     [ http://issues.apache.org/jira/browse/GERONIMO-632?page=history ]
     
David Jencks reopened GERONIMO-632:
-----------------------------------


> Create a JACC gbean per application to manage security
> ------------------------------------------------------
>
>          Key: GERONIMO-632
>          URL: http://issues.apache.org/jira/browse/GERONIMO-632
>      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
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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message