Difference between empty auth-constraint and no auth-constraint.

[Sanjeev Ba]

Hello Ranchers,
I wanted to know the effect of having two sercurity-constraint elements in the DD one with an empty <auth-constraint/> = allowing no one and the other with no auth-constraint element.

Is the result, allow everyone or allow no one? Which one takes precedence.

Also, I observed that there is some issue with the evaluation part of Whizlabs simulator. I does not exactly calculate the number of right answers properly. Has anyone else faced the same issue? I am using the trial version.

Thanks and Regards
Sanjeev

[Gowher Naik]

I tried <auth-constraint/> and no auth-constraint and i found it allows everyone.

[Niranjan Deshpande]

empoty <auth-constraint/> - NO one is allowed

no auth-constraint - every one is allowed, its same as
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>

[Sanjeev Ba]

Thanks Gowher for quickly testing it out.

Regards
Sanjeev

[Sayak Banerjee]

I tried <auth-constraint/> and no auth-constraint and i found it allows everyone.

Well, that's not possible.....could you please post the code for the DD?

<auth-constraint/> means no access to no one.


Also,

no auth-constraint - every one is allowed, its same as
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>

<auth-constraint> element missing is not exactly the same as
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>

Though everyone is allowed in both cases, the former one allows unauthenticated access
[ January 02, 2007: Message edited by: Sayak Banerjee ]

[Gowher Naik]

[code]
<web-app...>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>tomcat</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>MySecureWebResource</web-resource-name>
<http-method>GET</http-method>
<http-method>POST</http-method>
<url-pattern>/start.jsp</url-pattern>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>MySecureWebResource</web-resource-name>
<http-method>GET</http-method>
<http-method>POST</http-method>
<url-pattern>/start.jsp</url-pattern>
</web-resource-collection>
<auth-constraint/>
</security-constraint>

</web-app>
The above code from DD allows both admin and tomcat users.

[Gowher Naik]

<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>tomcat</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>MySecureWebResource</web-resource-name>
<http-method>GET</http-method>
<http-method>POST</http-method>
<url-pattern>/start.jsp</url-pattern>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>MySecureWebResource</web-resource-name>
<http-method>GET</http-method>
<http-method>POST</http-method>
<url-pattern>/start.jsp</url-pattern>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
 

Above code allows both tomcat and admin users.

[Sayak Banerjee]

There you go man.....I was pretty sure that you were combining constraints.....The information that I provided was about a single <security-constraint> element in the DD....

Tomcat 5.0.X does not strictly adhere to the spec. as far as combining <security-constraint> elements are concerned.....I dunno if they've corrected it in version 5.5.X but I had the same problem when using version 5.0.28....You can check this ISSUES WHEN COMBINING CONSTRAINTS

[Sayak Banerjee]

As for the question originally asked by Sanjeeva,

Hello Ranchers,
I wanted to know the effect of having two sercurity-constraint elements in the DD one with an empty <auth-constraint/> = allowing no one and the other with no auth-constraint element.

Is the result, allow everyone or allow no one? Which one takes precedence.

Answer is (according to the spec.) : - No access to no one

[Joe San]

Sayak,

How come <auth-constraint/> and no auth-constraint will give access to no one?? I feel that it will give access to everyone. The no auth-constraint overrides <auth-constraint/>. Can anyone please give me the spec reference here?? Please!

[Gowher Naik]

SRV.12.8.1
A security constraint that does not contain an authorization constraint shall combine with authorization constraints that name or imply roles to allow unauthenticated access. [B]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.[/B]

From above specification i think no one will be allowed.

[Joe San]

Gowher,

Your replies contradicts...

Your pfirst post says "I tried <auth-constraint/> and no auth-constraint and i found it allows everyone."

and

The above one says, from the servlet spec that no one is allowed. So servlet spec is the final and no one will be allowed is the conclusion for the above original question by Sanjeev.

Thanks ranchers.

[Gowher Naik]

This problem has occured before also
Check this PostSecurity
So i will go with specification.