IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Diagnosing security problems

This topic explains how to find out why access to a secured flow has been denied.

By default, security exceptions occurring in an input node are not processed in the same way as other errors (see Security exception processing). Security exceptions are not logged to the system event log, to prevent a security denial of service attack filling the logs and destabilizing the system.

This means that, by default, you cannot diagnose input node security exceptions in the same way as other errors. However, in a SecurityPEP node, a failing security operation causes a security exception to be raised, wrapped in a normal recoverable exception, which invokes the error handling that is provided by the message flow.

To see what might be causing the security exceptions, you can do either of the following things:

Select the Treat Security Exceptions as normal exceptions property on the input nodes.
Use the user trace.

The following steps show you how to use the user trace to find out why access to a secured message flow has been denied:

Use the mqsireloadsecurity command to clear the security cache, so that the traced request goes to the security provider rather than using a result held in the cache. This ensures that the reason codes returned from the security provider are displayed in the traced exception.
Enable user trace for the message flow, using either the workbench or the mqsichangetrace command (see Starting user trace for more information).
Resend the request that has been rejected by the security provider.
Stop the user trace, using either the workbench or the mqsichangetrace command.
Use the mqsireadlog command to examine the trace information that was recorded by the user trace. This trace information contains the error codes provided by the broker and the security provider.

ap04180_.htm |

Last updated Friday, 21 July 2017