geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Realmless security. Was: Release 1.0 New Build Available
Date Sun, 18 Dec 2005 23:23:25 GMT
So after some IRC discussion, it looks like this is not on the table
for 1.0 (instead, we're looking at a simpler fix to reject deployments
on Jetty which have web.xml security but not geronimo-web.xml

I tried for the fix described below and I could not get it to work in
the time I spent on it.  I changed JettyWebAppContext to set a
JettyJAASRealm pointing to a non-existant Geronimo realm, and also to
construct a generic DefaultPrincipal.  Then I had to change
SecurityContextBeforeAfter.obtainUser to not blow up if there was no
set of checked and excluded permissions specified.  But it still ended
up generating a 403 for a web app with no security at all in
SecurityContextBeforeAfter.checkSecurityConstraints when it called
AccessControlContext.checkPermissions.  So I think probably
JettyModuleBuilder needs to change to apply the right JACC stuff even
if no Geronimo security information is provided.  But that's as far as
I got, so I'm not really sure.

If you can come up with a patch for this (for 1.0.1) that would be great.


On 12/18/05, Greg Wilkins <> wrote:
> Aaron Mulder wrote:
> > Well it appears that Tomcat and Jetty handle this situation
> > differently (Tomcat: all secure pages locked down, Jetty: all secure
> > pages accessible to anybody), which is *definitely* a bug...
> If Jetty is not given a realm, but is given security constraints for a
> resources, it returns a "500 configuration error".   So the Jetty plugin
> must either be giving Jetty a realm or not giving it the security
> constraints.
> From a quick look at JettyModuleBuilder, I think the security
> constraints are not being built if there is no security realm name.
> > But really, if the user put security settings in their web.xml, then
> > clearly they're expecting security to be applied.  If we disable all
> > security because they missed a deployment plan or a deployment plan
> > setting, then I think that's a huge security problem.  Gnerally
> > speaking, I think it's always best to fail to a more secure state, not
> > to fail to an "anybody authorized for anything" state.  That's
> > certainly the behavior you'd expect from your bank.
> I agree - but then 1.0 is not going to be a real production release.
> I really think it should be called a 1.0RC.
> But anyway... I'm out for a few hours and if David has not fixed this by then,
> I'll work on a fix for trunk and we can then decide if that makes it for 1.0
> cheers

View raw message