Configuring Java Servlet 3.1 support for security

Liberty supports all security updates as defined in the Java™ Servlet 3.1 specification.

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 that you want to use:
   • Specify autocomplete=off in the login form.
     When you 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 that are 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 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