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)
Message-ID: <43AC0528.9060003@douma.nu>
Date: Fri, 23 Dec 2005 15:09:44 +0100
From: Ate Douma <ate@douma.nu>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@portals.apache.org>
CC: dev@geronimo.apache.org
Subject: Re: Jetspeed 2 - Geronimo security integration (from apachecon)
References: <D4BCB514-CB41-44F3-B725-4FD4628E9BE7@yahoo.com>
In-Reply-To: <D4BCB514-CB41-44F3-B725-4FD4628E9BE7@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
Correct.


 > 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".
For Tomcat (and probably Jetty too) we can look into using that solution.
But: if we do that, we will also need to have a handling in place for
other web/app servers like JBoss, WebSphere etc.
Because we currently use our own "fake" Subject throughout, we need to make
sure replacing that with the "real" Subject will provide the same/similar
features we now rely on.

 >
 > 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.
To be precise: jetspeed provides an api (and portlets) to map role, group
and user principals to each other. This is on-the-fly, but requires a subject
(user principal) to (re)login for new (or removed) mappings to get into effect.
The same can be done with (portal/portlet) permissions assignments to principals,
*but doesn't imply it*.
Roles (nor groups) require any (explicit) permission but can be used independent.

The Portlet API defines *no* requirements/restrictions/permission for role usage.
It leaves it to the container/portlet developer how to use it and  it only
defines a request.isUserInRole('roleName') api, nothing more.

Reading the jacc specification (I'm just getting into it so bear with me if I'm
missing the finer details of the spec) it seems as it defines a role as (only) a
named set of permissions. I'm not sure we might have a definition problem here (too).

 > Here is one  way
 > to proceed that I tried to explain and I think got general  agreement
 > that it deserved at least further consideration:
Yes

 >
 > 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
I'm afraid I'm not yet convinced of that yet: this needs further investigation.

 > 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.
Agreed, for a first test setup yes.
But we require support for dynamically changing role/permission assignments
or restrictions on newly created pages for instance (which also can be done
dynamically from with Jetspeed) in a releasable version.
 >
 > 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.
Sounds good a good summary of what we've discussed so far at ApacheCon.

 >
 > If anyone finds what I am talking about unclear please ask questions,  I
 > will be happy to try to explain in more detail.
I'm looking forward working with all of you on this.

I've good hopes we can have the security integration with Geronimo working soon
and I expect the Jetspeed security implementation to improve from that
as well.

Regards, Ate

 >
 > Many thanks,
 > david jencks
 >
 >
 > ---------------------------------------------------------------------
 > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
 > For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
 >
 >
 >
 >