Error
[27/03/09 09:57:45:099 GMT] 0000003e SibMessage W [SCA.SYSTEM.LIVWS0095952Node03Cell.Bus:LIVWS0095952Node03.server1-SCA.SYSTEM.LIVWS0095952Node03Cell.Bus] CWSII0212W: The bus SCA.SYSTEM.LIVWS0095952Node03Cell.Bus denied an anonymous user access to the bus.
[27/03/09 09:57:45:099 GMT] 0000003e JMSListenerMD E WSWS3406E: Unexpected exception caught while sending reply message: javax.jms.JMSSecurityException: CWSIA0006E: The authorization for the supplied user name was not successful.
Root Cause
Authorization problems connecting to the bus The primary reason for an authorization failure when connecting to the bus is that the user, or a group that includes the user, does not have the bus connector role for that bus.
Resolution.
You can configure a user to have the bus connector role using the administrative console or the wsadmin scripting tool.
Best practice is to assign roles using groups rather than users directly.
Resolving the problem using the administrative console
From the administrative console:
1. Select Service Integration Buses.
2. Click on the bus name to which the client requires access.
3. Select Security.
4. Select Users and groups in the bus connector role.
This page lists the users and groups in the bus connector role. By default, this
list only contains a single group, the Server group. This convention gives
application servers authority to connect to the bus, but not the individual
applications .
You can modify this list by either deleting or adding users or groups.
5. To give a user the bus connector role, click New.
A new panel displays that lets you add users and groups (along with the
special Everyone, AllAuthenticated, and Server groups) to the bus connector
role.
6. Click OK to add the user to the bus connector role. The result is shown in
Figure 17-8.
7. Save and synchronize the configuration. You do not need to restart the server.
Subscribe to:
Post Comments (Atom)

1 comment:
This is regarding "CWSII0212W: CWSII0227W: The bus <> denied an anonymous user access to send messages to the destination <>" - while the solution u have suggested did work when choosing Everyone as the sender and receiver, when i chose a specific user Id (administrator user Id), it failed to work. The admin Id is infact mentioned as a part of the JMS resources - CF, ActSpec as well. The admin id, is in LDAP and is used to log in to the admin console - so the authentication details are correct. Any reason for such a behaviour?
Post a Comment