Configuration

Channel security is supported by the security namespace by means of the requires-channel attribute on the <intercept-url> element and this is the simplest (and recommended approach)

To confiure channel security explicitly, you would define the following the filter in your application context:

<bean id="channelProcessingFilter" class="org.springframework.security.securechannel.ChannelProcessingFilter">
  <property name="channelDecisionManager" ref="channelDecisionManager"/>
  <property name="filterInvocationDefinitionSource">
    <security:filter-invocation-definition-source path-type="regex">
      <security:intercept-url pattern="\A/secure/.*\Z" access="REQUIRES_SECURE_CHANNEL"/>
      <security:intercept-url pattern="\A/acegilogin.jsp.*\Z" access="REQUIRES_SECURE_CHANNEL"/>
      <security:intercept-url pattern="\A/j_spring_security_check.*\Z" access="REQUIRES_SECURE_CHANNEL"/>
      <security:intercept-url pattern="\A/.*\Z" access="ANY_CHANNEL"/>
    </security:filter-invocation-definition-source>                
  </property>
</bean>
    
<bean id="channelDecisionManager" class="org.springframework.security.securechannel.ChannelDecisionManagerImpl">
  <property name="channelProcessors">
    <list>
    <ref bean="secureChannelProcessor"/>
    <ref bean="insecureChannelProcessor"/>
    </list>
  </property>
</bean>
    
<bean id="secureChannelProcessor" class="org.springframework.security.securechannel.SecureChannelProcessor"/>
<bean id="insecureChannelProcessor" class="org.springframework.security.securechannel.InsecureChannelProcessor"/>      

Like FilterSecurityInterceptor, Apache Ant style paths are also supported by the ChannelProcessingFilter.

The ChannelProcessingFilter operates by filtering all web requests and determining the configuration attributes that apply. It then delegates to the ChannelDecisionManager. The default implementation, ChannelDecisionManagerImpl, should suffice in most cases. It simply delegates to the list of configured ChannelProcessor instances. The attribute ANY_CHANNEL can be used to override this behaviour and skip a particular URL. Otherwise, a ChannelProcessor will review the request, and if it is unhappy with the request (e.g. if it was received across the incorrect transport protocol), it will perform a redirect, throw an exception or take whatever other action is appropriate.

Included with Spring Security are two concrete ChannelProcessor implementations: SecureChannelProcessor ensures requests with a configuration attribute of REQUIRES_SECURE_CHANNEL are received over HTTPS, whilst InsecureChannelProcessor ensures requests with a configuration attribute of REQUIRES_INSECURE_CHANNEL are received over HTTP. Both implementations delegate to a ChannelEntryPoint if the required transport protocol is not used. The two ChannelEntryPoint implementations included with Spring Security simply redirect the request to HTTP and HTTPS as appropriate. Appropriate defaults are assigned to the ChannelProcessor implementations for the configuration attribute keywords they respond to and the ChannelEntryPoint they delegate to, although you have the ability to override these using the application context.

Note that the redirections are absolute (eg http://www.company.com:8080/app/page), not relative (eg /app/page). During testing it was discovered that Internet Explorer 6 Service Pack 1 has a bug whereby it does not respond correctly to a redirection instruction which also changes the port to use. Accordingly, absolute URLs are used in conjunction with bug detection logic in the PortResolverImpl that is wired up by default to many Spring Security beans. Please refer to the JavaDocs for PortResolverImpl for further details.

You should note that using a secure channel is recommended if usernames and passwords are to be kept secure during the login process. If you do decide to use ChannelProcessingFilter with form-based login, please ensure that your login page is set to REQUIRES_SECURE_CHANNEL, and that the AuthenticationProcessingFilterEntryPoint.forceHttps property is true.