Service integration bus security: Troubleshooting tips

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 WAS trace and logging facilities as described in Tracing and logging configuration .

If you encounter a problem that you think might be related to service integration bus security, we can check for error messages in the WAS admin console, and in the appserver SystemOut.log file. We can also enable the appserver debug trace to provide a detailed exception dump.

WAS 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 WAS messages, indexed by message prefix. For each message there is an explanation of the problem, and details of any action that we can take to resolve the problem. Here is a set of tips to help you troubleshoot commonly-experienced problems:

• After you migrate a V5.1 appserver to WAS V7.0, existing web services clients can no longer use SOAP over JMS to access services hosted on the migrated server.
• When you try and make a connection by using a user ID in an authorized group, access is denied when using LDAP

 

After you migrate a V5.1 appserver to WAS V7.0, existing web services clients can no longer use SOAP over JMS to access services hosted on the migrated server.

Before you migrated the V5.1 appserver, no user ID or password was required on the target MQ Series queue. After the appserver is migrated to V7.0, 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 the_bus with reason: CWSIT0016E: 
The user ID null failed authentication in bus the_bus.

In WAS V7.0, when you use a service integration bus and WAS 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, we 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 V5.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 V5.1, configure basic authentication on each client that uses the service.

To disable WAS security, refer to Enable and disabling security using scripting, or Global security settings. To disable bus security, use the administrative console to complete the following steps:

1. Navigate to Service integration > Buses > bus_name .

2. Clear the Secure check box.

3. Save the changes.

To configure basic authentication on each client, use either the admin console or wsadmin. To complete the task by using wsadmin, see Configure Web service client port information using wsadmin scripting and use the WebServicesClientBindPortInfo wsadmin task option. To complete the task by using the admin console...

1. Navigate to Applications > Application Types > WebSphere enterprise apps > application_name > Web Modules or EJB Modules > module_name > Web services: Client security bindings .

2. Click HTTP basic authentication to access the "Configuring HTTP basic authentication with the administrative console" panel.

3. Enter the values in the panel.

4. Save the 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 we are using an Lightweight Directory Access Protocol (LDAP) registry. When 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.

• If we have problem connecting to a service integration bus, see Administer the bus connector role, and remove any groups with CN group names, and replace them with DN group names.

• If we have problem sending a message to a destination, see Administer destination roles, and remove any groups with CN group names, and replace them with DN group names.

• If we have problems sending topics to a topic space, see Administer topic space root roles, and remove any groups with CN group names, and replace them with DN group names.

• For any other problems refer to the appropriate section on Administer authorization permissions on how to modify the group name.

   

---

Last updated Nov 10, 2010 8:23:07 PM CST