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=a5+ctubxm2wqeh630JsLVXgiV09kZpydleO055yJSRXW6qCXZJ6sk7HyTZXj1EHoAEnNlJwZ1yiJFkhvXGv8K7EOYT2of2IzMpoMueJLYWZDWz/pDjTML9glLpg6TR6e9VDBdgn82O8v+BMP0YFdmoWzaiOfVayCwX26kkjIVcs=
  ;
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <D4BCB514-CB41-44F3-B725-4FD4628E9BE7@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: dev@geronimo.apache.org,
 Jetspeed Developers List <jetspeed-dev@portals.apache.org>
From: David Jencks <david_jencks@yahoo.com>
Subject: Jetspeed 2 - Geronimo security integration (from apachecon)
Date: Thu, 22 Dec 2005 15:05:01 -0800

At Apachecon some Jetspeed and Geronimo committers got together and  
discussed Jetspeed 2 - Geronimo security integration a bit.  Here's  
what I remember: please chime in if you remember more/differently.

People:  David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,  
David Jencks and ???

1. Jetspeed in tomcat is currently creating a separate "jetspeed  
subject" because it isn't clear how to get the JAAS subject that  
tomcat creates for use in jetspeed security.  In geronimo we create a  
special Principal that has a reference to the Subject  
(JAASTomcatPrincipal).  Probably Jetspeed can use the same idea in  
Tomcat to get the JAAS subject and avoid the "fake login".

2. IIUC correctly jetspeed security currently requires a login module  
to use specific principal classes, and there is a direct mapping  
between instances of these classes and jetspeed portal/portlet  
permissions.  This is not very j2ee-like, at least as geronimo  
interprets it :-)  In particular it seems excessively restrictive to  
require the use of specific principal classes.  On the other hand  
jetspeed implements an on-the-fly permissions-changing facility that  
will take some work to fit into a jacc-like structure.  Here is one  
way to proceed that I tried to explain and I think got general  
agreement that it deserved at least further consideration:

a. In analogy to the role-permissions mapping specified for web apps  
and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a  
(presumably xml) jetspeed specific deployment descriptor.  With a  
suitable deployer this can be fed into a jacc-compliant app server:  
in geronimo this can be fed into PolicyConfigurationGeneric.  In j2ee  
such a mapping is static, part of the original deployment descriptor,  
and cannot be changed without redeploying the app.  I'm inclined to  
think that such a restriction may also work for jetspeed but don't  
have enough info for my opinion to count for much.  I think  
implementing this as a first step would be a good idea.

b. Use the existing geronimo specific role-principal mapping to  
connect the principals created by an arbitrary login module with the  
roles set up in (a).  This would result in jetspeed security being  
integrated into the existing geronimo jacc security framework.   
However, it would not immediately result in being able to change  
permissions without redeploying the application.

c. Investigate how to make this more dynamic.  One possibility is to  
simply use the jacc facilities, which involve opening the policy  
configuration (at which point it is taken out of service and no  
requests can get through), modifying it, and committing the changes  
(at which time it is put back into service and the new policy rules  
are in force).  It is not entirely clear to me if the requests made  
while the configuration is open can be made to wait or if they must  
be refused.  I do think that some kind of transactional change  
mechanism is needed so that many changes can be made in one operation.

If anyone finds what I am talking about unclear please ask questions,  
I will be happy to try to explain in more detail.

Many thanks,
david jencks