• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question on multiple security-constraint elements

 
Jim Olsen
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am testing the following in my DD, I'm not seeing the results I expect:

<security-constraint>
<web-resource-collection>
<web-resource-name>Testing2</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>

<security-constraint>
<web-resource-collection>
<web-resource-name>Testing1</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>

I would expect the empty auth-constraint element in the second security-constraint to cause access, even by those in the admin role, to be precluded. What I'm seeing, however, is that admins do have access. If I reverse the order of the security-constraint elements, then I see the behavior I expect.

What's going on in this situation?
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't understand a couple of things:

1) The order of the <security-constraints> matters!! I tried your code in Tomcat and you are right in what you said.

2) What's the meaning of the absence of <http-method> in the <web-resource-collection>?
According to the confirmed errata of HFSJ (p. 634): "If there are NO <http-method> elements, in the <web-resource-collection>, it would mean that ALL HTTP Methods are allowed."
The behavior in Tomcat is the opposite: the absence of <http-method> elements mean that all HTTP methods are constrained.
Unfortunately, Servlet spec don't say anything about it (at least, I haven't found it).

Any help would be appreciated.
 
Bassam Zahid
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to my experience I found that when there are no <http-method> elements, the access is granted to *ALL* http methods. I've tested this on Tomcat 5.5.7, Resin 3.10 and SJAP 8.
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have tried several security configurations under Tomcat 5.0.25.

The authentication method I use in web.xml is BASIC:

The request method is GET.

These are my tests with several configurations of the <web-resource-collection>:

1) <web-resource-collection> with <http-method>GET</http-method>

Result: access to the resources is constrained (for the GET request). It is the expected result.

2) <web-resource-collection> with <http-method>POST</http-method>

Result: access to the resources is *NOT* constrained (for the GET request). It is the expected result.

3) <web-resource-collection> with **NO** <http-method>

Result: access to the resources **IS CONSTRAINED** (for the GET request). It is **NOT THE EXPECTED** result according to Bassam's post.

Any explanation?

[ April 02, 2005: Message edited by: Jose Esteban ]
[ April 02, 2005: Message edited by: Jose Esteban ]
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Come on, boys! Isn't this an interesting question?

I think it is. There's two questions without answer about the security-constraint element:

1) In the case of multiple security-constraints, the order of them is RELEVANT!! I think that it is incredible! It requires an explanation or, at least, experimenting on it.

2) What's the meaning of the absence of <http-method> in the <web-resource-collection>? Bassam's results say one thing, my results say the opposite. What's the correct answer.

More opinions and results will be appreciated.

Thanks.
 
Praveen Kumar Mathaley
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
instead of breaking heads over the implementation, it's better to stick to the specification which says the access is precluded...
i.e. no one will be having access... and this should be the behaviour...

and also if the http method is not there then constraint is applied to all methods...
so i assume according to specs the above confusion is resolved...
[ April 05, 2005: Message edited by: Praveen Kumar Mathaley ]
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Praveen Kumar Mathaley:
instead of breaking heads over the implementation, it's better to stick to the specification which says the access is precluded...
i.e. no one will be having access... and this should be the behaviour...

and also if the http method is not there then constraint is applied to all methods...
so i assume according to specs the above confusion is resolved...

Excuse me Praveen, but when anybody says that "according to specs the above confusion is resolved", it is a GOOD PRACTICE to give the exact reference.

If you have read the thread, in my first post I say: "Unfortunately, Servlet spec don't say anything about it (at least, I haven't found it)."

1) How can you explain the results obtained in the first question? Of course, we know that SRV.12.8.1 says: "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.". Then, is Tomcat implementation wrong? Are Jim and me making a mistake in our tests (probably)? That's what we are looking for: what's wrong.

2) Please, where in the spec is said anything about the second question in discussion.

I'm waiting anxiously for your answer.
[ April 06, 2005: Message edited by: Jose Esteban ]
 
Praveen Kumar Mathaley
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am sorry,
here's the reference it's on page 133 of servelt spec 2.4,
here's the text on that page...

The web-resource-collectionType is used to identify a subset
of the resources and HTTP methods on those resources within

a web application to which a security constraint applies. If
no HTTP methods are specified, then the security constraint
applies to all HTTP methods.
Used in: security-constraint

also sorry for the delayed reply, it's delayed bcos of time difference ( timezone..)
[ April 06, 2005: Message edited by: Praveen Kumar Mathaley ]
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Praveen Kumar Mathaley:
If no HTTP methods are specified, then the security constraint applies to all HTTP methods.

Thanks Praveen.

This resolves the second question. This result is against HFSJ's errata and against Bassam's experience. It is in agreement with HFSJ original text and with my tests using Tomcat.

The first question:
1) In the case of multiple security-constraints, the order of them is RELEVANT!!
is still open. Has anybody tried to reproduce the situation in the first post of this thread? I think there must be an error somewhere because, as far as I know, this is against the spec.

Thanks.
[ April 07, 2005: Message edited by: Jose Esteban ]
 
Jeff Moszuti
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jose

The first time I tried it out, I got the same result as Jim but this was due to the resource being cached by my browser. After clearing my browser cache,
a user with admin role is precluded from accessing a resource, *regardless* of the ordering of the security-constraint elements.
I tried Jim's example on Tomcat 5.0.28.

Hope this helps

Jeff
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff, thank you very much for your answer but, in Tomcat 5.0.25 I don't get what you said.

I've even tried with different browsers (IE and Firefox, without caching) and I always, always get Jim's results.

Thank you anyway for being curious about what's happening.
 
Jeff Moszuti
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Opps, I was only checking to see whether the browser pops up a box to prompt the user for a password. However, after entering a valid username and password, the user with 'admin' role *is* granted access to the protected resource.

After a quick peek through the Tomcat 5 source, I found that the method which grants resource permission



simply loops through the array of constraints verifying each constraint one after another. If the user has a matching role, the loop exits (ignoring the remaining constraints) and access to the resource is granted. Because constraints are verified one by one as opposed to the global policy, the ordering of security constraints does have an effect on what is precluded.

So I would say that this _feature_ of Tomcat doesn't quite follow the 2.4 Servlet Spec but for the purposes of studying for the SCWCD exam, it's best to take the Spec as gospel.

Jeff
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great job, Jeff!!

Your post clarifies what was happening.

Thanks again.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic