Use this set of specific tips to help you troubleshoot
problems you experience when working with a secure service integration
bus.
To help you identify and resolve service integration
bus security-related problems, use the WebSphere® Application Server trace and logging facilities
as described in Tracing and logging configuration Setting up component trace (CTRACE).
If you encounter a problem that you
think might be related to service integration bus security, you can
check for error messages in the
WebSphere Application Server administrative
console, and in the application server
SystemOut.log file.
You can also enable the application server debug trace to provide
a detailed exception dump.
New feature: This topic
references one or more of the application server log files. Beginning
in WebSphere Application Server Version 8.0 you can configure the
server to use the High Performance Extensible Logging (HPEL) log and
trace infrastructure instead of using
SystemOut.log ,
SystemErr.log,
trace.log,
and
activity.log files or native z/OS logging
facilities. If you are using HPEL, you can access all of your log
and trace information using the LogViewer command-line tool from your
server profile bin directory. See the information about using HPEL
to troubleshoot applications for more information on using HPEL.
newfeat
WebSphere Application Server system messages are logged
from a variety of sources, including application server components
and applications. Messages logged by application server components
and associated IBM products start with a unique message identifier
that indicates the component or application that issued the message.
The prefix for the service integration bus security component is CWSII.
The Troubleshooter reference:
Messages contains information about all WebSphere Application Server messages, indexed by message
prefix. For each message there is an explanation of the problem, and
details of any action that you can take to resolve the problem.
Here
is a set of tips to help you troubleshoot commonly-experienced problems:
After you migrate a Version 5.1 application server to WebSphere Application Server Version 7.0 or later, existing web services
clients can no longer use SOAP over JMS to access services hosted
on the migrated server.
Before you migrated the
Version 5.1 application server, no
user ID or password was required on the target MQ Series queue. After
the application server is migrated to
Version 7.0 or later, and to use the default
messaging provider (the service integration bus), client requests
fail because basic authentication is now enabled. The problem appears
as a log message:
SibMessage W [:] CWSIT0009W: A client request failed in the application
server with endpoint <endpoint_name> in bus your_bus with reason: CWSIT0016E:
The user ID null failed authentication in bus your_bus.
In WebSphere Application Server Version 7.0 or later, when you use a service
integration bus and WebSphere Application Server security
is enabled for the server or cell, by default the service integration
bus queue destination inherits the security characteristics of the
server or cell. So if the server or cell has basic authentication
enabled, then the client request fails.
To resolve the problem,
you have three choices (in order of security, from least secure to
most secure):
- Disable security.
- For an equivalent level of security to the configuration on Version 5.1, modify the settings
for the service integration bus that hosts the queue destination so
that bus security is disabled and therefore the bus does not inherit
security characteristics from the server or cell.
- For a greater level of security than the configuration on Version 5.1, configure basic authentication
on each client that uses the service.
To disable WebSphere Application Server security,
refer to Enabling and disabling security using scripting,
or Global security settings.
To
disable bus security, use the administrative console to complete the
following steps:
- Navigate to .
- Clear the Secure check box.
- Save your changes.
To configure basic authentication on each client, use
either the administrative console or the
wsadmin tool.
To complete the task by using the
wsadmin tool, see
Configuring web service client port information using wsadmin scripting and use
the
WebServicesClientBindPortInfo wsadmin task
option. To complete the task by using the administrative console,
complete the following steps:
- Navigate to .
- Click HTTP basic authentication to access
the "Configuring HTTP basic authentication with the administrative
console" panel.
- Enter the values in the panel.
- Save your changes to the master configuration.
When you try and make a connection by using
a user ID in an authorized group, access is denied when using LDAP
One
of the possible causes is the group name, if you are using an Lightweight
Directory Access Protocol (LDAP) registry. When you specify the group
authorization permissions, the distinguished name (DN) should be used
as the group name. If you specify a common name (CN) for the group
name users in that group cannot be authorized.
Steps to change
the group name from CN to DN depends on where the problem occurred.