Re: JACC plugability etc

[Jian Liao]

Some questions, pls see below.

On 1/19/06, David Jencks <[EMAIL PROTECTED]> 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