В этой лекции обсуждаются следующие темы:
Администрирование новой копии WebSphere MQ
Предоставление доступа к ресурсам менеджера очередей
Установка контекста идентификационных данных для клиентских приложений
Протокол Secure Sockets Layer (SSL)
WebSphere MQ internet pass-thru (IPT)
11.1. Администрирование новой копии WebSphere MQ
Для настройки только что установленных копий WebSphere MQ, а также для создания, запуска и остановки менеджеров очередей пользователь должен войти в систему на машине, где установлен WebSphere MQ.
При этом пользователь получает возможность исполнения управляющих команд в Microsoft Windows и UNIX, команд CL на серверах IBM Eserver iSeries, а также исполнения команд для управления подсистемами менеджеров очередей в z/OS. В этой книге такие пользователи называются администраторами.
Администраторы также обслуживают установленные копии WebSphere MQ и менеджеры очередей. Например, они регулярно анализируют журналы ошибок менеджеров очередей, работающих на вверенной им машине, а также выполняют проверки на FFST.
Примечание. Команда runmqsc - управляющая команда WebSphere MQ. В Windows, UNIX и iSeries только пользователи, авторизованные как администраторы WebSphere MQ, могут исполнять команды MQSC, адресованные непосредственно менеджерам очередей.
Способы ограничения доступа к этим операциям в WebSphere MQ зависят от платформы.
Windows: доступ к управляющим командам WebSphere MQ разрешен только членам групп mqm и Administrators.
UNIX: доступ к управляющим командам WebSphere MQ разрешен только членам группы mqm.
iSeries: члены группы QMQMADM обладают доступом ко всем командам WebSphere MQ CL. Подробнее об управлении доступом к отдельным командам CL в iSeries см. в разделе "Authority to administer WebSphere MQ on i5/OS" в руководстве WebSphere MQ Security, SC34-6588.
z/OS: проверка полномочий, выполняемая WebSphere MQ для z/OS, перенаправляется внешнему менеджеру безопасности (External Security Manager-ESM). Здесь предполагается, что его роль играет z/OS Security Server Resource Access Control Facility (RACF $$\text{\textregistered}$$). Доступ к наборам данных и командам, управляющим подсистемами менеджеров очередей, предоставляется посредством администрирования профилей RACF. Дополнительные сведения см. в разделе "Authority to administer WebSphere MQ on z/OS" руководства WebSphere MQ Security, SC34-6588.
11.2. Предоставление доступа к ресурсам менеджеров очередей
Модель защиты WebSphere MQ основана на конфигурировании профилей доступа для отдельных объектов и групп объектов WebSphere MQ.
Объекты WebSphere MQ представляют все ресурсы, принадлежащие менеджеру очередей и управляемые им; о некоторых из этих ресурсов рассказывается ниже. Например, объекты WebSphere MQ служат для настройки очередей в составе менеджера очередей, а также каналов, управляющих сетевым взаимодействием с данным менеджером очередей.
Эта модель защиты обеспечивает тонкую настройку защиты менеджера очередей при доступе различных сущностей, позволяя им доступ только к необходимым им ресурсам.
11.2.1. Object Authority Manager (OAM)
В Windows, UNIX и iSeries у каждого менеджера очередей имеется компонент под названием Object Authority Manager (OAM). Он проверяет у всех сущностей, подключенных к менеджеру очередей и пытающихся выполнить какое-либо действие над объектами WebSphere MQ, наличие соответствующих полномочий.
Сущности различаются по идентификаторам пользователя операционной системы. У приложений, выполняющихся на той же машине, это реальный идентификатор пользования, который есть у каждого приложения (а не действующий идентификатор пользователя, как в UNIX). Ниже обсуждается установка контекста идентификационных данных сущностей, подключающихся в режиме клиентов с удаленных систем (см. раздел 11.3).
Полномочия OAM
Любому действию, которое может быть выполнено над объектом, соответствуют полномочия, которые можно предоставить либо отозвать с помощью OAM. Сущности, подключенные к менеджеру очередей, могут выполнять следующие действия над объектами WebSphere MQ.
Подключение к менеджерам очередей.Существует объект WebSphere MQ, представляющий менеджер очередей. Чтобы подключиться к менеджеру очередей, сущность прежде должна получить полномочия на подключение к данному объекту менеджера очередей.
Операции с интерфейсом очередей сообщений ( message queue interface, MQI ).Любое действие, программно выполняемое над менеджером очередей, независимо от используемого API, соответствует одной или нескольким операциям MQI, например MQPUT, MQGET, MQINQ и MQSET.
Интерфейс MQI перед обращением к ресурсам требует выполнения операции MQOPEN. Чаще всего MQOPEN применяют для того, чтобы открыть очередь перед размещением и извлечением из нее сообщений.
Именно во время вызова MQOPEN компонент OAM проверяет наличие полномочий на выполнение операций, запрошенных при вызове MQOPEN. Каждой из возможных операций соответствуют полномочия, обслуживаемые OAM, а именно разрешения на извлечение ( get ), добавление ( put ), просмотр ( browse ), запрос ( inquire ) и установку ( set ). После вызова MQOPEN приложению разрешено выполнять лишь операции MQI, авторизованные во время вызова MQOPEN.
Примечание. Авторизация занимает некоторое время, поэтому после вызова MQOPEN рекомендуется выполнять несколько операций put/get, а не вызывать MQOPEN и MQCLOSE после каждой операции. То же верно для вызова MQPUT1, который соответствует операциям MQOPEN, MQPUT и MQCLOSE.
При вызове MQOPEN часто указывают имя объекта очереди, объявленного в менеджере очередей, к которому подключено приложение. При открытии очереди для извлечения или просмотра сообщений всегда указывают имя локального объекта или псевдонима очереди, а при открытии очереди для размещения сообщений - имя объекта локальной очереди, модельной очереди, псевдонима или удаленной очереди. В этих случаях вызывающая сущность должна получить полномочия для выполнения запрошенных действий над этим объектом.
Однако при добавлении сообщения в очередь удаленного менеджера в вызове MQOPEN может быть указано имя объекта, объявленного в другом менеджере очередей, а не в том, к которому подключено приложение. Например, приложение может указать при вызове MQOPEN имя объекта менеджера очередей или очереди, расположенной в другом менеджере очередей кластера. В этих случаях приложение должно получить полномочия на размещение сообщений в транспортной очереди, которая определяется в результате разрешения имени очереди.
В табл. 6.1 дана сводка объектов, для которых выполняется проверка полномочий при открытии очереди для размещения сообщений.
Примечание. Чтобы получить полномочия для размещения сообщений в любой из общих очередей кластера менеджеров очередей, приложение может получить полномочие на добавление в отношении очереди SYSTEM.CLUSTER.TRANSMIT.QUEUE, обслуживаемой менеджером, к которому это приложение подключается. Больше возможностей по управлению доступом можно получить следующим образом. Определите объекты модельных очередей, в атрибуте "target queue" ( TARGQ ) которых указаны имена общих очередей кластера. Далее можно предоставлять полномочия только для добавления сообщений в отношении этих объектов модельных очередей.
Выполнение действий в контексте другого пользователя.В некоторых обстоятельствах приложению требуется выполнять действия, как если бы оно было подключено в контексте другого пользователя, либо указывать другие идентификационные данные пользователя в MQMD сообщений, размещаемых этим приложением.
Примером может быть служба, которая переносит идентификационные данные из сообщения-запроса в сообщение-ответ.
Если приложению требуется возможность выполнять эти операции, оно должно заявить об этом при вызове MQOPEN для очереди. В WebSphere MQ имеется набор полномочий, соответствующих параметрам вызова MQOPEN: altusr, passid, passall, setid, setall.
Подробнее об этом см. в разделе "MQOPEN – Open object" руководства WebSphere MQ Application Programming Reference, SC34-6596.
Администрирование объектов WebSphere MQ.Только пользователи, назначенные администраторами WebSphere MQ, могут непосредственно администрировать менеджеры очередей с использованием управляющих команд WebSphere MQ и команд CL, в том числе исполнять команды MQSC с помощью runmqsc, подробнее об этом см. в разделе 11.1.
Однако WebSphere MQ допускает администрирование менеджеров очередей другими пользователями, которые могут использовать WebSphere MQ Explorer либо передавать команды PCF непосредственно командному серверу менеджера очередей.
Примечание. Командный сервер по умолчанию запускается для менеджеров очередей, созданных в WebSphere MQ V6.0 на любой платформе, кроме z/OS.
Авторизация этих команд выполняется на основе идентификатора пользователя в MQMD управляющего сообщения. Этот идентификатор пользователя основан на контексте идентификационных данных приложения, сгенерировавшего сообщение менеджеру очередей, к которому оно подключено. Однако у приложения могут быть полномочия для размещения сообщений в контексте другого пользователя.
OAM поддерживает ряд административных полномочий для тонкой настройки администрирования объектов пользователями.
Create ( crt ) и delete ( dlt ): назначаются в отношении некоторого типа объектов, позволяют, соответственно, создавать и удалять любые объекты этого типа.
Display ( dis ) и change ( chg ): назначаются в отношении отдельных объектов, позволяют отображать и модифицировать атрибуты объекта, для которого они назначены;
Clear ( clr ), ping ( ping ), control ( ctrl ) и control-extended ( ctrlx ): назначаются в отношении отдельных объектов соответствующего типа; позволяют выполнять над объектом некоторые операции по управлению. Например, полномочие clear ( clr ) позволяет очищать очередь, control ( ctrl ) - запускать и останавливать каналы, а control-extended ( ctrlx ) — выполнять сброс (reset) или разрешение (resolve) для каналов.
Примечание. Ряд административных действий над менеджерами очередей разрешен только администраторам WebSphere MQ. До WebSphere MQ V6.0 в их число входили запуск, останов и разрешение каналов. Подробнее см. в разделе "Authority checking for PCF commands" руководства WebSphere MQ Programmable Command Formats and Administration Interface, SC34-6598.
Ниже мы обсудим установку идентификационных данных пользователей, подключающихся к менеджеру очередей по сети и передающих команды для командного сервера.
Предоставление, отзыв и отображение полномочий OAM
WebSphere MQ поддерживает ряд управляющих команд, контролирующих атрибуты индивидуальных объектов и их групп.
WebSphere MQ V6.0 также поддерживает команды PCF для программного администрирования полномочий. Дополнительные сведения о них см. в руководстве WebSphere MQ Programmable Command Formats and Administration Interface, SC34-6598.
Полномочия могут назначаться только пользователям и группам, определенным в локальной операционной системе.
Примечание. В WebSphere MQ для UNIX-платформ назначение и отзыв полномочий всегда осуществляется на уровне групп пользователей ОС. Чтобы назначить или отозвать полномочие у отдельного пользователя, это необходимо сделать для основной группы данного пользователя, а не его самого.
Для администрирования полномочий OAM служат следующие команды Web Sphere MQ.
setmqaut - применяется для назначения и отзыва полномочий OAM для объектов WebSphere MQ на заданном менеджере очередей заданного типа с заданным именем. В именах параметров допускается символ "звездочка" (*), позволяющий указывать группы имен; сам по себе объект менеджера очередей не требует параметра, определяющего имя.Примечание. После внесения любых изменений с использованием команды setmqaut в активный менеджер очередей важно выполнить в отношении этого менеджера очередей команду MQSC REFRESH SECURITY. Это необходимо, поскольку для повышения быстродействия менеджеры очередей кешируют полномочия, и новые полномочия вступают в силу только после очистки кеша командой MQSC REFRESH SECURITY. То же самое необходимо делать после изменения членства пользователя в группах операционной системы.
dspmqaut - используется для отображения полномочий, назначенных определенному пользователю или группе в отношении некоторого объекта.
dmpmqaut - применяется для тех же целей, что и dspmqaut, но предоставляет более подробные сведения. Эта команда особенно удобна, так как позволяет узнать, почему данному пользователю назначаются те или иные привилегии, отображаемые командой dspmqaut (например, в силу членства в группах).
Подробнее об этих командах см. в разделе "WebSphere MQ control commands" руководства WebSphere MQ System Administration Guide, SC34-6584.
11.2.2. Полномочия для объектов в WebSphere MQ для z/OS
Проверка полномочий для объектов WebSphere MQ для z/OS выполняется внешними по отношению к WebSphere MQ средствами - при помощи RACF.
Этот механизм описан выше, в разделе 11.2.1. В этом случае проверка полномочий основана на профилях RACF для отдельных объектов, а не на полномочиях OAM.
Это может быть индивидуальный профиль менеджера очередей либо разделяемый профиль менеджеров группы с разделением очередей (queue sharing group). Различные операции над объектами WebSphere MQ, представляющими менеджеры очередей, требуют различных уровней доступа RACF.
Подробнее об этом см. в разделе "Setting up security" руководства WebSphere MQ для z/OS V6.0 System Setup Guide, SC34-6583.
11.3. Установка контекста идентификационных данных клиентских приложений
Установку контекста идентификационных данных (identity context) проще выполнить для приложений, работающих на одной машине с менеджером очередей и подключающихся к нему с использованием связывания. В этом случае менеджер очередей может считать идентификатор пользователя ОС, под которым работает приложение, подлинным, а правильность аутентификации OAM будет обеспечиваться администрированием системных учетных записей пользователей.
Однако при запуске слушателя менеджер очередей получает идентификационные данные для работы в сети. Через него возможно подключение к менеджеру очередей клиентских приложений.
Контролировать администрирование удаленных машин столь же полно невозможно. Например, некоторые из них могут быть рабочими станциями, пользователи которых обладают полномочиями root и сами могут создавать идентификаторы пользователей. В отдельных случаях хост-имя и порт менеджера очередей также могут быть доступны из публичных сетей, таких как Интернет.
11.3.1. Процедура установки идентификационных данных в WebSphere MQ по умолчанию
Когда приложение подключается к менеджеру очередей по сети в режиме клиента, MCA клиента передает через канал идентификатор пользователя, который будет использоваться менеджером очередей для установки контекста идентификационных данных приложения.
Этот идентификатор пользователя основан на идентификаторе, под которым приложение работает на удаленной машине. Тот же идентификатор пользователя должен существовать на машине, на которой работает менеджер очередей, - это необходимо для успешного подключения. Дальнейшая проверка полномочий осуществляется в данном контексте идентификационных данных.
Примечание. При подключении к удаленному менеджеру очередей клиентский MCA может передавать по каналу идентификатор, отличный от идентификатора на удаленной машине. Например, при подключении к UNIX-машинам передаются первые 12 символов в нижнем регистре идентификатора пользователя, под которым работает приложение. Так, вместо идентификатора Administrator менеджеру очередей в UNIX передается строка admin. Поэтому на машине, где работает менеджер очередей, должен существовать авторизованный идентификатор admin, иначе попытка подключения закончится неудачно.
Учтите, что существуют также стандартные учетные записи пользователя, такие как mqm, и стандартные каналы, например SYSTEM.DEF.SVRCONN. Удаленные приложения могут использовать их для подключения к менеджеру очередей, у которого есть слушатель, привязанный к доступной сети.
Сети часто защищают путем организации интрасетей и установки брандмауэров, и дополнительная защита может не потребоваться. Тем не менее WebSphere MQ поддерживает функции дополнительной защиты подключений.
11.3.2. Идентификатор пользователя MCA
Атрибут канала серверного подключения "идентификатор пользователя MCA" ( MCAUSER ) позволяет изменять процедуру назначения идентификационных данных по умолчанию, описанную выше. Все клиентские приложения, подключающиеся через канал, для которого задан этот атрибут, получают одинаковые полномочия в отношении менеджера очередей (независимо от идентификатора, под которым они работают на удаленной машине).
Значением этого параметра (оно чувствительно к регистру) является идентификатор пользователя, определенный на машине, где работает менеджер очередей. Все клиентские приложения, подключающиеся к менеджеру очередей по каналу с заданным таким образом именем, получают полномочия соответствующего локального пользователя.
Этот метод позволяет снизить нагрузку по администрированию удаленных компьютеров, позволяя клиентским приложениям работать на другом компьютере под любым идентификатором пользователя.
Кроме того, можно ограничить доступ к ресурсам менеджера очередей, назначив соответствующий уровень доступа идентификатору пользователя MCA для канала серверного подключения. Однако в некоторых случаях требуется предоставить полный доступ к машине, например для удаленного администрирования WebSphere MQ Explorer.
Некоторые менеджеры очередей никогда не принимают клиентские подключения и тем не менее имеют активные слушатели для каналов передачи сообщений. В этом случае для каналов серверных подключений могут быть указаны недопустимые значения атрибута "идентификатор пользователя MCA". В результате клиентским приложениям не удается подключиться к этому менеджеру очередей.
Само по себе применение идентификатора пользователя MCA не всегда гарантирует безопасность каналов связи с менеджером очередей. В этих обстоятельствах защита контекста идентификационных данных и конфиденциальности подключений осуществляется с использованием протоколов Secure Sockets Layer (SSL) и Transport Layer Security (TLS).
11.4. Secure Sockets Layer (SSL)
Secure Sockets Layer (SSL) - это промышленный стандарт технологий защиты конфиденциальных данных при передаче по публичным сетям и проверки подлинности контекста идентификационных данных.
В основе SSL лежит ряд фундаментальных понятий: симметричная и асимметричная криптография, дайджест сообщений, цифровая подпись и цифровой сертификат, CipherSuite и центры сертификации. Эти понятия существуют во всех реализациях SSL.
Разъяснение этих понятий приводится во введении к руководству WebSphere MQ Security, SC34-6588.
11.4.1. Поддержка SSL в WebSphere MQ
WebSphere MQ позволяет защищать при помощи SSL любые типы каналов: распределенные и кластерные каналы передачи сообщений, а также клиентские каналы.
SSL применяют для проверки подлинности удостоверений удаленных приложений и менеджеров очередей.
SSL также применяют для обеспечения конфиденциальности и целостности данных при передаче через каналы связи.
11.4.2. CipherSpec
Чтобы защитить канал с помощью SSL, необходимо занести строку CipherSpec в атрибут "SSL Cipher Specification" ( SSLCIPH ) объекта канала.
Имя CipherSpec определяет алгоритмы шифрования и вычисления кода проверки подлинности сообщения (message authentication code, MAC), которые будут использоваться для установленного канала.
Каждому значению CipherSpec в WebSphere MQ соответствует CipherSuite других поддерживающих SSL приложений, у которых в CipherSuite используется обмен ключами по протоколу RSA.
Различные значения CipherSpecs предоставляют различные уровни безопасности и быстродействия. Подробнее об этом см. в разделе "Working with CipherSpecs" руководства WebSphere MQ Security, SC34-6588.
Примечание. Для канала может быть задано только одно значение CipherSpec, которое к тому же должно соответствовать значению канала-партнера. При подключении клиентских Java-приложений или WebSphere MQ Internet Pass-Thru значение CipherSpec должно быть совместимо с параметром CipherSuite, указанным Java-клиентом или экземпляром WebSphere MQ IPT.
11.4.3. Протокол TLS
Transport Layer Security (TLS) версии 1.0 - протокол, сходный с SSL 3.0, с рядом дополнений, повышающих надежность защиты каналов связи.
В WebSphere MQ V6.0 использование протокола TLS задается некоторыми значениями CipherSpec, подробнее об этом см. в разделе "Transport Layer Security (TLS) concepts" руководства WebSphere MQ Security, SC34-6588.
Примечание. Все сказанное в следующих разделах этой главы про SSL верно и для TLS.
11.4.4. Обязательная и необязательная SSL-аутентификация клиентов
В SSL-взаимодействии вызывающая сторона традиционно называется SSL-клиентом, а отвечающая - SSL-сервером.
Во время первоначального SSL-взаимодействия (handshake) проверяется подлинность SSL-сервера, но не SSL-клиента. Так, при подключении браузера к сайту Интернет-магазина подлинность сайта проверяется с использованием цифрового сертификата, тогда как браузеру предъявлять свой сертификат, как правило, не обязательно.
В каждой допустимой паре каналов в WebSphere MQ один из MCA играет роль SSL-клиента, а другой MCA - SSL-сервера. При этом receiver-канал и канал серверного подключения являются SSL-серверами.
Объект канала на стороне SSL-сервера можно настроить так, чтобы он запрашивал у SSL-клиента действительный сертификат либо позволял ему предъявлять сертификат по желанию. Это делается при помощи атрибута "SSL Client Authentication" ( SSLCAUTH ). Независимо от значения этого атрибута, если SSL-клиент предъявляет сертификат, последний должен быть успешно проверен SSL-сервером.
11.4.5. Хранилище сертификатов менеджера очередей
У каждого менеджера очередей имеется собственное хранилище сертификатов. Оно содержит персональные сертификаты и закрытые ключи, идентифицирующие данный менеджер в инфраструктуре. Там же находятся открытые сертификаты всех доверяемых сущностей. Это могут быть как самоподписанные сертификаты, так и открытые сертификаты публичных центров сертификации (ЦС), выдающих сертификаты для нужд инфраструктуры.
Атрибут "SSL Key Repository" ( SSLKEYR ) объекта менеджера очередей идентифицирует хранилище ключей данного менеджера. Подробнее об этом см. в разделе "ALTER QMGR" руководства WebSphere MQ Script (MQSC) Command Reference, SC34-6597.
Менеджер очередей определяет, какой из находящихся в данном хранилище сертификатов ему следует использовать в качестве персонального сертификата, с помощью метки, или понятного имени сертификата. При этом метка должна быть определена в корректном формате. Подробнее см. в разделе "Setting up SSL communications" руководства WebSphere MQ Security, SC34-6588.
) позволяет скорректировать метку сертификата в PKCS12-файле перед импортом его в хранилище ключей WebSphere MQ.
11.4.6. Администрирование хранилищ сертификатов WebSphere MQ
Подробно администрирование сертификатов освещается в разделе "Working with WebSphere MQ SSL support" руководства WebSphere MQ Security, SC34-6588. В число административных задач управления сертификатами входит:
создание хранилища ключей для менеджера очередей;
выпуск самоподписанных сертификатов;
создание запросов для ЦС;
получение от ЦС подписанных сертификатов;
добавление сертификата доверенного ЦС в хранилище;
импорт персонального сертификата и закрытого ключа из PKCS12-файла;
экспорт персонального сертификата и закрытого ключа в PKCS12-файл;
извлечение открытого ключа из хранилища.
Дополнительные сведения о полном наборе функций утилит командной строки IBM GSKit iKeycmd, поставляемых с WebSphere MQ для Windows и UNIX, см. в разделе "Managing keys and certificates" руководства WebSphere MQ System Administration Guide, SC34-6584.
Примечание. Не забывайте о защите файловой системы хранилища ключей менеджера очередей. В частности, необходим контроль доступа к .kdb- и .sth-файлам.
11.4.7. Клиентские приложения WebSphere MQ
Администрирование хранилища сертификатов клиентских приложений, написанных на C и C++, во многом сходно с таковым для менеджера очередей.
Эти хранилища имеют одинаковый формат и административный интерфейс. Переменная окружения MQSSLKEYR определяет расположение хранилища и используется так же, как атрибут SSLKEYR менеджера очередей. О требованиях к формату метки (понятного имени) персональных сертификатов, содержащихся в хранилищах, см. в разделах "Setting up SSL communications" и "Working with the Secure Sockets Layer (SSL) on UNIX and Windows systems" руководства WebSphere MQ Security, SC34-6588.
Чтобы настроить CipherSpec для канала при подключении к менеджеру очередей, используют таблицу определений клиентских каналов (CCDT).
Альтернативный вариант - явно указать расположение хранилища ключей и CipherSpec. Это делается путем добавления структур MQCD и MQSCO к структуре MQCNO, передаваемой при вызове MQCONNX (см. руководство WebSphere MQ Application Programming Reference, SC34-6596).
11.4.8. Доступ клиентских Java-приложений к WebSphere MQ
Java-приложения могут получать доступ к инфраструктуре WebSphere MQ как клиенты через каналы, защищенные SSL. В число этих приложений входят WebSphere MQ Explorer и приложения, исполняемые сервером приложений WebSphere.
В этих случаях клиентские MCA используют одну из реализаций Java Secure Sockets Extension (JSSE) для SSL-аутентификации у менеджера очередей, подробнее см. в разделе "Secure Sockets Layer (SSL) support" руководства WebSphere MQ Using Java, SC34-6591.
Примечание. В JSSE для хранения ключей используется файл формата Java KeyStore (JKS), отличный от формата хранилища ключей менеджеров очередей WebSphere MQ. Однако с WebSphere MQ для Windows и UNIX поставляются утилиты KeyMan, которые служат для администрирования хранилища ключей в формате JKS. В набор KeyMan входит утилита командной строки gsk7cmd и gsk7ikm - инструмент с графическим интерфейсом пользователя (graphical user interface, GUI). Альтернатива KeyMan - утилита keytool из стандартной поставки исполняющей среды Java Runtime Environment (JRE).
Ниже вы найдете сводку операций по настройке Java-приложений для подключения с использованием SSL и стандартной реализации JSSE.
Укажите CipherSuite, соответствующий CipherSpec в определении канала серверного подключения, объявленного на сервере:для приложений, использующих базовый Java API, CipherSuite можно указать в атрибуте sslCipherSuite объекта MQEnvironment либо в свойстве MQC.SSL_CIPHER_SUITE_PROPERTY таблицы хеш-значений, передаваемой конструктору объекта MQQueueManager. Альтернативный вариант (в WebSphere MQ V6.0) - передать конструктору объекта MQQueueManager таблицу CCDT с каналом, для которого задан соответствующий атрибут SSL Cipher Specification ( SSLCIPH );
для JMS-приложений CipherSuite можно указать при помощи атрибута SSLCIPHERSUITE объекта ConnectionFactory. Альтернативный вариант (в WebSphere MQ V6.0) - передать через атрибут CCDTURL объекта ConnectionFactory таблицу CCDT с каналом, для которого задан соответствующий атрибут SSL Cipher Specification ( SSLCIPH ).
Укажите расположение и пароль для JSSE KeyStore; в хранилище должен быть минимум один персональный сертификат с закрытым ключом. Метка этого сертификатав KeyStore не имеет значения для клиентских Java-приложений. Хранимые в KeyStore сертификаты защищены паролем, поэтому для доступа к KeyStore необходим пароль. По умолчанию параметры для доступа к JSSE KeyStore указывают с помощью следующих Java-свойств:javax.net.ssl.keyStore
javax.net.ssl.keyStorePassword
Укажите размещение JSSE TrustStore. В TrustStore должны быть открытые сертификаты всех ЦС, которым доверяет Java-приложение. Обычно эти сертификаты хранятся в JKS-файле, не защищенном паролем, поэтому указывать пароль не требуется. TrustStore и KeyStore могут храниться в одном файле. По умолчанию параметры для доступа к JSSE TrustStore указывают с помощью следующих Java-свойств:javax.net.ssl.trustStore
javax.net.ssl.trustStorePassword
11.4.9. SSL и WebSphere MQ Explorer
WebSphere MQ Explorer подключается к менеджерам очередей как клиентское Java-приложение.
Настроить доступ к JSSE KeyStore и TrustStore можно в секции SSL Client Certificate Stores окна WebSphere MQ Preferences (рис 11.1).
(рис 11.1)
