On Aug 8, 2012, at 11:21 AM, KumarJayanti wrote:
>
>
> On Aug 7, 2012, at 7:41 PM, CASALINO, Matteo Maria wrote:
>
>> Hello Everyone,
>>
>> I believe I found a problem in the Glassfish interpretation of some combinations of security constraints in the deployment descriptor of web applications.
>>
>> In particular, the problem seems to occur whenever one or more security constraints apply to the context root of a web application (/) and other constraints apply instead to every path under the context root (/*). One such example is given by the following configuration:
>>
>> <!-- Security Constraint SC1 -->
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name/>
>> <url-pattern>/*</url-pattern>
>> </web-resource-collection>
>> </security-constraint>
>>
>> <!-- Security Constraint SC2 -->
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name/>
>> <url-pattern>/</url-pattern>
>> </web-resource-collection>
>> <auth-constraint/>
>> </security-constraint>
>>
>> According to Servlet spefication [1, 13.8.3] a HTTP request directed to the context root (such as "GET /") shall be denied in this case, since SC2 has the "best matching" URL pattern. In contrast, Glassfish allows any (even unauthenticated) requests to the context root. Notice that Tomcat behaves instead as prescribed by the Servlet specification and denies all the requests directed to the context root.
>>
>> Does anyone know if there is any explanation to this behaviour?
>
> It seems like an interesting corner case that i never experimented before, but here are some relevant points from the JSR 115 Spec and Servlet Spec.
>
> -------------------------------------------------------
> Servlet URL-Pattern Matching Rules (JSR 115)
> -----------------------------------------------
>
> this pattern is the special default pattern,"/",which matches all other patterns.
>
> Qualified URL Pattern Names (JSR 115)
> ------------------------------------
> If the pattern is the default pattern,"/",it must be qualified by every other pattern except the default pattern appearing in the deployment descriptor.
>
> Any pattern, qualified by a pattern that matches it, is overridden and made irrelevant (in the translation) by the qualifying pattern. Specifically, all extension patterns and the default pattern are made irrelevant by the presence of the path prefix pattern "/*" in a deployment descriptor.
>
> Combining Constraints (servlet spec)
> ----------------------------------
> The special case of an authorization constraint that names no roles shall combine with any other constraints to override their affects and cause access to be precluded.
> ---------------------------------------------
>
> Please note the statement above about the presence of path prefix pattern "/*" making the default pattern "/" irrelevant. So the granted.policy generated in this case for glassfish is :
>
> grant {
> permission javax.security.jacc.WebUserDataPermission "/*";
> permission javax.security.jacc.WebResourcePermission "/*";
> };
>
> And it allows access.
>
> On the other hand in SC1 if you remove the path prefix pattern and change it to something else say "/xyz" then you can see the deny behavior due to SC2 kicking in :
>
> Here is the granted.policy
>
> grant {
> permission javax.security.jacc.WebUserDataPermission "/xyz";
> permission javax.security.jacc.WebResourcePermission "/xyz";
> };
>
> and exclude.policy generated in this case :
>
> grant {
> permission javax.security.jacc.WebUserDataPermission "/:/xyz";
> permission javax.security.jacc.WebResourcePermission "/:/xyz";
> };
>
> As you can see the final result is to deny access to /xyz
Correction : i meant deny access to "/" here.
> . So i am tending to believe that GlassFish is correct in your case. I am CCing Ron who is the author of these specs for his comments.
>
> regards,
> kumar
>
>
>>
>>
>> [1] http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html
>>
>>
>> Matteo Casalino
>> Research Associate
>> Security & Trust
>> SAP Research, SAP Labs France SAS
>> 805, avenue du Dr. Maurice Donat
>> 06254 Mougins Cedex
>> T +334 92 28 - 63 42
>> E matteo.maria.casalino_at_sap.com
>> W http://www.sap.com/research
>>
>