Ron,
Thanks for the speedy reply. Comments inline.
On 2 May 2013 23:59, Ron Monzillo <ron.monzillo_at_oracle.com> wrote:
> On 5/2/13 10:47 PM, Jan Bartel wrote:
>
> The wording of section 13.4.1 on @ServletSecurity has been updated in a
> number of places regarding @HttpConstraint with all default values.
>
> For example, pg. 127:
>
>
> The @HttpConstraint annotation is used within the @ServletSecurity
> annotation to represent the security constraint to be applied to all HTTP
> protocol methods for which a corresponding @HttpMethodConstraint does NOT
> occur within the @ServletSecurity annotation.
>
Agreed.
>
> "For the special case where an @HttpConstraint that returns all default
> values1
> occurs in combination with at least one @HttpMethodConstraint that returns
> other than all default values, the @HttpConstraint represents that no
> security
> constraint is to be applied to any of the HTTP protocol methods to which a
> security
> constraint would otherwise apply. This exception is made to ensure that
> such
> potentially non-specific uses of @HttpConstraint do not yield constraints
> that will
> explicitly establish unprotected access for such methods; given that they
> would not
> otherwise be covered by a constraint."
>
> I find this language very difficult to understand and there are no
> explicit examples of mappings to <security-constraint> that would help
> de-mystify it.
>
> Given this annotation:
> @ServletSecurity (httpMethodConstraints =
> @HttpMethodConstraint(value="GET", rolesAllowed = "R1"
> ))
>
> Does the wording of this section imply that the above annotation maps to
> a single constraint only (leaving out the <web-resource-collection> for
> brevity):
>
> yes
>
OK. Can we please have an example added to the spec then to set that in
stone.
> <security-constraint>
> <http-method>GET</http-method>
> <auth-constraint>
> <role-name>R1</role-name>
> </auth-constraint>
> </security-constraint>
>
> ?
>
> If so, what is the semantic difference to following the rules for
> mapping to <security-constraints> outlined on pg 131/132, which would
> result in 2 mappings:
>
> The pages you refer to and those in
> http://java.net/projects/servlet-spec/downloads/directory/Final
> seem to be different, but I assume you are referring to section
> 13.4.1.2 Mapping @ServletSecurity to security-constraint, which also
> descibes and relies on
> the exception you referred to above. see the text just before code example
> 13-9
>
> "When one or more @HttpMethodConstraint elements are specified, the
> method- independent constraint corresponds to a single security-constraint
> containing a web-resource-collection that contains on(e)
> http-method-omission for each of the HTTP methods named in the
> @HttpMethodConstraint elements. The security-constraint containing
> http-method-omission elements must NOT be created if the method-independent
> constraint returns all default values and at least one
> @HttpMethodConstraint does not. Each @HttpMethodConstraint corresponds to
> another security-constraint containing a web-resource- collection
> containing an http-method element naming the corresponding HTTP method."
>
> the above says that the first of the following 2 security constraints MUST
> NOT be created.
>
> <security-constraint>
> <http-method-omission>GET</http-method-omission>
> <user-data-constraint>
> <transport-guarantee>NONE</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> <security-constraint>
> <http-method>GET</http-method>
> <auth-constraint>
> <role-name>R1</role-name>
> </auth-constraint>
> </security-constraint>
>
> the purpose of the exception is to retain the ability to distinguish
> (following the mapping) those
> HTTP methods that were uncovered according to case 3 of section 13.8.4
> Uncovered HTTP Protocol Methods.
>
Ah, so the 2-statement version and the 1-statement version are indeed
*semantically* equivalent from the perspective of the container's
application of security to inbound requests. The wording of this exception
is written from the perspective of enabling the container to log a warning
about uncovered http methods. The 2-statement version produces a
constraint which relaxes access for all methods other than GET, so no log
warning would be produced according to the rules in section 13.8.4.2.
Looking again at the wording of section 13.4.1 pg 129 (sorry about page
number confusion on my previous email), I can see now that this is the
sense of it, but it was by no means clear, obvious and upfront. Can we have
a clearer re-wording of this?
Also, there is a typo in section 13.8.4.1 point #3 pg 149:
"If you can’t follow rule #2, declare constraints to cover all HTTP methods
at each
constrained URL pattern. Use the <http-method-omission> element or the
HttpMethodConstraint annotation to represent the set of all HTTP methods
other than those named by <http-method> or HttpMethodConstraint. When
using annotations, use the HttpConstraint annotation to define the security
semantic to be applied to all other HTTP methods and configure
EmptyRoleSemantic=DENY to cause all other HTTP methods to be denied."
The first reference to HttpMethodConstraint should surely be HttpConstraint
instead??
Also, I cannot see from the spec how I would create an @ServletSecurity
> annotation that permitted access to an authenticated user that was in any
> one of the roles defined for the webapp (ie the equivalent of the special
> <role-name>*</role-name>). The spec and javadoc explicitly states that
> when used in @HttpConstraint rolesAllowed or @HttpMethodConstraint
> rolesAllowed, the value "*" has no "special meaning" eg pg 133 and javadocs
> for both annotations.
>
> The use of * as a shorthand for all roles declared for the application
> has never been supported
> within @ServletSecurity.
>
Ok, but I fail to see why not. As it was so explicitly excluded, I assume
there must have been a good reason for it.
>
> If that is truly an important semantic for your app, you would need to
> explicitly list all the roles
> that are to be permitted access, or you could define your constraint in
> web.xml; where
> the role-name * has meaning.
>
I'm looking at this from the perspective of container implementer, as I am
one of the project leads for Jetty. I couldn't find any conversation in the
archives of the servlet spec 3.0 discussions to support why such an
exclusion would have been made. Jetty has not implemented this restriction
to date, thus I wanted to understand its purpose so that we could address
it if need be in our spec 3.1 implementation.
>
> With the addition of support for the ** role, applications may be less
> inclined to need to
> indicate that access is to be permitted to all roles declared for the
> application.
>
Well, they serve different purposes.
Jan
> Ron
>
> ?
>
> Jan
>
>
> --
> Jan Bartel <janb_at_intalio.com>
> www.webtide.com – Developer advice, services and support
> from the Jetty & CometD experts.
>
>
--
Jan Bartel <janb_at_intalio.com>
www.webtide.com – Developer advice, services and support
from the Jetty & CometD experts.