Security in Spring Integration

To secure message channels in the integration flow, an AuthorizationChannelInterceptor has to be added to those channels, or it can be configured as a global channel interceptor with a respective pattern:

See Global Channel Interceptor Configuration for more information.

To be sure that our interaction with the application is secure, according to its security system rules, we should supply some security context with an authentication (principal) object. The Spring Security project provides a flexible, canonical mechanism to authenticate our application clients over HTTP, WebSocket, or SOAP protocols (as can be done for any other integration protocol with a simple Spring Security extension). It also provides a SecurityContext for further authorization checks on the application objects, such as message channels. By default, the SecurityContext is tied to the execution state of the current Thread by using the (ThreadLocalSecurityContextHolderStrategy). It is accessed by an AOP (Aspect-oriented Programming) interceptor on secured methods to check (for example) whether that principal of the invocation has sufficient permissions to call that method. This works well with the current thread. Often, though, processing logic can be performed on another thread, on several threads, or even on external systems.

Standard thread-bound behavior is easy to configure if our application is built on the Spring Integration components and its message channels. In this case, the secured objects can be any service activator or transformer, secured with a MethodSecurityInterceptor in their <request-handler-advice-chain> (see Adding Behavior to Endpoints) or even MessageChannel (see Securing channels, earlier). When using DirectChannel communication, the SecurityContext is automatically available, because the downstream flow runs on the current thread. However, in the cases of the QueueChannel, ExecutorChannel, and PublishSubscribeChannel with an Executor, messages are transferred from one thread to another (or several) by the nature of those channels. In order to support such scenarios, we have two choices:

This is implemented as a org.springframework.security.messaging.context.SecurityContextPropagationChannelInterceptor in the spring-security-messaging module, which can be added to any MessageChannel or configured as a @GlobalChannelInterceptor. The logic of this interceptor is based on the SecurityContext extraction from the current thread (from the preSend() method) and its populating to another thread from the postReceive() (beforeHandle()) method. See the SecurityContextPropagationChannelInterceptor Javadocs for more information.

Propagation and population of SecurityContext is just one half of the work. Since the message is not an owner of the threads in the message flow, and the system should be sure that it is secured against any incoming messages, the SecurityContext has to be cleaned up from ThreadLocal. The SecurityContextPropagationChannelInterceptor provides the afterMessageHandled() interceptor method implementation. It cleans up operation by freeing the thread at the end of invocation from that propagated principal. This means that, when the thread that processes the handed-off message finishes processing the message (successful or otherwise), the context is cleared so that it cannot inadvertently be used when processing another message.

If the data integrity, transferred in the system via messages, is not guaranteed, the authentication and authorization control might not be enough for the application to perform correctly, since even a valid user may produce malicious data. The validation and filtration must be applied to the message payload and its headers if the source of that message is not trusted. This applies not only to the type information carried in headers with potential deserialization gadgets but also to those use-cases where the target destination for the message is determined from a header of that message. These scenarios fit into the Return Address pattern. Some vulnerabilities have been identified related to email reply addresses, specifically involving injection, spoofing, and unauthorized redirection of replies. Therefore, such metadata in those standard message headers (MqttHeaders.TOPIC, RedisHeaders.KEY, MailHeaders.TO, MailHeaders.CC, MailHeaders.BCC, AvroHeaders.TYPE etc.), if they are carried (or re-mapped) from an external untrusted source, should be validated or stripped before they are used in the target endpoint.

One of the options to avoid metadata spoofing is to not allow it to enter the application at all. The inbound channel adapters (and gateways) in Spring Integration provide a HeaderMapper strategy to filter what headers should be mapped from the source system. Another component is the HeaderFilter to remove unwanted headers in the flow.

However, sometimes the logic of the application relies on those headers even if they come from an external system. For this purpose values of those headers should be validated, for example, using MessageFilter endpoint, or MessageSelectingInterceptor. Starting with version 6.5.9, Spring Integration provides an AllowListMessageHeaderSelector to apply simple patterns on the message header values:

In the example above only values starting with test would be accepted for MqttHeaders.TOPIC. And those with malicious sub-string (even if they start with test) won’t be accepted. See AllowListMessageHeaderSelector Javadocs for more information.