Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:Content-Transfer-Encoding:Message-Id:Content-Type:To:From:Subject:Date:X-Mailer;
  b=YhfocF9TYnWCRrYTO2RvxwGJth+DVVf46SLPw53K+x12OnFQo2Bq/scaY1DJxKULvSU/bmTUqoYMiLP4CKAnV6cRM8iM+ugaNfJ4yVmR+pWtm0fun1rU8tl4XEhCh4xNbXLErFNCwNbeve/EGk1TszGKjE2wiAmEFj0kz2fvQ1Y=
  ;
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <07307D74-2169-4CFA-9CC9-57DCB62C0351@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: dev@geronimo.apache.org
From: David Jencks <david_jencks@yahoo.com>
Subject: JACC plugability etc
Date: Wed, 18 Jan 2006 10:47:19 -0800

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.

- 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