geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jian Liao <>
Subject Re: Jetspeed 2 - Geronimo security integration (from apachecon)
Date Fri, 23 Dec 2005 01:43:20 GMT
On 12/23/05, David Jencks <> wrote:
> 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".

This could solve *JS2-238 <>*,

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.

I am wondering when will  2-a come true? I'm eager to see that ASAP.

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

View raw message