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
