Combining Security Constraints

[Sayak Banerjee]

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:

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
 
<servlet>
<servlet-name>Servlet</servlet-name>
<servlet-class>foo.Count</servlet-class>
</servlet>
 
<servlet-mapping>
<servlet-name>Servlet</servlet-name>
<url-pattern>/Counter.do</url-pattern>
</servlet-mapping>
 
<security-role>
<role-name>Admin</role-name>
<role-name>Member</role-name>
<role-name>Guest</role-name>
</security-role>
 
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/loginPage.html</form-login-page>
<form-error-page>/errorPage.html</form-error-page>
</form-login-config>
</login-config>
 
<security-constraint>
<web-resource-collection>
<web-resource-name>SomeStuff</web-resource-name>
<url-pattern>/Counter.do</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Admin</role-name>
</auth-constraint>
</security-constraint>
 
<security-constraint>
<web-resource-collection>
<web-resource-name>SomeStuff</web-resource-name>
<url-pattern>/Counter.do</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
</security-constraint>
 
</web-app>

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) :

<security-constraint>
<web-resource-collection>
<web-resource-name>SomeStuff</web-resource-name>
<url-pattern>/Counter.do</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
 
<security-constraint>
<web-resource-collection>
<web-resource-name>SomeStuff</web-resource-name>
<url-pattern>/Counter.do</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Admin</role-name>
</auth-constraint>
</security-constraint>

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"

<security-constraint>
<web-resource-collection>
<web-resource-name>SomeStuff</web-resource-name>
<url-pattern>/Counter.do</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Admin</role-name>
</auth-constraint>
</security-constraint>
 
<security-constraint>
<web-resource-collection>
<web-resource-name>SomeStuff</web-resource-name>
<url-pattern>/Counter.do</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>

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

The tomcat-users.xml reads

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="Guest"/>
  <role rolename="Member"/>
  <role rolename="Admin"/>
  <user username="Annie" password="admin" roles="Admin,Member,Guest"/>
  <user username="Diane" password="coder" roles="Member,Guest"/>
  <user username="Ted" password="newbie" roles="Guest"/>
</tomcat-users>

Could anybody please try it out and confirm this....I'm really confused....Does the order really matter?

[Celinio Fernandes]

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]

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]

Everything is very well explained on page 639

[Johan Pelgrim]

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]

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]

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 ]