Channelprocessingfilter of Spring Security uses HTTPS requests

7.4.6 ensure a secure channel

The letter "S" is the most important letter on the Internet. Anyone who has surfed the web for more than five minutes knows that most Web pages are associated with URLs that begin with "http://." That's because most Web pages are requested and sent over the HTTP protocol.

HTTP is sufficient for most pages, but not enough when secret information travels around the Internet. Messages sent over HTTP are easily intercepted and read by lawless hackers and used in their malicious programs.

When the information must be sent secretly, the letter "s" begins to work. For those pages, you'll find that the URLs begin with "https://" rather than "http://". For HTTPS, the information is still sent using HTTP, but is sent on another port, and is encrypted, so that if they are intercepted, any person who is not scheduled will not be able to read them.
Unfortunately, the problem with HTTPS is that you must ensure that the pages that are delivered over HTTPS belong to the author of the link to the secure page. In other words, for a page to be protected with encrypted HTTPS, it must be linked with a URL that starts with "https://". Without that letter "s", the page will be sent unencrypted on HTTP.

Because this vital "s" is particularly vulnerable to omission, spring security provides a very simple way to ensure that certain pages are routed using HTTPS, regardless of which URL is used to link to them. As shown in Figure 7.14, Channelprocessingfilter is a spring security filter that intercepts a request to see if it needs to be protected, and if so, redirects the request to the HTTPS format of the original request URL so that "s" Work.

(Click to view larger image) Figure 7.14 Channelprocessingfilter redirect HTTP requests to HTTPS (and vice versa) to ensure appropriate security for each request.

We have configured a channelprocessingfilter for the Roadrantz application in the Roadrantz-security.xml file as follows:

The Filterinvocationdefinitionsource attribute here is configured to tell channelprocessingfilter which pages should be protected using HTTPS and which should not be protected. It is configured to one or more URL patterns that are mapped to be protected or unprotected.

But before these URLs appear, we have to set some basic rules for how to handle those URLs. The first line contains Convert_url_to_lowercase_before_comparison, which tells spring Security to standardize all URLs before comparing it to subsequent URL patterns. The second line contains Pattern_type_apache_ant, which indicates that subsequent URL patterns will be rendered using the APACHE ANT style path.

Each subsequent row maps a URL pattern to its security requirements. In a Roadrantz application, the login page must be protected (so that no one can intercept the user's password). Therefore,/login.htm is mapped to Requires_secure_channel, indicating that it should be sent over HTTPS. Similarly, the information sent to the URL that handles the login must also be encrypted. As the reader will soon see, Spring Security's authenticationprocessingfilter is responsible for/j_acegi_security_check, so this URL pattern is also set to Requires_ Secure_channel.

No other pages in the Roadrantz application require encryption, so the "/**" url pattern (which means all URLs in the ant path Syntax) is set to Requires_insecure_channel, specifying that all other pages must pass through the usual, Unsecured HTTP send. Note that these pages require an unsecured channel. That means that if these pages are accessed through HTTPS, then Channelprocessingfilter will redirect them to send over HTTP.