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.
>
> "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
> <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.
>
>
> 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.
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.
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.
Ron
> ?
>
> Jan
>
>
> --
> Jan Bartel <janb_at_intalio.com <mailto:janb_at_intalio.com>>
> www.webtide.com <http://www.webtide.com> -- Developer advice, services
> and support
> from the Jetty & CometD experts.