geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Jetspeed 2 - Geronimo security integration (from apachecon)
Date Fri, 23 Dec 2005 20:32:57 GMT

On Dec 23, 2005, at 6:09 AM, Ate Douma wrote:

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

I am speculating, but I think one possible outcome (possibly for the  
distant future) might be something like:

-jetspeed only provides security on platforms with a jacc implementation
-jetspeed uses the jacc mechanism to insert and modify the role- 
permission mappings
-jetspeed provides, as one choice, a JAAS login module that produces  
jetspeed-friendly principals for easy role-principal mapping
-jetspeed relies on the jacc implementation for the actual role- 
principal mapping.

I haven't investigated but I would hope that this would let the jacc  
framework implement all or most of isUserInRole.

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

My understanding of this is that it requires use of a jetspeed- 
specific login module or at least one that adds jetspeed-specific  
principals to the JAAS Subject.  I suspect this may not be  
appropriate for all deployments, such as ones using an existing ldap  
system.

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

I know nothing about the plans for the portlet 2.0 spec, but I wonder  
if defining a set of portlet permissions and a role-permission  
mapping analogous to those for web apps and ejbs would be a  
reasonable goal.

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

I think the jacc spec takes a quite different view than the current  
jetspeed implementation.  I would say that a (jacc) role is an object  
scoped to a j2ee application whose only attribute is its name.  The  
web and ejb spec deployment descriptors define (abstractly, and as  
specified in detail in the jacc spec) a role to permissions mapping.   
The jacc spec does not indicate or specify the  Subject/Principal to  
role mapping.  It does specify an api whereby the algorithm that  
determines permissions can use the invocation information (request  
for web apps, ejb method name and args for ejbs, etc) in the  
authorization decision.  Currently the Geronimo implementation  
defines a static role-permissions mapping that can only be changed at  
deployment time.  This information from the geronimo plan is combined  
with the spec-dd specified role-permissions mapping to make a  
principal-permissions map which is actually used in authorization  
decisions.   Geronimo is not currently using the invocation  
information in authorization decisions.

IIUC the jetspeed view of a role is an instance of a specific  
Principal class.  While this simplifies some parts of security setup,  
I think it will cause problems in some environments.

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

I'd like to understand a lot more about the use cases here, and if  
there are any docs please point me to them :-)  Some of my questions  
are:

- do the portal/portlet permissions apply to the portal app or the  
portlet app deployed in the portal?
- Where do new portlet pages come from (and are they portlet pages or  
portal pages)?  Can they be added to a running system or do they  
require (re)deployment of a portlet application?  Are they additional  
portlets or servlets that should be represented in the portlet.xml or  
web.xml deployment descriptor or are they representable as additional  
parameters to an existing portlet or servlet?

- In the existing jetspeed implementation, what kind of  
"transactional" behavior is there to allow applying a set of security  
changes at once?

- Are the contents of the request needed to make authorization  
decisions?


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

Likewise!

thanks
david jencks

>
> 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
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>


Mime
View raw message