Как получить кредитные сертификаты на вход в систему клиенту службы JAX-WS со связанными наборами политик и привязками в инструментах Rational/WebSphere

Question

Я специально использую WebSphere Integration Developer V7, но я также мог бы использовать Rational Software Architect V 7.5.1 (как у меня обоих).

Контекст: я пытаюсь создать клиент JAX-WS для вызова служб Human Task Manager и Business Flow Manager в WebSphere Process Server V7, которые доступны через JAX-WS. По умолчанию к ним прикреплены наборы политик и привязки провайдера, которые определяют некоторые параметры WS-Security (так как они не определены в WSDL).

Я понял, как заставить его работать с помощью динамического веб-проекта. Я смог сгенерировать код клиента JAX-WS из WSDL. Мне удалось экспортировать наборы политик и привязки провайдера и клиента из Process Server и импортировать их в мое рабочее пространство. Мне удалось прикрепить набор политик и привязки клиента к клиентскому сервису. Мне удалось настроить страницу и сервлет для вызова моего веб-сервиса (для проверки клиента). И я смог настроить параметры безопасности в дескрипторах развертывания и файлах привязки / расширения websphere, чтобы заставить его работать.

Это все замечательно, но в действительности мы не хотим войны с тем, чтобы выставлять клиента веб-сервиса другим нашим приложениям, которые мы пишем. Мы хотим создать jar-файл веб-службы и упаковать его в другие приложения.

Учитывая эту точку зрения, я смог понять, как использовать обычный Java-проект в моей IDE, и сгенерировать в нем клиент веб-службы. Я также смог прикрепить набор политик и привязки клиента к клиенту.

Моя проблема сейчас, как я могу это вызвать? Я создал динамический веб-проект с моей страницей и сервлетом, как и прежде, для тестирования моего клиента. Я настроил свой клиентский проект как зависимость от веб-библиотеки, чтобы он имел доступ к клиентскому коду. Я даже могу настроить дескрипторы развертывания, как и раньше, для принудительного входа в систему и аутентификации. Единственная проблема сейчас заключается в том, что я не могу понять, как передать учетные данные моему веб-сервису сейчас, когда он находится в собственном "фляге". Раньше у меня был доступ к меню для настройки TokenGenerator и CallbackHandler. Теперь у меня нет доступа к этим меню, так как клиент не находится в динамическом веб-проекте. Так что теперь у меня есть "отключение", и это, конечно, не удается при попытке запустить его на сервере.

Должен быть способ сделать это. Я должен быть в состоянии сгенерировать JAR-файл клиента и передать ему то, что ему нужно Кто-нибудь сталкивался с этим раньше?

Answer 1

Хорошо. Я потратил много времени на изучение этого, читая справочники и статьи разработчиков, стуча головой по клавиатуре, и я наконец-то кое-что нашел. Не совсем так, но почти. (Хотелось бы, чтобы кое-что из IBM было легче найти... но вы работаете с тем, что вам дают. И, честно говоря, с тем, что я прочитал, это имеет смысл и довольно мощно.)

В любом случае, здесь есть хитрость для инструментов Rational и WebSphere: сначала нужно создать пустой Java-проект. Это один из ключей к созданию портативного клиента веб-службы.

Так что вот так далеко:

1. Создайте пустой Java-проект в вашей IDE. Я предпочитаю использовать перспективу Java EE в Rational Application Developer/Software Architect или в WebSphere Integration Developer.
2. Импортируйте WSDL и схемы в другой пустой универсальный проект в вашей IDE, а НЕ во вновь созданный Java-проект.
3. Щелкните правой кнопкой мыши основной WSDL и выберите создание клиента веб-службы.
4. Еще один ключ: убедитесь, что в появившемся мастере вы изменили клиентский проект на Java-проект, созданный на первом шаге. По умолчанию мастер будет пытаться настроить таргетинг на новый или существующий динамический веб-проект, а это НЕ то, что вам нужно.
5. Убедитесь, что вы выбрали JAX-WS в качестве своей реализации. Убедитесь, что вы хотите, чтобы клиент был "переносимым", и убедитесь, что вы указываете мастеру включить WSDL в клиент Java Project.
6. Пока у вас все в порядке (и ваш локальный сервер работает), инструментальные средства Rational/WebSphere теперь должны сгенерировать клиента веб-службы JAX-WS в Java Project.

Замечательно! Большой! Теперь у вас есть Java-проект (он же jar), который вы можете использовать, чтобы сделать его переносимым. Но как сделать инструмент IBM счастливым и прикрепить политики безопасности к клиенту?

Ну, во-первых, я узнал, что действительно лучше подключить политики безопасности в административной консоли WebSphere Application Server/Enterprise Service Bus/Process Server. Слишком много вещей, чтобы попытаться объяснить их безопасностью, пытаться вручную все это кодировать, даже несмотря на то, что IBM предоставляет вам API для этого. Доверьтесь мне. Проще определить безопасность на сервере, а затем просто назначить ее клиенту.

В любом случае.... для того, чтобы клиент был виден консоли администратора для присоединения наборов политик и привязок клиента для безопасности JAX-WS, он должен быть на "веб-уровне" (из-за отсутствия лучшего термина) в для того, чтобы он увидел банку в качестве веб-клиента. Это означает, что присоединение jar-файла как J2EE Utility Jar к проекту EAR не будет работать. EAR - это не "веб-уровень", а "уровень приложения". Поэтому для этого вам нужно связать Java-проект с EAR на экране Зависимости модуля J2EE, но НЕ как Utility Jar. Вместо этого установите флажок "lib". Это означает, что он может быть виден / смонтирован в каталоге lib динамического веб-проекта / войны (что вы также должны сделать). Удивительно, но консоль администратора теперь увидит ваш клиентский jar как настоящий клиент веб-службы JAX-WS! И теперь вы можете связать с ним наборы политик и привязки клиентов, чтобы удовлетворить ваши потребности в безопасности!

Поначалу это может показаться странным, но это имеет смысл. В конце концов, вы имеете дело с веб- сервисом и используете веб-протоколы, поэтому в некотором смысле имеет смысл поместить клиента на " веб-уровень " вашего приложения.

РЕДАКТИРОВАТЬ: я перепутал с политиками безопасности, и я обнаружил, что эта статья о разработчиках мне помогла больше всего. Обратите особое внимание на листинг 2 ClientTest.java. К сожалению, вы должны закодировать всю безопасность в вашем клиенте, чтобы заставить его работать максимально чисто. А потом вот еще одна ошибка. IBM позволит вам создавать токены имени пользователя на клиенте, работающем вне WebSphere, но они НЕ позволят вам создавать токены LTPA вне WebSphere. Таким образом, чтобы протестировать эти типы токенов, вы должны упаковать и развернуть свой клиент локально, чтобы протестировать все это.