On 5 February 2013 02:06, Ron Monzillo <ron.monzillo_at_oracle.com> wrote:
>
> . The Servlet security model is a path model designed to secure the paths
> used to access Servlets.
> As such, it is analogous and closely aligned with the Servlet mapping model.
> In both, the
> best matching algorithm is based only on url-pattern.
And that is exactly the problem. Security constraints have 2 matching
criteria that can be specified: url and method, but only url is
actually used and the method is not a selector but a modifier of
behaviour.
This is confusing for developers and results in sets of constraints
that do not act as expected. The current proposal does not fix the
confusion, but instead just adds a mode that is a little bit less
likely for a mistake to have adverse effects. But I would
say that any change to the security model that does not fix the cause
of the problem, but just moderates the effect is just a band-aid fix.
You have made the association between constraint matching and servlet
matching. In reality the analogy should be to filter matching as
filters have both a url and a dispatch type that they are matched by.
With filters, if the path matches a request but the dispatcher type
does not, then that filter simply does not affect that request at all.
The current security model is analogous to saying that a filter at
ERROR:/foo/bar would prevent a filter at REQUEST:/foo/* from matching
a normal request to /foo/bar. That is the fundamental confusions and
changing the unexpected result from Allow to Deny is just a band aid.
If we are to change the security model, let's fix it rather than
patch it.
> . The proposal does not seek to create two models or even two modes.
But it does. Depending on the setting of a boolean a set of security
constraints will be interpreted differently. Saying that the
difference is only small does not mean that it is not a mode.
> It's
> pupose is to
> provide a simple way to cause there to be an explicit protection
> specification for all HTTP methods
> at all constrained url-patterns. Applications that follow the
> recommendations for
> defining security constraints, (e.g.,
> http://docs.oracle.com/javaee/6/tutorial/doc/gmmku.html)
> will feature no uncovered methods, and WILL BEHAVE EXACTLY THE SAME
> INDEPENDENT OF THE
> SETTING OF THE PROPOSED FLAG.
And that holds for my proposal as well. If there are no uncovered
requests, then the provisions of neither proposal come into play.
Both proposals only deal with what happens if there are uncovered
methods. The current proposal is to change the unexpected behaviour
from Allow to Deny but does not deal with the fundamental confusion.
My proposal is to allow uncovered requests to sensible fall through to
the next most specific matching constraint in a way that is logical
and simple for developers to understand. Indeed in a way that most
developers already expect it to occur.
In either case, I do not believe it is wise for us to advocate that a
deployer simply switch the boolean on a webapplication and not inspect
the actual security constraints and evaluate their behaviour. In
both cases, it may be that a deployer might have to add a few
constraints to web.xml after switching the boolean to true to correct
issues within the constraints defined within jars/fragments.
Please don't impose another band-aid fix that just adds more
complexity and does not fix the fundamental problem.
regards
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.