Anil Saldhana is the Lead Identity Management Architect at JBoss. He blogs at http://anil-identity.blogspot.com Anil has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Understanding Web Security Using web.xml Via Use Cases

02.11.2009
| 219631 views |
  • submit to reddit

The deployment descriptor, web.xml is the most important Java EE configuration piece of Java EE Web applications. The security configuration in this descriptor drives the semantics and operation of web container security. Hence it is very critical that web developers and administrators understand the various combinations possible in the security configuration in this descriptor.


Security Constraints


Security Constraints are least understood by web developers, even though they are critical for the security of Java EE Web applications. Specifying a combination of URL patterns, HTTP methods, roles and transport constraints can be daunting to a programmer or administrator. It is important to realize that any combination that was intended to be secure but was not specified via security constraints, will mean that the web container will allow those requests. Security Constraints consist of Web Resource Collections (URL patterns, HTTP methods), Authorization Constraint (role names) and User Data Constraints (whether the web request needs to be received over a protected transport such as TLS).


In this section, we will look at specifying the security constraints for multiple use cases.


Use Case: We would like to define a set of web resources that will have unchecked access. We will achieve this by omitting the authorization constrainsts (auth-constraint element).
<security-constraint>
<web-resource-collection>
<web-resource-name>All Access</web-resource-name>
<url-pattern>/unchecked/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>PUT</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
Use Case: HTTP GET operation on a set of web resources should be accessible only by an user with the role "Employee". We will achieve this with the specification of authorization constraints (auth-constraint element with the role-name element).
<security-constraint>
<display-name>Restricted GET To Employees</display-name>
<web-resource-collection>
<web-resource-name>Restricted Access - Get Only</web-resource-name>
<url-pattern>/restricted/employee/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Employee</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>

 

CAUTION Remember that in this example, you have specified a http-method of GET.  This implies that security constraint is applied to GET.  All the other http methods (POST, PUT,TRACE,HEAD etc) are open.  If you do not want the vulnerability, then do not specify a http method.

 

 

Use Case: We would like to exclude a set of web resources from any access. This can arise when a certain portion of the web application needs to undergo some form of maintenance or is not applicable for a particular physical deployment of a generic web application. We will achieve this with authorization constraints that specify no roles.

<security-constraint>
<display-name>excluded</display-name>
<web-resource-collection>
<web-resource-name>No Access</web-resource-name>
<url-pattern>/excluded/*</url-pattern>
<url-pattern>/restricted/employee/excluded/*</url-pattern>
<url-pattern>/restricted/partners/excluded/*</url-pattern>
</web-resource-collection>
<web-resource-collection>
<web-resource-name>No Access</web-resource-name>
<url-pattern>/restricted/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>PUT</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint />
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>


Authentication

A web container can authenticate a web client/user using either HTTP BASIC, HTTP DIGEST, HTTPS CLIENT or FORM based authentication schemes.

Use Case: We would like to utilize the browser authentication mechanism, HTTP BASIC as defined in the HTTP 1.0 specification.

The login-config.xml element in web.xml would look like the following:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>


Use Case: We would like to utilize HTTPS Client authentication mechanism that is based on digital certificates. The authentication is based on the user's X509 certificate.

The login-config.xml element in web.xml would look like the following:
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>JMX Console</realm-name>
</login-config>

Use Case: We would like to utilize FORM based authentication mechanism.
FORM based mechanism provides flexibility in defining a custom jsp/html page for login and another page to direct for errors during login.

The login-config xml element in web.xml would look like the following:

<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>



In this case, the html page for login is the login.html and if any errors are encountered (including failed login), the user is directed to error.html

Reference

  1. Seven Security (Mis)Configurations in Java web.xml Files


About the Author: Anil Saldhana is the Lead Security Architect at JBoss. He blogs at http://anil-identity.blogspot.com

Published at DZone with permission of its author, Anil Saldhana.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Stephane Dupont replied on Mon, 2009/03/23 - 10:22am

Hi,

your article is great but I don't understand something. I d'on't the difference beetween use case 1 and 3.

 In the first one, you say : "...define a set of web resources that will have unchecked access. We will achieve this by omitting the authorization constrainsts (auth-constraint element)."

 In the third one, you say: " We would like to exclude a set of web resources from any access..."

 I understand that in both case, we will have the same result. We will exclude a set of URL that are probably secured by another  <security-constraint> node.

Can you explain to me the exact difference between those two use case ?

I have to work in an application in which they define the security like the following and I tried your two use case and none seems to work. It always brins me back to the login page and creates a new Http session, which I don't want on certain pages

 Here is how they defined it:

  <security-constraint>
    <display-name>Toutes les ressources</display-name>
    <web-resource-collection>
      <web-resource-name>Toutes les ressources</web-resource-name>
      <description />
      <url-pattern>*.do</url-pattern>
      <url-pattern>*.jsp</url-pattern>
      <url-pattern>*.htm</url-pattern>
      <url-pattern>*.html</url-pattern>
      <http-method>GET</http-method>
      <http-method>PUT</http-method>
      <http-method>HEAD</http-method>
      <http-method>TRACE</http-method>
      <http-method>POST</http-method>
      <http-method>DELETE</http-method>
      <http-method>OPTIONS</http-method>
    </web-resource-collection>
    <auth-constraint>
      <description />
      <role-name>UtilisateurAuthentifie</role-name>
    </auth-constraint>
  </security-constraint>

Can you help me ? 

 

 

Anil Saldhana replied on Wed, 2009/04/01 - 4:14pm

unchecked access basically means allow access to every authenticated user.

 

excluded access means that certain web patterns are not available. Suppose you are vendor supplying a web application to customers A, B and C.  Customers A and C do not need certain portion of your web application (say JSPs), then you can configure the web.xml to exclude access to these resources.

Shivaji Byrapaneni replied on Thu, 2009/05/28 - 12:20am

It really helped i had a scenario in which i need to limit the access to the resources based on the role. which falls under the use case 2 you provided now i the problem is i had a login page which collects me the user id, password and triggers JAAS which returns a subject with principal (i wrote my own principal with some set of fields) which contains a role parameter. where does i required to set this role parameter so that my web.xml reads my login details for providing the acess to the resources configured in my web.xml plese help thanks in advance.

Shivaji Byrapaneni replied on Thu, 2009/05/28 - 12:16am

.

Pricy Push replied on Mon, 2010/03/22 - 7:26am

Hi, We have created an web application which gets the request parameters in the form of encrypted query string. The application decrypts the query string and use them. The encrypted query string varies dynamically with time and we are accessing it through https. At times, we are receiving forbidden error message when we access the application. We figured out that, this is because of the request validation done by the server. We use jboss server 3.0 Could you please help us with, how to disable the request validation performed by the jboss server. Or is there anyway to disable it through web.xml configuration. Thanks.

Samarth Gahire replied on Tue, 2010/03/23 - 4:41am

HI All Actually i want to give only "get" and "post" access to every user of my application and not any other access like "put" ,"delete" etc. Also i have to achive this without creating any role Is there any way to achive this using in xml? please reply soon thank you.

Ritesh Goel replied on Wed, 2010/08/04 - 1:15am

Hi, We have created an web application which gets the login parameters from Request Header. We are receiving forbidden error message when we access the application from a link. We are using WAS 6.1. we have removed the from web.xml, still that error is there. Appreciate your help. Thanks.

Dorran Anderson replied on Tue, 2010/11/16 - 11:58am

That's the clearest you could get, thanks for sharing this post! I wonder now how many application can be driven with the help of this security script and I am most interested on a list of enterprise security applications, do you have any resources on that?

Ian Wong replied on Mon, 2011/06/27 - 8:11pm in response to: Stephane Dupont

Hi Great article,

I have a question. Is it piossible to configure  <security-constraint> so that only allow particlar folders are accessible.  For example, only help files are allow to access.   

 

Zoharat Bhiwandiwala replied on Wed, 2011/07/20 - 4:07pm

We have a particular requirement where we want the security to be invoked only if a user has supplied a particular parameter in the query string. e.g. http://docfinity:9080/application/index.html?auth=kerberos#module=main I need to check if the url string contain auth=kerberos and invoke the j2EE security constraint. What will the URL pattern for this be? I have tried /application/*auth=kerberos* but it does not seem to work.

Vishal Deshmukh replied on Fri, 2012/10/26 - 8:24am

Hi,

 

First thanks for the information. I am trying to inlcude 'security-constraint' in web.xml. Following is the snippet of tags

 <security-constraint>

<web-resource-collection>

<web-resource-name>restricted methods</web-resource-name>

<url-pattern>/*</url-pattern>

<http-method>TRACE</http-method>

<http-method>PUT</http-method>

<http-method>OPTIONS</http-method>

<http-method>DELETE</http-method>

<http-method>TRACK</http-method>

<http-method>COPY</http-method>

<http-method>MOVE</http-method>

<http-method>LOCK</http-method>

<http-method>UNLOCK</http-method>

<http-method>PROPFIND</http-method>

<http-method>PROPPATCH</http-method>

<http-method>SEARCH</http-method>

<http-method>MKCOL</http-method>

</web-resource-collection>

<auth-constraint />

</security-constraint>

When I try to install the WAR containing the above web.xml on Websphere 8.0 I get the following error.

"The EAR file could be corrupt and/or incomplete. Make sure that the application is at a compatible Java(TM) Platform, Enterprise Edition (Java EE) level for the current version of WebSphere(R) Application Server.

com.ibm.websphere.management.application.client.AppDeploymentException: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.DeploymentDescriptorLoadException: WEB- INF/web.xml [Root exception is org.eclipse.jst.j2ee.commonarchivecore.internal.exception.DeploymentDescriptorLoadException: WEB- INF/web.xml] "

I searched on net but could not get the solution. Could you smell anything wrong here.

Your suggestions will be helpfull for me.

 Thanks and Regards,

Vishal Deshmukh 

 

Jessica Brown replied on Thu, 2014/03/20 - 10:45am

This information is very useful, not only for web developers but also for all those who spend a lot of time surfing the internet. Web security is more than necessary these days and like many other people, I want my data to be safe, therefore I've found on http://www.trendmicro.com/us/enterprise/challenges/it-consumerization/index.html, everything I need in order to protect my data against all kind of threats.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.