Среда выполнения Java (JRE), которую использует рабочая среда, должна поддерживать уровень шифрования, требуемый выбранным цифровым сертификатом. Например, невозможно использовать цифровой сертификат, который требует 256-разрядного шифрования, с JRE, которая поддерживает только 128-разрядное шифрование. По умолчанию рабочая среда настроена с помощью ограниченных шифров. Для использования менее ограниченных алгоритмов шифрования необходимо загрузить и применить файлы стратегии неограниченной юрисдикции (local_policy.jar и US_export_policy.jar).
Эти файлы стратегии неограниченной юрисдикции можно загрузить с сайта: http://www.ibm.com/developerworks/java/jdk/security/50/
Щелкните на ссылке Файлы IBM SDK Policy, а затем войдите в developerWorks для получения файлов стратегии неограниченной юрисдикции. Перед установкой этих файлов стратегии скопируйте существующие файлы стратегии, если вы хотите восстановить первоначальные файлы позже. Затем перезапишите файлы в каталоге /jre/lib/security/ на файлы стратегии неограниченной юрисдикции.
Простая аутентификация (аутентификация сервера): В этом случае тестовый клиент должен определить, можно ли доверять службе. Вам не обязательно устанавливать хранилище ключей. Если выбрана опция Всегда доверять, не обязательно предоставлять хранилище ключей сертификатов сервера.
Если необходимо фактически аутентифицировать службу, можно настроить хранилище доверенных сертификатов, которое содержит сертификаты надежных служб. В этом случае тест будет ожидать получения верного сертификата.
Двойная аутентификация (аутентификация клиента и сервера): В этом случае служба должна аутентифицировать тестовый клиент в соответствии с его корневыми полномочиями. Вам необходимо предоставить хранилище ключей сертификатов клиента, которое должно быть создано для аутентификации теста как сертифицированного клиента.
Когда тест службы записывается через прокси, прокси записи находится между службой и клиентом. В этом случае необходимо настроить параметры SSL прокси записи для аутентификации себя как фактической службы на клиенте (для простой аутентификации), и как клиента в службе (для двойной аутентификации). Это означает, что необходимо предоставить прокси записи соответствующие сертификаты.
При использовании заготовок служб можно также настроить параметры SSL заготовки службы для аутентификации себя как фактического сервера. Это означает, что необходимо предоставить заготовке службы соответствующий сертификат.
Продукт поддерживает аутентификацию Microsoft NT LAN Manager (NTLMv1 и NTLMv2) и Kerberos. Информация об аутентификации записывается как часть теста на этапе записи.
Для того чтобы включить поддержку NTLMv2 необходимо добавить библиотеку другой фирмы в рабочую среду. Дополнительная информация приведена в разделе Настройка рабочей среду для идентификации NTLMv2.
Можно протестировать службы с помощью цифровых сертификатов и для SSL, и для протокола защиты SOAP. Цифровые сертификаты должны содержаться в ресурсах хранилища ключей Java Key Store (JKS), доступных в рабочей области. При работе с файлами хранилища ключей необходимо установить пароль, требуемый для доступа к ключам в редакторе защиты и редакторе тестов. Для защиты SOAP может потребоваться предоставить явное имя ключа и пароль для доступа к личным ключам в хранилище ключей.
Массивы не поддерживаются.
Транспортный протокол службы сообщений Java (JMS) не поддерживает вложение, поскольку отсутствует требуемая спецификация. Пакет отправляется в кодировке UTF-8.
Отдельные реализации среды выполнения Java поддерживают не все алгоритмы защиты. Если конкретная реализация защиты недоступна, добавьте требуемые библиотеки в путь к классам среды JRE, применяемой продуктом.
В инструменте тестирования общих служб отображается пакет, указанный в документе XML. Однако алгоритмы защиты считают конверт двоичным. Таким образом, конфигурация защиты SOAP должна обеспечивать шифрование входящих и исходящих сообщений, сохраняя их в исходном виде в пределах теста.
Производительность виртуального пользователя зависит от реализации приложения контейнера. Для транспортного протокола HTTP продукт протестирован с максимум 900 параллельными виртуальными пользователями в системе Windows и 600 пользователями в системе Linux. Для JMS использовалось максимум 100 параллельных виртуальных пользователей, хотя это число может измениться из-за асинхронной реализации JMS. За пределами этих значений могут возникнуть ошибки соединения и частота транзакций будет уменьшена.