views:

42

answers:

1

Our code runs in weblogic and we MQ 6.0. No matter if I use the default createQueueConnection() or createQueueConnection("myuserid","mypassword") it always seems to use userid mqm. See code below.

When I connect from version 6.0 to an older mq installion 5 it seems to throw the following error javax.jms.JMSSecurityException: MQJMS2013: invalid security authentication supplied for MQQueueManager using the default createQueueConnection() unless I send a blank userid/password as in createQueueConnection("","")

How can I get myuserid to be send instead ?

Hashtable properties = new Hashtable(2);
properties.put(Context.PROVIDER_URL,context);
properties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory");

InitialContext ctx = new InitialContext(properties);
QueueConnectionFactory qcf = (QueueConnectionFactory) ctx.lookup("QCF");
QueueConnection qc = qcf.createQueueConnection();
javax.jms.Queue q = (javax.jms.Queue) ctx.lookup("MYQUEUE");
QueueSession qs = qc.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
TextMessage tm = qs.createTextMessage();
tm.setText(outString);
QueueSender sender = qs.createSender(q);
sender.send(tm);
sender.close();
qs.close();
qc.close();
+3  A: 

If you are setting the ID in the createQueueConnection, rest assured, it is being presented to the queue manager. The problem you are seeing is that the SVRCONN channel definition on the QMgr has the value MCAUSER('mqm') hard coded. This overrides any value presented by the client app.

A couple of things to note here.

  1. Although you can send the ID and password, WMQ accepts these at face value. The fields exist to make the credentials available for a channel exit that can validate them. Without such an exit the channel just runs as whatever ID the app claims to be and the password is ignored.
  2. For the reason stated above, I always tell people not to trust the credentials presented unless they have such an exit. The administrator must code the appropriate value into the MCAUSER.
  3. The administrative ID ('mqm' on UNIX flavors) is NOT the appropriate value. It confers administrative authority to anyone connecting on that channel.

For a LOT more on this topic and pointers to the WMQ security presentation and WMQ Security Lab guide from IMPACT, please see this SO question.

T.Rob
Thnaks T.Rob for the clarification. Also I do see difference connecting with MQ6 java jars to an MQ5 installation. It seems to be not 100% compatible, as the userid is not overwritten in that case. But passing a blank string as userid/password seems to work as in that scenario the default mqm userid is used by the QMgr.
mrjohn
I should have mentioned that WMQ 5.x is out of support for quite a while now and WMQ v6 is out of support as of Sept 2011. If at all possible, move to v7 on both the client and the QMgr. Ordinarily I'd say that you can use a later version of client than on the QMgr and to upgrade there first if you have to - but the v7 client wasnot tested with the v5 QMgr AKAIK so just upgrade everything if this will be a Production system and you want to be able to open IBM PMRs against it.
T.Rob