Security exception processing

Security exceptions are processed in a different way from other errors on the input node. An error is typically caught on the input node and routed down the Failure terminal for error processing, but security exceptions are not processed in the same way. By default, the broker does not allow security exceptions to be caught within the message flow, but backs the message out or returns an error (as in the case of HTTP). Security exceptions in input nodes are managed in this way to prevent a security denial of service attack filling the logs and destabilizing the system.

However, security exceptions in SecurityPEP nodes are managed in a different way. If a security operation fails in a SecurityPEP node, a security exception is raised, wrapped in a normal recoverable exception, which invokes the error handling that is provided by the message flow.

If you have designed the message flow to be in a secure area and you want to explicitly perform processing of security exceptions, you can select the Treat Security Exceptions as normal exceptions property on the MQInput or HTTPInput nodes. This property causes security exceptions to be processed in the same way as other exceptions in the message flow.

If you associate the Default Propagation security profile with an output or request node, the token type of the mapped or source security token must be the same as the transport default for that node; otherwise, a security exception occurs. For example, for an MQOutput node, the token type must be Username, for an HTTPRequest node, the token type must be Username + Password, and for a SOAPRequest node, the token type must be the type that is defined in either the policy set and binding or the transport binding.

For information on how to diagnose the causes of security exceptions, see Diagnosing security problems.