Realmless security. Was: Release 1.0 New Build Available

[Greg Wilkins <gr...@mortbay.com>]

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

Re: Realmless security. Was: Release 1.0 New Build Available

[Aaron Mulder <am...@alumni.princeton.edu>]

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
security).

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.

Thanks,
    Aaron

On 12/18/05, Greg Wilkins <gr...@mortbay.com> 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
>