Политики для Web-сервисов

Имеются разные спецификации, дополняющие базовую архитектуру Web-сервисов средствами защиты, надежного обмена сообщениями и выполнения транзакций. В будущем, вероятно, появятся спецификации для обеспечения секретности, авторизации, управления сеансами и т.д. Трудность состоит в том, что эти спецификации должны иметь множество опций, чтобы справляться с требованиями самых разных приложений. Как потенциальный клиент может узнать, какие опции необходимы для конкретного Web-сервиса или поддерживаются им? Как указать сервису, какие опции нужно поддерживать?

Функциональные уровни

Сервисы и их администраторы могут использовать политики следующим образом:

администратор с помощью политики выбирает для сервиса определенное подмножество опций;
поставщик услуг публикует свои политики, чтобы разработчики могли программировать в соответствии с ними потребительские сервисы и клиентские приложения;
потребительские сервисы сравнивают собственные политики с политиками потенциальных поставщиков, чтобы убедиться в их совместимости;
сервисы выбирают совместимые опции политик для взаимодействия друг с другом;
сервисы проверяют транзакции на соответствие согласованным политикам;
сторонние посредники или агенты используют политики, чтобы найти для потребителя подходящего поставщика;
сервисы объединяются друг с другом, чтобы предоставить потребителям более эффективные комплексные услуги, учитывающие политики всех задействованных сервисов.

Для полного раскрытия потенциальных возможностей политик необходимы многочисленные функции их обслуживания, в том числе механизмы транспортировки, идентификации, автоматизации переговоров, инструменты разработки и анализа, проверки соответствия и управления жизненным циклом. Реализующие такие функции продукты разных поставщиков могут оказаться несовместимыми, хотя для выполнения некоторых задач они должны быть интероперабельными. Поскольку протоколы выражения политики, связи политик с интерфейсами сервисов и переговоров о политиках затрагивают интероперабельность, в этих областях наиболее важны открытые стандарты.

Прежде в отрасли уделялось недостаточно внимания политикам сервисов на стороне потребителя и ведению переговоров о политиках между потребителями и поставщиками. На современной стадии развития Web-услуг сервис поставщика определяет свои политики, а разработчики выбирают на стороне клиента (с помощью зависящих от реализации методов) набор опций политики для каждого интерфейса.

Хотя группы стандартизации еще не работают над переговорами о политиках, имеются несколько проектов стандартов для выражения политики и ее связи с сервисами поставщика. Для осмысления предлагаемых стандартов полезно разобраться в том, к каким аспектам политики относится каждый из них. Мы можем логически разделить эти аспекты на функциональные уровни, расположенные один над другим:

уровень привязки к интерфейсу связывает политику с интерфейсом сервиса;
уровень привязки к домену связывает политику с предметной областью или «доменом» (таким, как аутентификация или надежный обмен сообщениями);
уровень политики определяет наборы допустимых опций;
уровень формулировок, или предикатов, определяет отдельные опции политики;
уровень словарей определяет переменные и значения в опциях политики.

На рисунке эти уровни показаны на примере политики аутентификации, которая гласит: «Используйте либо сертификат X.509 с длиной ключа не менее 1024 бит, либо билет TGT (ticket-granting ticket) протокола Kerberos». Разные цвета текста на рисунке обозначают части политики, относящиеся к различным функциональным уровням.

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

Уровень привязки к интерфейсу (фиолетовый) связывает описание интерфейса Web-сервиса с политикой — в данном случае с помощью идентификатора политики. Он также может связать политику с группой интерфейсов. В этом случае важно знать, дополняет ли групповая политика индивидуальные политики, относящиеся к отдельным интерфейсам в группе, или их отменяет.

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

Уровень политики (черный) — это собственно политика. В языках описания политик, предлагаемых для Web-сервисов, уровень политики предоставляет пакет политик вместе с логическими операторами типа AND и XOR. Он дает возможность разработчикам политики комбинировать опции политик, указанные на следующем уровне.

Уровень формулировок (зеленый) состоит из предикатов, называемых формулировками, которые определяют конкретные опции политики. Этот уровень устанавливает ограничения на переменные и значения, указанные на следующем уровне — в словаре.

Уровень словаря (голубой) определяет имена переменных и их возможные значения, используемые в домене политики. Формулировка связывает переменную, определенную в словаре политики домена, с одним или несколькими допустимыми значениями, также определенными в словаре.

Используются два подхода к построению формулировок. Например, чтобы сформулировать требование «для аутентификации следует использовать сертификаты X.509 с минимальной длиной ключа 1024 бит», разработчик политики может создать новую структуру XML. В качестве альтернативы допустимо применять язык функций ограничения общего вида. Подобные функции есть, например, в языках XACML (Extensible Access Control Markup Language) [1], XQuery и XPath [2]. При этом подходе мы можем выразить то же самое требование с помощью двух функций ограничения:

Технические комитеты в группах стандартизации, таких как OASIS (Organization for the Advancement of Structured Information Standards) и Консорциум W3C (World Wide Web Consortium), уже определили словари политик для некоторых доменов общего характера. Отраслевые группы, вероятно, дополнят их словарями для собственных отраслевых доменов. Если политики не используют функции ограничения, разработчик словаря должен также определить новые структуры XML, чтобы связать элементы словаря со значениями (как в первом примере), а также определить, как программное обеспечение политики должно интерпретировать эти структуры.

Положение дел в стандартизации

Политики рассматриваются в нескольких комитетах и рабочих группах OASIS и W3C. В таблице перечислены некоторые проекты стандартов, относящихся к разным функциональным уровням.

Уровень политики, очевидно, является ключевым для политик Web-сервисов, поскольку определяет общую модель политик. В 2002 году группа ведущих производителей разработала для этого уровня язык WS-Policy [3], который получил широкую поддержку, хотя его проприетарный характер оказался серьезным барьером на пути к специфицированию других уровней. В апреле 2006 года производители представили на рассмотрение W3C окончательный вариант WS-Policy в качестве проекта стандарта.

Еще одно предложение на уровне политики — дополнить язык WSDL (Web Services Description Language) логическими операторами. Однако оно не получило достаточной поддержки W3C (lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html). Одно из возражений состояло в том, что ссылаться на политику нужно не только в описании интерфейса сервиса, поэтому предпочтительно более общее решение.

Есть предложение использовать некоторую форму языка XACML, который уже одобрен стандартом OASIS для управления политиками доступа и авторизации, выраженными на языке XML. Правда, XACML не предназначен для роли языка общего назначения, обеспечивающего описание политик Web-сервисов. Технический комитет XACML разработал профиль XACML, подходящий для описания политик Web-сервисов [4] общего характера и политик авторизации Web-сервисов. Однако стандартизация этого профиля приостановлена из-за разногласий по поводу того, входит ли «политика Web-сервисов» в сферу деятельности комитета.

На основе уровня политики строится уровень привязки к домену. Язык WS-Policy имеет средства определения идентификаторов предметной области (хотя в спецификации эти идентификаторы не всегда используются последовательно, процесс стандартизации должен прояснить данный механизм). Профиль XACML для Web-сервисов также определяет механизм привязки к домену, но передача WS-Policy в группу стандартизации почти не оставляет стимулов для поиска альтернатив на данном уровне.

Уровень привязки к интерфейсу строится на базе уровней политики и привязки к домену. Чтобы удовлетворить требованиям на этом уровне, разработчики WS-Policy создали отдельный проект стандарта WS-PolicyAttachment [5], который расширяет WSDL за счет включения привязки к политике. Спецификация WS-PolicyAttachment была предоставлена W3C в апреле, вместе с WS-Policy. Профиль XACML для Web-сервисов также определяет механизм привязки к интерфейсу, но теперь почти не осталось мотивации для его совершенствования.

Уровень политики строится на базе уровня формулировок. Несколько групп стандартизации предполагали, что WS-Policy или нечто подобное в конечном счете станет стандартом, и работали с этой моделью. Поскольку в WS-Policy не установлен язык для уровня формулировок, каждая из групп предложила свой язык, определив для формулировок новые структуры XML с использованием собственного словаря.

Например, технический комитет OASIS Reliable Exchange (WS-RX) для формулировок надежной политики обмена сообщениями применяет проект стандарта WS-ReliableMessaging Policy [6]. Для формулировок, связанных с безопасностью, комитет OASIS Secure Exchange (WS-SX) задействует проект стандарта WS-SecurityPolicy [7]. Он относится к домену, который охватывает стандарты, находящиеся в ведении двух технических комитетов OASIS — WS-SX и Web Services Security (WSS). Язык XACML, использующий функции ограничения, — очевидный выбор для формулировок политики авторизации, поскольку он уже является стандартом OASIS.

Политика, которая выражена на языке WS-Policy, охватывающем несколько доменов, может целиком включать в себя политику XACML в виде единой комплексной формулировки для домена авторизации. Разработчики могут также использовать функции ограничения XACML как обобщенный язык построения формулировок в любом домене. В списке рассылки OASIS, посвященном независимым от домена языкам формулировки политик (lists.OASIS-open.org/archives/dipal-discuss/), недавно обсуждался язык WS-PolicyConstraints. В нем функции ограничения XACML служат для построения формулировок политики со словарем из любого домена; он может также обслуживать автоматические переговоры о политике. Не ясно, однако, будет ли этот язык продвигаться в сторону стандартизации. Еще один вариант для уровня формулировок — язык XQuery, но он не поддерживает автоматические переговоры о политике.

Большинство групп стандартизации определили собственные словари как часть своих формулировок. XACML определяет несколько стандартных переменных, вроде current time («текущее время»), которые, вероятно, будут полезны во многих доменах. Однако словари авторизации почти всегда зависят от приложения или предприятия, поэтому вряд ли нуждаются в глобальной стандартизации.

Сложившаяся тенденция использования новых структур XML для каждого очередного типа формулировок препятствует достижению интероперабельности политик, удобству сопровождения и автоматизации переговоров. Универсальный язык функций ограничения, такой как WS-PolicyConstraints, может оказаться полезным, но даже стандартизованный язык построения формулировок не устраняет проблем большого числа опций. Если каждый сервис способен выбирать опции политики из растущего множества допустимых опций, то уменьшается вероятность того, что два произвольных сервиса будут иметь совместимые политики. Одно из решений таково: когда станут доступными основообразующие стандарты, организации Liberty Alliance (http://www.project%20liberty.org/) и Web Services Interoperability Organization (www.ws-i.org) смогут разработать профили, определяющие небольшое количество опций для отдельных доменов политики.

Сегодняшняя модель политики Web-сервисов не поддерживает, например, делегирование, переговоры об установке доверительных отношений и обязательства, связанные с выбором политики. Постоянно усложняющиеся Web-сервисы могут потребовать в будущем более сложных языков описания политики.

ЛИТЕРАТУРА

T. Moses ed. Extensible Access Control Markup Language (XACML), version 2.0, Organization for the Advancement of Structured Information Standards standard. — 1 Feb. 2005; www.OASIS-open.org/com-mittees/tc_home.php?wg_abbrev= xacml.
XQuery 1.0 and XPath 2.0 Functions and Operators, World Wide Web Consortium (W3C) candidate recommendation.— 3 Nov. 2005; www.w3.org/TR/xquery-operators/.
J. Schlimmer et al. Web Services Policy Framework (WS-Policy), joint specification by IBM, BEA Systems, Microsoft, SAP AG, Sonic Software and VeriSign. — 9 Mar. 2006; http://www.ibm.com/developer%20works/library/ws-polfram/.
A. Anderson. An Introduction to the Web Services Policy Language // Proc. 5th IEEE Int’l Workshop on Policies for Distributed Systems and Networks (Policy 04). — IEEE CS Press. — 2004; available at http://%20research.sun.com/projects/xacml/Policy2004.pdf.
C. Sharp et al. Web Services Policy Attachment (WS-PolicyAttachment), joint specification by BEA Systems, IBM, Microsoft, SAP AG and Sonic Software. — 9 Mar. 2006; www.ibm.com/developerworks/library/specification/ws-polatt/.
D. Davis et al. Web Services Reliable Messaging Policy Assertion (WS-RM Policy), Organization for the Advancement of Structured Information Standards, committee draft 03. — 14 Mar. 2006; www.OASIS-open.org/committees/tc_home.php?wg _abbrev=ws-rx.
C. Kaler and A. Nadalin. Web Services Security Policy Language (WS-Security Policy), version 1.1, joint specification by IBM, Microsoft, RSA Security and VeriSign. — July 2005; www.ibm.com/developerworks/library/specification/ws-secpol/.

Энн Андерсон (mailto:www.ibm.com/developerworks/library/specification/ws-secpol/) — инженер компании Sun Microsystems, член IEEE и ACM.

Таблица