This attached patch adds security to the console-standard context
- adds a security constraint to console-standard that requires admin
role priveleges to access any resource. The auth method is set to
BASIC, but it could have just as well been set to any other
type since console users aren't expected to reference that
web-app directly from their browsers (except for the DWR servlet,
but I'll get to that).
- adds a servlet to console-framework that forwards requests of
the form /console/dwr/X to /console-standard/dwr/X. By the
time this servlet is accessed the authorization has been
established so forwarding the request internally into the
console-standard context propagates the principal
across the contexts. (effectively a poor man's version of single
- adds a security constraint to console-framework that requires
admin priveleges to access the new servlet described above
- updates console-framework/project.xml to build the new servlet
- adds a filter to the console-standard web-app that intercepts
requests made to the existing dwr servlet (forwarded via the new
servlet in mentioned above) and maps the original request
attributes back into the request. This is done so that the DWR
servlet can build self-referrential URLs (which it does by
querying the attributes of the request) that are routed back
through the console-framework webapp and are thus authenticated.
- updates the tomcat and jetty console plans to enable the
geronimo-properties-realm on the console-standard context
- updates the Information portlet to route its AJAX/DWR requests
through the new servlet in console-framework mentioned above
This patch was tested on the 1.0 branch and it applies OK to HEAD
but I had compile problems in the security-builder module (not
caused by this patch) and couldn't test it out. I will keep trying
to build head and test asap.
Other approaches to address this issue that were investigated and
- enable the single signon valve in the web container configuration.
works great but is a server wide setting, which is not desirable.
There may be some way to scope the valve to a groups of contexts
but AFAIK this would still require altering the web container's
configuration to accomodate the admin console, which IMO is not
- use BASIC authentication instead of FORM authentication. enables
authentication to work cross context since both context prompt
for the geronimo-properties-realm domain which the browser can
provide across all contexts. But forces the console to use the
browser's popup dialog instead of the nice login page, which
again is not desirable
- merge console-standard and console-framework into a single webapp.
I didn't even try this since, architecturally, I wanted to remain
as close to the "standard" pluto configuration as possible since
Geronimo may soon upgrade to pluto 1.1 and/or jetspeed 2.0
- move the DWR servlet into console-framework webapp. This approach
would be easier to implement and require fewer changes (no new
servlet or filter). But longer term there will be more AJAX
enabled functions in the console and creating a classloader
boundary between the UI code and DWR (or whatever AJAX impl gets
plugged in) will cause problems.
- implement a custom realm gbean that allows users that have
authenticated to one console context to automatically get
access to the other (unchallenged). didn't get very far with
that idea - don't think its possible since there's no access to
the HTTP requests,context,etc