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: [EMAIL PROTECTED]
> For additional commands, e-mail: jetspeed-dev-
[EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
