Servlet Declarative Security Notes

web-resource-collention> has NO http-method> sub-element

Scenario-I

WithOut auth-constraint> sub-element of security-constraint> element:
Everyone are allowed; Anyone in any role has access to the resource specified by the url-pattern> sub-element. The browser will NOT demand UserName/Password.

Scenario-II

With auth-constraint> sub-element of security-constraint> element:
All request to the specified resouce(all Http methods since there is no http-method> sub-element available) identified by the url-pattern> sub-element will be Constrained. The browser will request UserName/Password. Any request without correct UserName/Password will fail to get access to the resource.

web-resource-collention> has http-method> sub-element

Scenario-I

WithOut auth-constraint> of security-constraint> element:
Everyone are allowed; Anyone in any role has access to the resource specified by the url-pattern> sub-element. The browser will NOT be asking for UserName/Password

Scenario-II

With auth-constraint> sub-element of security-constraint> element:
All request to the specified resouce identified by the url-pattern> will be Constrained. The browser will request UserName/Password. Any request without correct UserName/Password will fail to get access to the resource.

NOTE:

The auth-constraint> element does NOT define which roles are allowed to access the resources defined in url-pattern>. Instead, it defines which roles are allowed to make the constraint request. Don't think Bob is a member, so Bob can access the AddRecipe servlet. Instead, say "Bob is a Member, so Bob can make a GET o POST request on the AddRecipe servlet.

If you specify an http-method> element, all the HTTP methods which you didn't specify are UNConstrained.

Check this Thread