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

ОБЗОРЫ

Продолжение. Начало см. PC Week/RE, 2004, N 27, с. 20; N 28, с. 19; N 29, с. 18; N 30, с. 20; N 31, с. 22; N 32, с. 31.

     В предыдущей части обзора было рассказано, как в рамках стандартов Global XML Web Services Architecture (GXA) обеспечивается безопасность обмена сообщениями и устанавливаются доверительные отношения между участниками. Однако данные для установления подобного доверия нужно как-то получать, описывать и хранить. Технологии, о которых пойдет речь ниже, решают эту задачу. Кроме того, они позволяют создать деревья доменов, находящихся в доверительных отношениях, и обеспечить такую востребованную функцию, как однократная аутентификация для доступа ко множественным ресурсам.     

WS-Policy и Web Services Policy Assertions Language (WS-PolicyAssertions)

     Статус: черновик, версия 1.01, 2 June 2003.

Авторы: BEA Systems, IBM, Microsoft, SAP AG.

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

Перечисляется два взаимоисключающих варианта, когда сервис может быть использован,

 - для протоколов Kerberos и X.509. Для каждого из них предъявляются еще и требования

к алгоритмам шифрования и цифровой подписи

WS-Policy определяет XML-грамматику для описания возможностей и характеристик WS-системы, а также требований, предъявляемых ею к клиентам. Наборы подобных описаний, или утверждений (assertions), сводятся в документы, называемые политиками. Утверждения в WS-Policy формируются из выражений (expressions) и могут быть как простыми декларациями наличия у сервиса каких-либо свойств, так и сложными параметризованными проверками входящих данных на соответствие каким-то критериям. В типичных WS-приложениях политики задают, как правило, условия, при которых сервис готов к обслуживанию клиента. Скажем, они контролируют свойства схемы аутентификации или транспортного протокола. Клиент может запросить эту информацию и использовать ее, чтобы решить, обращаться к сервису или нет.

 Рис. 2. Пример ссылки на политику безопасности,

определяемой WSPolicyAttachement

     Грамматика WS-Policy состоит из трех компонентов: контейнерного элемента <wsp:Policy>, операторов группирования нескольких проверок (они и называются операторами определения политики) и набора общих атрибутов, используемых для обозначения способа применения проверки. В качестве примеров используемых операторов можно привести следующие: <wsp:ExactlyOne>, обозначающий требование сделать единственный выбор между перечисленными в нем блоками-условиями; <wsp:All>, показывающий, что все включенные в него элементы-условия должны быть выполнены; <wsp:OneOrMore>, который требует, чтобы было удовлетворено условие как минимум в одном из его дочерних элементов. Допускается также оператор <wsp:Policy>, имеющий семантику, аналогичную <wsp:All>, и позволяющий определить внутри данной политики вложенную политику.

 Рис. 3. Пример приложения, определяющего привязку к политике для развернутой

"конечной точки" (задается при помощи WS-Addressing), для которой есть WSDL-описание

     Внутри операторов находятся утверждения, соответствующие проверкам. Грамматика этих утверждений - дело расширений. В частности, для разметки требований безопасности могут использоваться теги, определенные в WS-Security. Эти теги дополняются атрибутом wsp:Usage, указывающим на тип использования утверждения. Он может быть определен и для всей политики в целом - через тег <Assertion>. Определено пять значений атрибута: Required (правило обязано выполняться), Optional (желательное, но необязательное правило), Rejected (при выполнении условия входное сообщение отвергается), Observed (проверка будет примерена ко всем запросам, и клиент будет информирован о ее результатах), Ignored (условие будет проверено, но никаких действий предпринято не будет).

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

Сочетание операторов группирования и проверок позволяет создавать сложные проверки из простых. Так, используя приведенные выше операторы, можно организовать проверочную таблицу - элементы ее строк логически объединяются операцией "И", а сами строки объединяются операцией "ИЛИ". Атрибуты же задают либо отрицание результатов почтовой проверки, либо их обязательное соблюдение, либо игнорирование и т.д.

Помимо описанных возможностей есть еще средство задать имя для политики (в том числе вложенной в другую политику) - через атрибут wsu:Id в теге <Policy>. Это поле добавляется к URI-адресу файла политики для формирования нового, уникального URI. Если адрес политики http://aaa.com/policies , а wsu:Id вложенной политики равно "P1", то ссылаться на нее можно по адресу: http://aaa.com/policies#P1. Политику, получившую такой составной URI, можно впоследствии использовать как "элементарную" проверку в других политиках при помощи оператора <wsp:PolicyReference>. Таким образом можно создавать иерархию политик.

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

Примечание. Web Services Policy Assertions Language (WS-PolicyAssertions) - вспомогательная спецификация, предоставляющая некоторый набор тегов для описания утверждений, часто используемых в Web-сервисных приложениях. Таковыми являются описание кодировки текста, альтернативные языки, используемые в тексте сообщения, версия какой-либо спецификации, поддерживаемой сервисом, соответствие сообщения некоему предикату (предварительное условие) и пр. Также дается список базирующихся на XPath функций выборки данных из сообщений - например, wsp:GetBody (получение тела из конверта сообщения), wsp:IsInBody (проверка, находится ли нужный узел XML-сообщения в теле этого сообщения), wsp:IsInHeader (проверка нахождения узла в заголовке) и др.

Web Services Policy Attachment (WS-PolicyAttachment)

Статус: авторская спецификация, версия 1.01, июнь 2003.

Авторы: Microsoft, IBM, BEA Systems, SAP.

Как правило, политики не хранятся сами по себе - они должны быть приспособлены к существующей инфраструктуре. WS-PolicyAttachment определяет общий механизм для привязки описаний политик к описаниям сервисов, а также три его специфических варианта: привязки на уровне WSDL-типов, привязки к элементам каталогов UDDI и привязки к конкретным реализациям сервисов через WSDL-описания.

Подключение политик к ресурсам

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

Для реализации первого механизма WS-PolicyAttachment определяет два ссылочных атрибута, которые можно включать в текст произвольного XML-элемента: wsp:PolicyURIs, содержащий список из одного или более URI-адресов политик, и wsp:PolicyRefs, содержащий аналогичный список, но из имен QNames. В случае, когда указано более одного имени QName или URI, формируется некоторая объединенная политика по правилам, принятым в конкретной реализации.

Второй обобщенный механизм фактически задает правило составления связи между двумя независимыми сущностями - политикой и ресурсом. Эта связь задается XML-документом, имеющим внутри элемент <wsp:PolicyAttachment>. Данный элемент состоит из трех компонентов, описывающих границу применения (scope) политики*1 (т.е. указатели на ресурсы, к которым она применима), утверждения политики (или ссылки на файлы политик), используемые в рамках этих границ, и произвольную дополнительную информацию для обеспечения безопасности.

_____

*1 Границы применения приложения определяются элементом и комбинацией любых других XML-тегов внутри него, например URI, заданным командами WS-Addressing. Если в перечисляется несколько ресурсов, то политика будет применена ко всем ним.

 Рис. 4. Пример запроса к системе на получение политики относительно сервиса

     в WS-MetadataExchange и ее ответа. Адрес сервиса определен через WS-Addresing

Главным из конкретных механизмов, описанных в WS-PolicyAttachment, является привязка к WSDL. Команды привязки включаются в WSDL-описание. Так как стандарт WSDL 1.1 не допускает каких-либо дополнительных XML-элементов внутри описаний типов портов (portType) и сообщений, то WS-PolicyAttachment предлагает расширять эти теги через атрибуты wsp:PolicyURIs и wsp: PolicyRefs. Для того чтобы пользователь такого расширенного описания сервиса понимал, что его структура отличается от той, что диктуется "чистым" стандартом, спецификация предлагает включить элемент <wsp:UsingPolicy/> в секции <wsdl:definitions>, содержащие описания portType и сообщений.

Хранение политик

Реестры UDDI становятся универсальными хранилищами метаданных, и естественно, что WS-PolicyAttachment дает механизмы привязки политик к этим хранилищам. Основа для этого уже прописана в спецификации UDDI: модели tModels предлагают обобщенный механизм для ассоциирования произвольных данных с любыми сущностями (в том числе Web-сервисами), описания которых есть в UDDI-реестре. WS-PolicyAttachment лишь указывает конкретные пути реализации этой возможности.

Рис. 5. Базовый механизм доверительных доменов WS-Federation. Для доступа к ресурсу

клиенту требуется предварительно получить жетон безопасности (1) у IdP в своем домене.

В силу доверия между доменами этот жетон принимается STS в домене ресурса (2).

На его базе STS генерирует для клиента новый жетон, который принимается ресурсом (3)

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

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

Web Services Metadata Exchange (WSMetadataExchange) Статус: авторская спецификация, март 2004.

Авторы: Microsoft, IBM, SAP, BEA Systems.

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

- политики WS-Policy, связанные с конечной точкой-получателем или с заданным в запросе пространством имен;

- WSDL-описания, также связанные с конечной точкой-получателем или с заданным в запросе пространством;

- XML-схему для заданного пространства имен.

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

Web Services Federation Language (WS-Federation) Статус: версия 1.0, июль 2003.

Авторы: IBM, Microsoft, BEA Systems, RSA Security, Verisign.

WS-Federation описывает сценарии использования систем, в которых аутентификация производится разными центрами, состоящими в доверительных отношениях, или, иначе говоря, основывается на федеративных принципах. Текущая версия спецификации рассматривает три важных применения стандартов WS-Trust, WS-Security и WS-Policy - обеспечение однократной аутентификации (Single Sign On, SSO), федеративное хранение метаданных (атрибутов пользователей, политик и пр.) и отключение от обслуживания в федеративной среде (Sign-out).

Аутентификация в федеративной среде

WS-Trust и WS-Policy диктуют, что ресурс должен проверить набор утверждений, закодированных в жетоне безопасности поступающего запроса, на соответствие принятой у него политики. Ресурс может потребовать от клиента дополнительных сведений (в виде ЖБ) для подтверждения этих данных, для чего клиенту придется сделать дополнительные запросы к службе аутентификации и подтверждения идентичности (Identity Providers, IdP), в которой имеется запись о нем.

WS-Federation рассматривает возможные последовательности действий (протоколы обмена сообщениями) в таких сценариях, в частности для сред с несколькими аутентификационными центрами. Между такими центрами могут существовать самые разные формы доверительных отношений, не обязательно "один к одному". Например, механизм неявного доверия предполагает наличие сервиса жетонов безопасности (СЖБ, Security Token Service), которому все доверяют и который может своим авторитетом подтвердить право СЖБ выдавать жетоны безопасности, пригодные для аутентификации в СЖБ ресурса. Кроме того, предусматривается механизм посредников, когда один сервис получает доступ к ресурсу от имени другого сервиса. Есть и возможность сделать доверительные отношения между доменами транзитивными: если A доверяет B и C доверяет В, то A будет доверять жетонам, выданным C.

Эти средства делают возможным стандартизовать построение важного частного случая систем аутентификации - систем с однократной аутентификацией клиента.

Атрибуты и псевдонимы

Второй важный набор сценариев, описываемый WS-Federation, затрагивает использование сервиса атрибутов и псевдонимов (САП, Attribute/Pseudonym services). САП не только производит аутентификацию клиента, но и способен расширять ЖБ некоторой дополнительной информацией о клиенте. В спецификации подробно описывается привязка к UDDI как к репозиторию атрибутов - для хранения атрибутов вводится специальная модель tModel.

Что касается псевдонимов, то они применяются для ограничения выдаваемой информации о клиенте (principal) и маскировки (отображения, mapping) его идентичности; в этом случае при доступе к разным ресурсам в жетонах безопасности будут фигурировать разные имена для клиента, что затруднит отслеживание его перемещений между узлами. Согласно WS-Federation, псевдонимы получаются из сервиса псевдонимов командой , а ее поле указывает, к какому домену этот псевдоним нужно применять. Другие поля задают время жизни псевдонима, жетон доказательства обладания секретом и пр. Определяются и команды управления псевдонимами в их хранилище*1.

_____

*1 Соответственно <wsse:SetPseudonym> и <wsse:DeletePseudonym>.

 Рис. 6. Применение псевдонимов в WS-Trust. Клиент регистрируется в домене

Business456.com (1) и получает жетон (2), содержащий его первый псевдоним для доступа

 к этому домену. Используя этот жетон, он обращается к ресурсу в домене Fabrikam123.com (3),

находящемуся в доверительных отношениях с Business456.com. Ресурс запрашивает у своего сервиса

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

Для обнаружения клиентом разных сервисов псевдонимов и атрибутов применяется механизм WS-Policy/WS-MetadataExchange. Пакет WS-Federation несколько расширяет его, в частности показывает, как сервис в своей политике может указать место получения нужного ЖБ с псевдонимом*1.

_____

*1 Для этого структуры WS-PolicyAssertions расширяются новым утверждением <wsse:RelatedService>.

Наконец, WS-Federation описывает несколько схем отключения от обслуживания в федеративной среде (federated sign-out). Задачей такого процесса является очистка кэшированных данных и ЖБ, которые могут возникнуть в ходе процесса распределенной аутентификации. Спецификация вводит новые SOAP-команды, применяемые при осуществлении подобных действий*1, а совместимые политики при этом могут дополняться новыми конструкциями вроде <wsse:AutoSingOutMessages>, <wsse:RequestSSOMessagesEndpoint>.

_____

*1 <wsse:SingOut>, <RequestSSOMessages>, <CancelSSOMessages>.

Примечание. В пакете WS-federation помимо основной имеются еще и две дополнительные спецификации - WS-Federation: Active Requestor Profile и WS-Federation: Passive Requestor Profile. В них приводятся UML-диаграммы последовательности действий, затрагивающие специфику применения WS-Federation к активным и пассивным клиентам. Активные клиенты - это приложения, способные выдавать и получать SOAP-сообщения, описанные в WS-Security и WS-Trust. Пассивный клиент - это HTTP-браузер или приложение, обеспечивающее широкую поддержку HTTP/1.1. Протоколы аутентификации в данных профилях жестко привязываются к HTTP как транспортному слою - используются операции HTTP/ GET, HTTP/POST и протокол перенаправления запроса, а также куки-файлы. Кроме того, спецификации детально рассматривают вопросы применения жетонов безопасности, формируемых в рамках разных стандартов (Kerberos, X.509), в том числе конкурирующих - вроде SAML.