How do I secure servlets with declarative security in web.xml

Securing servlets with declarative security in the web.xml deployment descriptor is an essential practice in Java web applications. It allows you to define security constraints without writing specific code, instead leveraging the standard configuration mechanism in web.xml. Here’s how you can do it step-by-step:


1. Define a Security Constraint

The <security-constraint> element is used to define access rules (restrictions) for specific URL patterns or resources.

<security-constraint>
    <display-name>Protected Area</display-name>
    <web-resource-collection>
        <web-resource-name>ProtectedServlet</web-resource-name>
        <url-pattern>/protected/*</url-pattern>
        <http-method>GET</http-method>
        <!-- You can specify other methods like POST, PUT, DELETE, etc. -->
    </web-resource-collection>
    <auth-constraint>
        <!-- Specify user roles allowed to access these resources -->
        <role-name>ADMIN</role-name>
    </auth-constraint>
</security-constraint>
  • <web-resource-collection>: Defines which resources (e.g., servlet paths or URL patterns) are protected.
    • Include one or more <url-pattern> sub-elements for specific paths.
    • Use <http-method> if you want to secure specific HTTP methods (e.g., GET or POST).
  • <auth-constraint>: Specifies the roles allowed access to the protected URL patterns. Define roles in the <role-name> tag.


2. Configure the Authentication Mechanism

The <login-config> element specifies the type of authentication and the location of the login pages (if required).

<login-config>
    <auth-method>BASIC</auth-method> <!-- Can be BASIC, DIGEST, FORM, CLIENT-CERT -->
    <realm-name>MySecureRealm</realm-name>
</login-config>
  • Auth Methods:
    • BASIC: Uses the browser’s built-in login dialog.
    • FORM: Uses custom login and error pages defined in web.xml.
    • DIGEST: Similar to BASIC, but passwords are hashed.
    • CLIENT-CERT: Authenticates users via client certificates (SSL/TLS).

Example for FORM Authentication:

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

3. Define Security Roles

Use the <security-role> element to list all the roles used in your application.

<security-role>
    <role-name>ADMIN</role-name>
</security-role>
<security-role>
    <role-name>USER</role-name>
</security-role>

These roles correlate with the roles you define in the <auth-constraint> section.


4. Example web.xml Configuration

A complete example with all the above steps:

<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" version="5.0">
    <security-constraint>
        <display-name>Secure Admin Pages</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Resources</web-resource-name>
            <url-pattern>/admin/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>ADMIN</role-name>
        </auth-constraint>
       <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

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

    <security-role>
        <role-name>ADMIN</role-name>
    </security-role>
    <security-role>
        <role-name>USER</role-name>
    </security-role>
</web-app>

5. Configuring Realm

a. Tomcat: tomcat-users.xml

In Tomcat, the tomcat-users.xml file (located in the conf folder) is the default User Realm. You can define users and their roles directly in this file.

Example tomcat-users.xml:

<tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">
    <role rolename="ADMIN"/>
    <role rolename="USER"/>

    <user username="admin" password="admin1234" roles="ADMIN" />
    <user username="user1" password="password" roles="USER,ADMIN" />
    <user username="guest" password="guest" roles="USER" />
</tomcat-users>
  • username: The username the user enters in the form.
  • password: The password used for authentication.
  • roles: The roles granted to this user. These roles must match the ones defined in web.xml (<security-role>).

When a user submits the form with j_security_check, the server matches their credentials against this file and determines whether they have the necessary role(s) to access the resource.

login.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Login</title>
</head>
<body>
<form class="login-form" method="post" action="j_security_check">
    <h2>Login</h2>
    <div class="error">
        <!-- Uncomment this for demonstration -->
        <!-- Invalid username or password -->
    </div>
    <label for="username">Username</label>
    <input type="text" id="username" name="j_username" placeholder="Enter your username" required>
    <label for="password">Password</label>
    <input type="password" id="password" name="j_password" placeholder="Enter your password" required>
    <button type="submit">Login</button>
</form>
</body>
</html>

error.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Access Denied</title>
</head>
<body>
<div class="error-container">
    <h1>Access Denied</h1>
    <p>Sorry, you are not authorized to access this page.</p>
    <a href="login.html">Return to Login</a>
</div>
</body>
</html>

Key Elements Explained:

  1. <security-constraint>:
    • Protects resources (e.g., /admin/* or /protected/*).
    • Specifies roles allowed to access resources.
  2. <auth-constraint>:
    • Specifies authorized roles for the secured resource.
  3. <login-config>:
    • Defines the authentication mechanism (BASIC, FORM, DIGEST, CLIENT-CERT).
  4. <user-data-constraint>:
    • Specifies transport security (e.g., CONFIDENTIAL ensures HTTPS is used).

Notes:

  • The actual user-role mapping is provided by the application server (through deployment descriptors, database configuration, or an external realm). How roles map to users is server-specific.
  • For FORM authentication, form-login-page is a path to your custom login page relative to the application’s context root.

This declarative approach is efficient for servlet security and follows the Jakarta EE standards.

How do I configure servlets in web.xml?

In a Jakarta EE (formerly Java EE) application, you can configure servlets in the web.xml deployment descriptor. The web.xml file is located in the WEB-INF directory of your project. Here’s how you can configure a servlet in web.xml step-by-step:

1. Declare the Servlet

You define the servlet by giving it a name and specifying its implementing class.

<servlet>
    <servlet-name>MyServlet</servlet-name>
    <servlet-class>org.kodejava.servlet.MyServlet</servlet-class>
</servlet>

2. Map the Servlet to a URL Pattern

After declaring the servlet, you specify the URL patterns (endpoints) it should handle.

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myServlet</url-pattern>
</servlet-mapping>

The servlet-name in the <servlet-mapping> must match the one defined in the <servlet> section.

Complete Example

Below is a complete example of web.xml configuration for a servlet:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd"
         version="6.0">

    <!-- Declare the servlet -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-class>org.kodejava.servlet.MyServlet</servlet-class>
    </servlet>

    <!-- Map the servlet to a URL pattern -->
    <servlet-mapping>
        <servlet-name>MyServlet</servlet-name>
        <url-pattern>/myServlet</url-pattern>
    </servlet-mapping>

</web-app>

Understanding the Tags

  • <servlet>: Declares the servlet, including its name and fully qualified class name.
  • <servlet-name>: A unique name for your servlet (used in <servlet-mapping> to link configuration).
  • <servlet-class>: The fully qualified class name of the servlet (e.g., org.kodejava.servlet.MyServlet).
  • <servlet-mapping>: Maps the declared servlet to specific URL patterns (e.g., /myServlet).
  • <url-pattern>: Specifies the URL or set of URLs that the servlet will handle.

Notes:

  1. URL Patterns:
    • /myServlet matches a specific path.
    • /* matches all paths.
    • /example/* matches all paths under /example.
  2. Multiple Servlet Mappings: You can map the same servlet to multiple URL patterns by adding multiple <servlet-mapping> entries.

  3. Override Annotations: If you use @WebServlet annotations in your servlet class, you generally won’t need to configure the servlet in web.xml. However, web.xml still allows more control over deployment and compatibility with older specifications.
  4. Jakarta EE Web.xml Version:
    The <web-app> version should match the Jakarta EE version you are using. For Jakarta EE 10, use version="6.0" as shown above.

How do I configure secure cookies using web.xml?

To configure secure cookies using web.xml, you typically need to set the secure attribute on your cookie definitions. This ensures that the cookie is only sent over HTTPS connections, enhancing security by protecting sensitive information from being transmitted over unencrypted channels. Here’s how you can do it:

1. Define Your Servlet Filter (Optional but Recommended):

If you don’t have a servlet filter for managing cookies, you can create one. This filter can intercept requests and responses to handle cookie-related operations.

<filter>
    <filter-name>CookieFilter</filter-name>
    <filter-class>org.kodejava.servlet.CookieFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>CookieFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Replace org.kodejava.servlet.CookieFilter with the actual class that implements your cookie handling logic.

2. Configure Secure Cookie in web.xml:

Inside your web.xml, you can define cookie configurations using <session-config> and <cookie-config> elements.

<session-config>
   <cookie-config>
      <!-- Recommended to prevent client-side script access -->
      <http-only>true</http-only>
      <!-- Set all cookies to be secure -->
      <secure>true</secure>
    </cookie-config>
</session-config>
  • <secure>true</secure>: This line ensures that all cookies are marked as secure, meaning they will only be sent over HTTPS connections.
  • <http-only>true</http-only>: This line makes cookies accessible only through HTTP headers, preventing client-side scripts (like JavaScript) from accessing them. It adds another layer of security against certain types of attacks.

3. Deploy and Test:

After making these changes, deploy your web application and test it over HTTPS. Verify that cookies are being set with the secure flag by checking your browser’s developer tools (usually under the “Application” or “Storage” tab).

By following these steps, you can configure secure cookies in your Java web application using web.xml.

Notes: Setting the secure attribute in web.xml configures the default behavior for cookies created by the servlet container. However, for custom cookies that your application creates programmatically, you need to explicitly call setSecure(true) on the Cookie object to make them secure.

How do I define welcome files for web application?

The configuration below gives us example how to define a welcome-files to our web application. The welcome file is default file to be loaded by a servlet container when we access a URL without telling which page to load.

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
         version="4.0">

    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.jsp</welcome-file>
        <welcome-file>default.html</welcome-file>
        <welcome-file>default.jsp</welcome-file>
    </welcome-file-list>
</web-app>