• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Combining Security Constraints

 
Sayak Banerjee
Ranch Hand
Posts: 292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm getting results quite different from that mentioned in the servlet spec. 2.4 and the HFSJ book while combining security constraints. I'm using Tomcat 5.0.28/Win XP...Is anyone else gettin' the same thing? Here are some of the differnces:-

1.>In the servlet spec. (page 97) it says:

A security constraint that does not contain an authorization constraint shall combine with authorization constraints that name or imply roles to allow unauthenticated access.


But when I implement this the request is still being authenticated...My DD reads:


2.> In the spec(page 98) it says (and so does HFSJ) :
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.


Now when my DD reads (here I'm showing only the relevant parts) :



it obeys the spec. and does not allow access to any one in any role...

BUT if I just change the order of the 2 <security-constraint> elements in the DD as shown below then it allows any body with role "Admin"



3.> I'm gettin similar things on changing the order with other combos as well...

The tomcat-users.xml reads


Could anybody please try it out and confirm this....I'm really confused....Does the order really matter?
 
Celinio Fernandes
Ranch Hand
Posts: 549
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Everybody has access
2. Nobody has access, in both cases, whatever the order is.

In any case, you should not spend too much time on this matter, you might have some caching problem or something related to the container.
I personaly hate that part of the deployment because it makes you waste a lot of time figuring out what could possibly be wrong.
 
Sayak Banerjee
Ranch Hand
Posts: 292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, Celinio, you're probably right....And I hate these container specific issues....just to make this sure abotu the <security-constraint> elements combination result(irrespective of order) for one final time....

1.> any 2 <security-constraint> elements with non-empty <auth-constraint> sub-elements(including one with <role-name>*</role-name> --> union of the 2

2.> <security-constraint> with no <auth-constraint> sub-element with any other <security-constraint> element(except one with <auth-constraint/> --> unauthenticated access

3.> <security-constraint> with <auth-constraint/> sub-element with any other <security-constraint> element--> no access to any one

Am I right?
 
Celinio Fernandes
Ranch Hand
Posts: 549
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Everything is very well explained on page 639
 
Johan Pelgrim
Ranch Hand
Posts: 105
Android Java Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sayak,

I thought I had the answer. You are using the same web-resource-name SomeStuff for both web-resource-collections. This name should be unique. I thought this was why one definition was overwriting to other... But that didn't work out.

So... Tomcat doesn't seem to adhere to this bit of the spec and order does matter?! Most disturbing in my view. A Tomcat implementation bug? This does not help me committing this rule to memory
[ December 12, 2006: Message edited by: Johan Pelgrim ]
 
Sanjeev Ba
Ranch Hand
Posts: 40
Android Chrome Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Everyone,

Thanks so much for sharing your thoughts on this one.

So, as far as I understand, this is what will happen.

<auth-constraint>*</auth-constraint> & <auth-constraint/> = NO BODY
NO <auth-constraint>& <auth-constraint/> = EVERY BODY

Am I right?

Regards
Sanjeev
 
Sayak Banerjee
Ranch Hand
Posts: 292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
NO <auth-constraint>& <auth-constraint/> = EVERY BODY

That's wrong....it's NOBODY

I've mentioned clearly what the spec. says....please try and adhere to the spec.
[ January 03, 2007: Message edited by: Sayak Banerjee ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic