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
.