This recipe highlights how Spring MVC transactions will behave even when a wrong HTTP and port channel is accidentally used in executing the request. In the previous recipe, the login request was executed through http://localhost:8080/ch04/login.html and the security model did not allow this execution even with the correct user credentials. Since our Tomcat 9.0 is using HTTPS, we need to include a solution in our security model that will force redirection of all URL request transactions from HTTP at port 8080 to HTTPS using port 8443. The easiest solution is to configure the http.requiresChannel() method, which can restrict any requests from running on HTTP but with HTTPS instead.

The requiresChannel() method outputs a ChannelRequestMatchRegistry class that lists all the URL requests that can be executed in HTTPS. Some applications consider /login.html as a non-HTTP request, thus the line http.requiresChannel().antMatcher ("/login.html").requiresInsecure() is indicated in the model. But in this recipe, we will include all URLs as part of the HTTP transactions, thus the line http.requiresChannel().anyRequest().requiresSecure() in our AppSecurityModelA context. In an XML-based context definition, this process is equivalent to the metadata:

<intercept‐url pattern="/**" access="isAuthenticated()"  
requires‐channel="http"/> 

What follows after the HTTPS registration is the typical authorizeRequests() invocation asking for the usual authentication and authorization rules.

With regard to port matching, HttpSecurity also has a portMapper() method, which forces a port to be redirected to another port, just like in our case wherein running requests on port 8080 will just be executed forcedly to port 8443. When using XML-based Spring Security configuration, port mapping is done through:

  <security:port-mappings> 
        <security:port-mapping http="8080" https="8443"/> 
    </security:port-mappings> 

To wrap up, using this security model on a non-TLS Tomcat installation will give you: