+

Search Tips   |   Advanced Search

Configure Java Servlet 3.1 support for security

WebSphere Application Server traditional supports all security updates as defined in the Java Servlet 3.1 specification.

Take advantage of the Java Servlet 3.1 features on WAS traditional.


Tasks

  1. Add the servlet-3.1 feature in the server.xml file:
    <feature>servlet-3.1</feature>
    

  2. Determine which of the following Java Servlet 3.1 functions to use:

    • Specify autocomplete=off in the login form.

      When we use HTML for a form login page, set the password form field to autocomplete="off" to disable automatically filling in passwords in the web browser. For example:

      <form method="POST" action="j_security_check">
      <input type="text" name="j_username">
      <input type="password" name="j_password" autocomplete="off">
      </form>
      

    • Specify the all authenticate security constraint (**).

      The special role name ** indicates any authenticated user. When ** displays in an authorization constraint, if the user is authenticated, that user has access to the methods specified in the constraint. Users do not have to be mapped to this role in the application bindings. For example:

      <security-constraint id="SecurityConstraint_1">
      		<web-resource-collection id="WebResourceCollection_1">
      			<web-resource-name>Protected with ** role</web-resource-name>
      			<url-pattern>/AnyAuthSecurityConstraint</url-pattern>
      			<http-method>GET</http-method>
      			<http-method>POST</http-method>
      		</web-resource-collection>
      		<auth-constraint id="AuthConstraint_1">
      			<role-name>**</role-name>
      		</auth-constraint>
      </security-constraint>
      

      When the isUserInRole() method is called with a role name of **, isUserInRole() returns true if the user is authenticated. If ** is a defined role in the configuration in a security-role, it is not treated like the special any authenticated user role. The user must be mapped to that role in application bindings for isUserInRole to return true.

    • Specify the deny-uncovered-http-methods flag in the web.xml files.

      If the deny-uncovered-http-methods element is specified within the web.xml file, the container denies any uncovered HTTP methods that are not enumerated within the combined security constraint for a URL pattern that is the best match for the request URL. A 403 (SC_FORBIDDEN) status code is returned. For example:

      <servlet-mapping id="ServletMapping_1">
      		<servlet-name>MyServlet</servlet-name>
      		<url-pattern>/MyURLPattern</url-pattern>
      </servlet-mapping>
      
      <deny-uncovered-http-methods/>
      
      <!-- SECURITY CONSTRAINTS -->
      <security-constraint id="SecurityConstraint_1">
      		<web-resource-collection id="WebResourceCollection_1">
      			<web-resource-name>Protected with Employee or Manager roles</web-resource-name>
      			<url-pattern>/MyURLPattern</url-pattern>
      			<http-method>GET</http-method>
      			<http-method>POST</http-method>
      		</web-resource-collection>
      		<auth-constraint id="AuthConstraint_1">
      			<role-name>Employee</role-name>
      			<role-name>Manager</role-name>
      		</auth-constraint>
      </security-constraint>
      

      If the deny-uncovered-http-methods element is specified in the web.xml file, a message is logged in the messages.log file for each URL pattern in each servlet, indicating the uncovered methods with a note that those uncovered methods are unprotected and not accessible. For example:

      For URL MyURLPattern in servlet MyServlet, the following HTTP methods are uncovered, and not accessible: DELETE OPTIONS HEAD PUT TRACE
      

      If the deny-uncovered-http-methods element is not specified in the web.xml file, a message is logged in the messages.log file for each URL pattern in each servlet, indicating the uncovered methods with a note that those uncovered methods are unprotected and accessible. For example:

      For URL MyURLPattern in servlet MyServlet, the following HTTP methods are uncovered, and accessible: DELETE OPTIONS HEAD PUT TRACE
      

We have now secured the application.

  • JSR-000340 Java Servlet 3.1 Specification