从WAS连接到MQ时为JMSWMQ2013 [英] JMSWMQ2013 when connecting from WAS to MQ

问题描述

我正在尝试从WebSphere App Server 7创建JMS连接，但是一直在获取JMSWMQ2013(使用MQ原因代码2035).显然这是一个身份验证问题，我可以参见 很多 其他 报告，所以我对一般问题有一个大概的认识.

I am trying to create a JMS connection from WebSphere App Server 7, but keep getting JMSWMQ2013 (with MQ reason code 2035). Clearly this is an authentication problem, and I can see many other similar reports so I have a rough idea of the general problem.

我正在等待我们的运营团队提供有关渠道确切配置的反馈，但是与此同时，我有一个令人费解的观察.如果我使用WebSphere的JAAS认证来提供用户ID，那么我总是会收到JMSWMQ2013错误.但是，如果将相同用户标识显式传递给JMS队列连接工厂对createQueueConnection()的调用，则不会收到身份验证错误.

I'm awaiting feedback from our operations team as to the exact configuration of the channel, however, in the meantime I have one observation that is quite puzzling. If I use WebSphere's JAAS authentication to provide the userid, then I always get the JMSWMQ2013 error. , however, if explicitly pass the same userid to the JMS queue connection factory's call to createQueueConnection(), then I don't get the authentication error.

说实话，我希望两种技术都能表现一致.使用JAAS为JMS队列连接工厂提供凭据时，我缺少一些精妙之处吗?

To be honest, I would have expected both techniques to behave consistently. Is there some subtlety that I am missing with using JAAS to provide the credentials for a JMS queue connection factory?

编辑:我使用*=info: JMSApi=all: JMSServer=all: Messaging=all: JMS_WASTraceAdapter=all: com.ibm.mq.*=all: jmsApi=all在WAS中打开了JMS跟踪，并逐行比较了输出.

I turned on JMS tracing in WAS using *=info: JMSApi=all: JMSServer=all: Messaging=all: JMS_WASTraceAdapter=all: com.ibm.mq.*=all: jmsApi=all, and compared the output line by line.

使用JAAS时，我可以看到在JmsXAQueueConnectionImpl的深处，它实际上是在调用WMQConnection.getProcessUserId()，它返回我的WAS实例正在其下运行的用户ID(肯定是不是渠道MCAUSER中定义的用户).

When using JAAS I can can see that deep in the bowels of JmsXAQueueConnectionImpl it is actually calling WMQConnection.getProcessUserId() which returns the userid that my WAS instance is running under (which is definitely not the user that is defined in the channel's MCAUSER).

这很奇怪……似乎根本没有使用JAAS身份验证条目.我的QCF肯定正在使用带有DefaultPrincipalMapping映射配置别名的CLIENT传输，但是由于某些原因，它仍在使用进程的用户ID而不是JAAS用户ID.

It is all quite odd... it doesn't seem to be picking up the JAAS authentication entry at all. My QCF definitely is using CLIENT transport with a mapping configuration alias of DefaultPrincipalMapping, but for some reason it is still using the process's userid instead of the JAAS userid.

谢谢. 克雷格

推荐答案

2035当然是身份验证问题.尝试连接的用户标识没有访问MQ资源的权限.

2035 is certainly authentication problem. The user id trying to connect doesn't have access to the MQ resource.

关于您的以下评论:

如果我使用WebSphere的JAAS认证来提供用户ID，那么我 总是会收到JMSWMQ2013错误. ，但是，如果明确通过 与JMS队列连接工厂调用相同的用户ID createQueueConnection()，那么我没有收到验证错误.

If I use WebSphere's JAAS authentication to provide the userid, then I always get the JMSWMQ2013 error. , however, if explicitly pass the same userid to the JMS queue connection factory's call to createQueueConnection(), then I don't get the authentication error.

您的期望是正确的.两种技术的行为均应相同.如果用户ID可以访问，则两个都应该连接，否则，两个都应该抛出错误.

Your expectation is correct. Both techniques should behave in the same way. If user id has access then both should connect, if not then both should throw error.

仅是对您的问题的解释是，您在不知不觉中在这些应用中发送了不同的用户ID.

Only explanation to your problem may be, that you are unknowingly sending different user ids in these apps.

例如，您的用户ID是"User123"，并且可以访问MQ资源.

Like, your user id is "User123", and it has access to the MQ resource.

但是，可能WebSphere的JAAS身份验证正在将Domain和用户ID一起发送. 假设您的用户ID位于开发人员"域中，则发送的用户ID为开发人员\ User123"，该用户可能无权访问该资源.

However, may be WebSphere's JAAS authentication is sending Domain along with user id. Say, your user id is in "Developer" domain, then the user id being sent is "Developer\User123", which may not be having access to the resource.

这篇关于从WAS连接到MQ时为JMSWMQ2013的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！