понедельник, 20 января 2014 г.

Несколько слов об использовании OWSM политик веб-сервисов в ADF Mobile

Стоит ли напоминать о том, что технология веб-сервисов остается наиболее популярным механизмом интеграции информационных систем, являясь также средством поддержки сервис-ориентированной архитектуры SOA. Принимая во внимание все очевидные достоинства этой технологии нельзя обойти вопрос кастомизации сервисов, в частности вопрос обеспечения безопасности: кто захочет публиковать незащищенный сервис, подвергая опасности корпоративные бизнес данные? Не менее актуален данный вопрос и для корпоративных мобильных приложений, использующих веб-сервисы для обмена данными и синхронизации с корпоративными информационными системами. ADF Mobile предлагает довольно широкие возможности такой интеграции с использованием SOAP и RESTful сервисов. Но давайте посмотрим, а чем могут помочь продукты стека Oracle FMW для решения задачи кастомизации веб-сервисов и, в частности, обеспечения их безопасности.

Oracle Web Services Manager (OWSM) - это компонент стека Oracle Fusion Middleware, обеспечивающий возможность создавать и управлять политиками безопасности и управления, которые могут быть применены к веб-сервисам, развертываемым внутри домена Oracle WebLogic Server. Возникает логичный вопрос: а в чем преимущество этих политик и зачем вообще они нужны? Отвечаем: часто веб-сервисы, развертываемые внутри FMW среды нуждаются в специфической конфигурации для настройки их поведения и для удовлетворения требований безопасности, качества обслуживания и управления. Такую кастомизацию удобнее применять отдельно от реализации бизнес логики службы через внешние политики, применяемые к сервисам во время их вызова. 

Ниже я приведу источники, которые могут быть полезны для ознакомления с продуктом OWSM:


Но, вернемся к нашей основной теме. Ниже я продемонстрирую, как настроить отдельный WebLogic ADF продуктивный домен с защищенным веб-сервисом и как сконфигурировать ADF Mobile приложение, вызывающее этот защищенный сервис. В нашем примере мы будем использовать WebLogic версии 10.3.6, платформу Oracle ADF версии 11.1.2.4. В продукционной среде OWSM политики настраиваются при помощи консоли Enterprise Manager FMW Control, поэтому дополнительно необходимо расширить домен с использованием опций Oracle JRF и Oracle Enterprise Manager.

Конфигурирование серверного окружения


1. Для развертывания серверных компонентов необходимо последовательно проинсталлировать Oracle Weblogic Server (в нашем случае версии 10.3.6), Application Development Runtime 11.1.1.6 и далее накатить соответствующие патчи для обновления платформы Oracle ADF до версии 11.1.2.4. Я не буду подробно акцентировать на этом внимание, т.к. об этом уже писал в предыдущих статьях блога. Отмечу лишь, что для демонстрационного примера кластеризация и высокая доступность не нужна и достаточно только одного управляемого (managed) сервера или даже Admin сервера. Полезную информацию можно найти в следующих статьях:
2.    Для использования компонента OWSM необходимо иметь специально созданную для хранения метаданных схему в БД. Создать её можно использую утилиту RCU (Repository Creation Utility) - подробнее можно ознакомиться здесь: http://docs.oracle.com/cd/E28280_01/doc.1111/e14259/rcu.htm.  В нашем случае использовалась RCU версии 11.1.1.6. Каких-то сложностей в ее использовании нет, подробнее остановлюсь лишь на шаге 3 где происходит выбор компонентов. Здесь, для конфигурирования OWSM достаточно выбрать только элемент AS Common Schemas в дереве компонентов.


3.       После завершения этапов создания схемы метаданных и установки программных компонентов, необходимо развернуть и настроить домен. Для его конфигурирования необходимо запустить Configuration Wizard и добавить поддержку следующих продуктов: Oracle Enterprise Manager, Oracle WSM Policy Manager, Oracle JRF.


4.       Далее необходимо завершить настройку домена, указав остальные настройки (напоминаю, в простейшем случае для демонстрационных целей достаточно иметь домен с одним Admin сервером)
  

Применение политики безопасности для веб-сервиса

Как я уже упоминал ранее, для конфигурирования OWSM, используется инструмент Enterprise Manager FMW Control. В нашем примере мы применим серверную политику oracle/wss_username_token_service_policy – предполагающую использование данных аутентификации (credentials) в SOAP заголовке для процесса аутентификации.
1.      Для применения политики необходимо авторизоваться в EM.
2.      Выбрав соответствующее приложение в дереве Application Deployments, необходимо вызвать контекстное меню и выбрать пункт меню Web Services.


3.       Далее необходимо выбрать соответствующий сервис в таблице Web Services


4.        Нажав кнопку Attach/Detach перейдите в соответствующий раздел и выберите политики, которые необходимо применить к веб-сервису (в нашем случае это oracle/wss_username_token_service_policy):




5.       После завершения процесса конфигурации необходимо нажать на кнопку OK. Конфигурирование серверного окружения завершено.

Конфигурирование мобильного клиента

Для корректного вызова сервиса с примененными политиками необходимо также правильно сконфигурировать и клиентское приложение. В нашем случае это будет мобильное приложение, разработанное с использованием платформы Oracle ADF Mobile. В настоящее время ADF Mobile использует Oracle Web Services Manager (OWSM) Lite Mobile ADF Application Agent для создания и конфигурирования прокси. Также ADF Mobile поддерживает следующие политики безопасности для SOAP веб-сервисов:
  • oracle/wss_http_token_client_policy - включает данные аутентификации в HTTP заголовок для исходящих клиентских запросов.
  • oracle/wss_http_token_over_ssl_client_policy - включает данные аутентификации в HTTP заголовок для исходящих клиентских запросов с использованием траспортного протокола HTTPS.
  • oracle/http_basic_auth_over_ssl_client_policy
  • oracle/wss_username_token_client_policy - включает в себя данные аутентификации в WS-Security UsernameToken заголовке во всех исходящих SOAP сообщениях. Эта политика не безопасная и применяется в демонстрационных целях, т.к. пароль передается в незашифрованном виде.
  • oracle/wss_username_token_over_ssl_client_policy- включает в себя данные аутентификации в WS-Security UsernameToken заголовке во всех исходящих SOAP сообщениях. Эта политика преполагает защиту с использованием SSL протокола.    

Для веб-сервисов, к которым применена политика безопасности, данные для аутентификации динамически внедряются в запрос во время вызова сервиса. Подробнее про вызов защищенных сервисов в ADF Mobile узнать здесь: (http://docs.oracle.com/cd/E37975_01/doc.111240/e24475/amxwebservices.htm#autoId10)
Т.к. вызываемая SOAP служба защищена политикой oracle/wss_username_token_service_policy вызов её можно осуществлять использую политику oracle/wss_username_token_client_policy на стороне клиента.

Необходимо также отметить что в общем случае перед вызовом защищенной службы необходимо, чтобы пользователь прошел аутентификацию с использованием login сервера. Подробнее об этом можно узнать здесь: 
http://docs.oracle.com/cd/E37975_01/doc.111240/e24475/security.htm#CDDGGAAC и здесь:
http://docs.oracle.com/cd/E37975_01/doc.111240/e24475/security.htm#CDDHGJAG

Для конфигурации сервиса необходимо выполнить следующее:

1. Открыв проект ADF Mobile приложения в среде Oracle JDeveloper, выберите артефакт DataControls.dcx в окне Projects (Application Navigator).


2. Перейдите в окно Structure и, выделив, имя Data Control артефакта (в нашем случае это BankingSDOService) и вызвав контекстное меню, выберите пункт Define Web Service Security


3. В окне Edit Data Control Policies выберите oracle/wss_username_token_client_policy элемент в списке Policies list и нажмите OK.


4. В окне Application Resources, выберите в дереве пункт Descriptions ADF META-INF → connections.xml и дважды кликните для открытия в редакторе.



5. В редакторе выделите соответсвующий Reference элемент в котором определен SOAP Data Control (в нашем случае это «BankingSDOService»), перейдите в редактор Property Inspector  и задайте значение параметра adfCredentialStoreKey (в нашем случае это «MobileBankingLoginServer»).


Конфигурирование сервиса в клиентском приложения завершено. После того, как пользователь пройдет процесс аутентификации, он может вызывать защищенный сервис. В запрос, выполняемый к удаленной службе, будут внедрены данные аутентификации, необходимые для вызова службы.


И еще одна рекомендация: WSM сервер лучше не выставлять без всякой защиты во внешнюю сеть, оптимально использовать DMZ как средство дополнительной защиты.

Комментариев нет:

Отправить комментарий