WebSphere 7, настройка фабрики соединений JMS Q без идентификатора пользователя: MQRC_NOT_AUTHORIZED

У меня есть экземпляр WebSphere 6 и экземпляр WebSphere 7. У каждого из них есть поставщик сообщений WebSphere MQ, фабрика соединений с очередями и очередь, настроенная аналогичным образом. Все поля идентификатора пользователя остаются пустыми, а псевдонимы аутентификации - «нет».

В WAS6 работает нормально.

В WAS7 я получаю ошибку:

JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'. Please check if the supplied username and password are correct on the QueueManager you are connecting to; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

Чем отличается способ подключения WAS7 к MQ по сравнению с WAS6, если идентификатор пользователя не указан?

У меня нет видимости или доступа к этому MQ (версия 7), он не требует идентификатора пользователя при доступе из WAS 6, поэтому мне нужно, чтобы WAS7 работал так же.


security websphere ibm-mq jms
person Maxim Suponya    schedule 16.05.2011    source источник

Ответы (1)


arrow_upward
12
arrow_downward

В WAS 6, если вы оставили идентификатор пользователя в панели администрирования пустым, в WMQ передавалось пустое поле. WMQ будет запускать канал, даже если он не может определить удаленного пользователя, и в этом случае канал работает с полномочиями агента канала сообщений (MCA), который всегда является административным. Следовательно, в V6 это работает.

Начиная с версии V7, клиент WMQ будет немного усерднее пытаться определить, какой идентификатор передать, если вы оставите его пустым в панели администратора WAS, и получит идентификатор JVM и передаст его при вызове CONNECT. Это источник 2035 года.

Правильный способ исправить это состоит в том, что администратор WMQ должен поместить идентификатор с низким уровнем привилегий в поле MCAUSER канала SVRCONN. Идентификатор должен быть авторизован для любых очередей, которые нужны серверу Java EE, но не для очереди команд и различных других административных очередей. Это решит проблему, заключающуюся в том, что WAS 7 отправляет нераспознанный идентификатор и не позволяет удаленным клиентам любого типа получить административный доступ на этом канале.

Альтернативой является переход к панели администратора WAS для подключения WMQ и установка идентификатора пользователя на mqm. (Это работает, если WMQ работает в распределенной системе, отличной от Windows. Если WMQ работает в Windows, z / OS или чем-то еще, замените здесь идентификатор, эквивалентный платформе.) тот факт, что QMgr предоставляет административный доступ.

См. Презентацию и лабораторную работу по усилению защиты WMQ по адресу http://t-rob.net/links для получения дополнительной информации исчерпывающее объяснение того, как определить и устранить основную угрозу безопасности в QMgr.

person T.Rob    schedule 16.05.2011
comment
спасибо Максиму за то, что задал этот животрепещущий вопрос, а также спасибо T.Rob за точный ответ - person siddhesh jog; 22.08.2012