geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jian Liao <norwaywo...@gmail.com>
Subject Re: JACC plugability etc
Date Thu, 19 Jan 2006 05:21:37 GMT
Some questions, pls see below.

On 1/19/06, David Jencks <david_jencks@yahoo.com> wrote:
>
> First of all, someone pointed me recently to https://
> openjacc.projects.dev2dev.bea.com/ which looks like it shares some
> goals with us.  I can't tell how its license affects our ability to
> use it, and would appreciate some informed opinions.
>
> I would like our JACC implementation to be plugable and extensible to
> permissions not specifically mentioned in the jacc spec such as the
> jetspeed 2 portal permissions.  I've been thinking on and off about
> this and it might even be possible.  Here are some aspects to this
> problem:
>
> - spec defined permissions, from the spec deployment descriptors.
> This can probably be used for any jacc implementation, so should
> remain in "core geronimo".
>
> - Putting the permissions from the spec into the jacc
> PolicyConfiguration.  We use the
> ApplicationPolicyConfigurationManager gbean for this now, but that
> includes also code specific to our geronimo jacc implementation.
> Perhaps this can be split into 2 gbeans or a base gbean with the spec-
> required behavior can be written.


1. User can write an J2PortalPolicyConfigurationManager to config  J2
specific perssioms. Do I have to extend from the base one?

2. J2PortalPolicyConfigurationManager just add J2 specific permissions to
the corresponding policyConfiguration instance?

3. Will J2PortalPolicyConfigurationManager be used to support dynamic
policyConfiguration update? like remove, add or change a permission in
runtime?

- Our plans include xml for a role >> principal mapping which is
> specific to our jacc implementation.  This info is added to the
> ApplicationPolicyConfigurationManager as well.  The use of our schema
> is hardcoded in our j2ee plans, but this could be turned into a
> namespace-driven choice of security builders.
>
> So, what I'm thinking of is something like:
>
> - define a SecurityBuilder interface primarily for the non-spec parts
> of the security setup.  The various j2ee builders can call into it at
> appropriate times.
>
> - selection of a SecurityBuilder relates to configuration of the
> server, since it reflects the Policy installed.  I don't see how to
> have several JACC implementations running at once.  Each
> SecurityBuilder would presumably have its own namespace. Perhaps we
> can select the SecurityBuilder based on namespace, but this would
> push the discovery of incompatibility in JACC implementation to
> runtime.  This might or might not be acceptable or the best idea, I'm
> not sure.
>
> - the SecurityBuilder would be responsible for adding the
> ApplicationPolicyConfigurationManager-like gbean to the
> deploymentContext and building up its configuration.
>
> - as now, when the app starts, the
> ApplicationPolicyConfigurationManager gbean will configure the JACC
> PolicyConfiguration appropriately for its jacc implementation.
> Presumably it will need to object if it finds the wrong jacc
> implementation installed.
>
> Comments? Objections? Questions?
>
> thanks
> david jencks
>

Mime
View raw message