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. 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".
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. Here is one
way to proceed that I tried to explain and I think got general
agreement that it deserved at least further consideration:
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 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.
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.
If anyone finds what I am talking about unclear please ask questions,
I will be happy to try to explain in more detail.
Many thanks,
david jencks
