Hi Greg. I'm not aware of all the background here but my understanding
is that the Servlet expert group has seen this proposal of yours before.
Your proposal is a different matching algorithm to determine which
security constraints apply to which http requests. I understand that
you believe it is more intuitive, but I'm not seeing any support for
this different model from other members of the Servlet expert group.
In any event, it's getting pretty late in this release to consider
such a significant change. As Ron has described, our proposed change
does not change the matching algorithm at all, and so is a somewhat
simpler change to introduce at this late date.
Given that the platform expert group widely support our proposed change,
and that there's no support even in the Servlet expert group for your
change, I think we need to go ahead with our change as proposed.
If you still think a more significant change is desirable, feel free to
bring it up again for Java EE 8.
Thanks.
Greg Wilkins wrote on 02/04/13 16:21:
> 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
>
>