Наше приложение работает в системе Sun Solaris и имеет локальную установку WebSphere MQ. Приложение использует режим привязки для подключения к администратору очередей. При попытке отправить сообщение в локальную очередь привязка JNDI выполняется успешно, но мы сталкиваемся с ошибкой javax.jms.JMSSecurityException: MQJMS2013: invalid security authentication supplied for MQQueueManager. При расследовании было обнаружено, что учетные данные (идентификатор пользователя), используемые для аутентификации, не чувствительны к регистру, как пользователь, от которого запущено приложение. Идентификатор пользователя совпадает, но регистр не учитывается. По умолчанию пользователь, на котором запущено приложение, будет проходить аутентификацию, но здесь совпадение с учетом регистра не выполняется. Сервер приложений — WebLogic. Цените любые входные данные.
Исключение проверки подлинности WebSphere MQ Security в Unix
Ответы (2)
Чтобы открыть локальную очередь, приложение должно сначала успешно подключиться к администратору очередей. Ошибка в удаленной очереди — это ошибка подключения, поэтому она даже не доходит до диспетчера очередей. Это говорит о том, что вы используете разные фабрики соединений и что вторая имеет некоторые отличия в параметрах подключения. Первый шаг – примирить эти различия.
Кроме того, ошибка безопасности MQJMS2013 может быть связана со многими вещами, большинство из которых на самом деле не являются проблемами MQ. Например, некоторые люди хранят свои управляемые объекты в LDAP, и проблема аутентификации там вызовет эту ошибку. Для людей, которые используют JNDI на основе файловой системы, права доступа к файлам ОС могут вызвать то же самое. Однако, если это фактическая проблема WMQ (как это кажется), тогда связанное исключение будет содержать код причины MQ (например, MQRC=2035). Если вы хотите иметь возможность лучше диагностировать проблемы MQ (или, если уж на то пошло, любого транспорта JMS), стоит выработать привычку печатать связанные исключения.
Если вы не можете решить эту проблему на основе этого ввода, я бы посоветовал обновить вопрос, указав подробности определений управляемых объектов и код причины, полученный при печати связанных исключений.
Мы использовали createQueueConnection() в QueueConnectionFactory для создания соединения, и проблема была решена с помощью метода createQueueConnection("",""). Идентификатор пользователя unix (webA) чувствителен к регистру, и приложение пыталось пройти аутентификацию на MQ с нечувствительным к регистру идентификатором пользователя (weba), а диспетчер очередей MQ отклонял попытку подключения. Можете ли вы рассказать нам, почему приложение раньше отправляло регистронезависимый идентификатор пользователя (weba)?
Спасибо, Арун
