David Jencks wrote:
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.
I can't really oversee it yet either, but if this all could be done as you
proposes but it really sounds promising.
>
> 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.
Why not?
I know some use ldap with Jetspeed so (some of) it should be possible, although
I haven't tested or used it myself.
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.
Well, both David Sean Taylor and myself are part of the portlet 2.0 spec
Expert Group ;-)
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.
Ok. I'm open to see how we can improve/correct this, hopefully in a way which
still supports our current security handling.
> 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?
Both: we have portlet permissions (portlet app) and also something like page
permissions
(portal app).
- 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?
"Portlet" pages as such do not exists, although we support a specific
invocation for
only one portlet output in a request (a jetspeed specific feature).
A "Portal" page is deployed to/managed by the portal.
Currently, there is no formal deployment model or dd for it and the portlet spec
says really *nothing* about a page other than it can contain/represent one or
more
portlets (which may originate from different portlet apps).
- In the existing jetspeed implementation, what kind of "transactional"
behavior is there to allow applying a set of security changes at once?
We control this ourselves through Spring configured transactions. Can be a
single or multiple
changes, depending on our configuration.
- Are the contents of the request needed to make authorization decisions?
I'm not sure I understand what you mean here.
Request/query parameters?
In that case, I think not, but maybe Randy Watler and/or David Sean Taylor
should respond
to this one.
>
> 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
Thanks for the support David, I know you planned to take some time off these
days.
I will be mostly offline the next few days, so a next response might take some
time.
Take care and Happy Christmas anyone!
Regards, Ate
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
