ОБЗОРЫ

Окончание. Начало см. PC Week/RE, 2004, N27, с. 20; N 28, с. 19; N 29, с. 18; N 30, с. 20; N 31, с. 22; N 32, с. 31; N 33, с. 28; N 34, с. 50.

Если пользователь работает с разными ресурсами в корпоративной сети, то ему необходимо помнить пароль и логин для доступа к каждому из них. Однако этих данных может быть много, и их приходится записывать на бумагу, что повышает опасность попадания к нечистоплотным людям. Решение состоит в применении средств однократной аутентификации (Single Sign-On, SSO), которые хранят все нужные пароли в защищенном, дистанционно удаленном от пользователя хранилище. При подключении к разным информационным ресурсам пользователю достаточно аутентифицироваться лишь один раз, а далее система SSO автоматически предоставит каждому ресурсу требуемую для входа информацию. Эта технология активно используется в системах электронной коммерции и порталах.

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

Вместе SAML, Liberty и XACML закрывают почти все те же области Web-сервисной безопасности, что и стандарты GXA, разговор о которых шел в предыдущих частях обзора. Однако они отличаются большей открытостью процесса и не столь жестко защищены авторскими правами, как стандарты WS-*. Стоит также сказать, что область их применения не ограничивается Web-сервисами - они могут применяться в любой Интернет-подобной среде.

Security Assertion

Markup Language (SAML)

Статус: версия 1.1 утверждена как стандарт OASIS в сентябре 2003 г.; версия 2 - рабочий документ OASIS на последних фазах утверждения.

Авторы: Sun Microsystems, Netegrity, RSA Security при участии BEA Systems, Cisco Systems, Entrust, Hewlett-Packard, IBM, VeriSign и пр.

SAML описывает рамочную инфраструктуру для обмена любой информацией, касающейся безопасности, защиты данных в XML-сообщениях и реализации разных стилей SSO.

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

Рис. 1. Доменная архитектура SAML.

Заявления могут быть аутентификационными ("данный субъект был аутентифицирован в это время"), атрибутными (т.е. содержащими сведения о субъекте - "это пользователь из департамента сбыта") и авторизационными ("субъект допущен делать то-то"). Соответственно классифицируются и авторитетные инстанции. Вот только инстанции, производящие авторизацию, называются узлами принятия решений о соответствии запроса политике безопасности (policy decision points, PDP).

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

Привязки,

дополнения и профили

Главная спецификация SAML не рассматривает, как именно будут передаваться сформированные в ее рамках блоки XML-данных. Привязки к транспортному и сетевому слоям задаются в профилях SAML - дополнительных технических описаниях, показывающих, как применять SAML для решения конкретной задачи. Профили строятся на базе рассмотрения сценариев использования (use cases). Отделение привязок от основного стандарта способствует совместимости независимых программных продуктов.

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

Сравнение с GXA

Надо заметить, что SAML дает альтернативный WS-Security и WS-Trust набор средств безопасности. Безусловно, они опираются на единые исходные принципы и даже общие стандарты XML Encode и XML Signature. Многие вещи в этих двух группах стандартов также организованы аналогичным образом: в обеих применяется концепция использования утверждений, похожи многие структуры данных и протоколы. К примеру, в SAML, так же как и в WS-Trust, команды запросов на авторизацию и ответы на них помещаются в тело SOAP-сообщений.

Однако в деталях протоколы сильно различаются, в первую очередь синтаксисом форматов данных и запросов. Кроме того, в SAML заголовки SOAP-сообщений почти совсем не используются, в то время как в WS-Security они применяются весьма интенсивно. WS-Security напрямую запрещает использование конвертной подписи XML-Signature (enveloped signature), а SAML 1.1, наоборот, требует ее применения. SAML 1.1 отдает предпочтение подписи RSA с открытым ключом, а WS-Security совместим и с системами на базе секретного ключа. SAML не требует использования элементов для описания ключа цифровой подписи (да и вообще допускает утверждения безопасности, не подкрепленные цифровой подписью), а в WS-Security это один из главных элементов безопасности.

Далее, SAML отличается от спецификаций серии WS-* по привязке к транспортному слою: в WS-* - это всегда SOAP, причем сетевой слой вообще не оговаривается, но в SAML это не так. Иначе говоря, SAML в отличие от средств семейства WS-* ориентирован не только на Web-сервисы.

Наконец, версия SAML 1.1 менее детально описывала подходы к созданию систем с федеративной организацией служб безопасности, нежели WS-Trust. Разрыв устранялся лишь применением технологий Liberty Alliance. В версии 2.0 он ликвидирован, но она еще не утверждена окончательно.

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

Версии и расширения

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

Версия 2.0 стека стандартов SAML подверглась значительным изменениям. Появились протоколы однократного отключения от федеративной системы аутентификации (Single Logout Protocol), управления псевдонимами (Name Identifier Mapping Protocol и Name Identifier Management Protocol), сессиями, а также профили атрибутов, средства обеспечения представительства центров авторизации.

Liberty Project

Статус: версия 1.2.

Авторство: отраслевой консорциум из 150 участников Отраслевой консорциум Liberty был организован для того, чтобы предложить альтернативу SSO-технологии Passport корпорации Microsoft. Однако он не только достиг поставленной вначале цели, но и создал много новых технологий для обеспечения аутентификации в Интернете, управления метаданными об Интернет-объектах и безопасной передачи этих метаданных.

Рис. 2. Упрощенный SAML-сценарий однократной аутентификации с использованием HTTP-привязки и браузера

Рассмотреть семейство стандартов можно только в самых общих чертах - оно содержит почти 40 документов объемом по 40-60 страниц каждый. Авторы объединили их в три логические группы: Identity Federation Framework (ID-FF), Liberty Identity Web Services Framework (ID-WSF) и Identity Services Framework (ID-SIS).

ID-FF: архитектура

Основные документы ID-FF определяют протоколы для кросс-доменной аутентификации (фактически SSO), построения системы федеративного управления сущностями (identity) и управления сессиями. Другие части рассматривают вопросы построения безопасной реализации системы аутентификации, сохранения приватности, использования в беспроводных средах (WAP), обмен метаданными (политиками безопасности), расширения для управления контекстом аутентификации (т.е. дополнительными сведениями об инфраструктуре безопасности, необходимыми для авторизации) и пр.

Как легко увидеть, ID-FF аналогична по назначению WS-Trust и WS-Federation и частично SAML, но решает поставленные задачи для более общего случая. Важное свойство, обеспечившее популярность ID-FF, - бесплатность, хотя в прилагаемых XML-схемах указано, что использование некоторых элементов спецификаций может потребовать приобретения лицензий у правообладателей.

Решение, описываемое ID-FF, состоит из трех участников - главного клиента (инициатор, Principal), провайдера сущности (IdP) и провайдера сервиса. Основной задачей, решаемой средой, является подтверждение со стороны IdP идентичности инициатора при его обращении к услугам разных сервисов. Результат авторизации - утверждение аутентификации, которое клиент может передать провайдеру сервиса (ПС). Если ПС доверяет жетонам безопасности (ЖБ) данного IdP, то предоставит услуги клиенту. Такая форма взаимодействия IdP и ПС называется федеративной. В этом контексте термин федерирование (federate) лучше переводить как уравнивание значимости ЖБ, выданных разными IdP.

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

Число IdP может быть большим, и они могут быть объединены в "кольцо доверия", т.е. пользователь, идентифицированный одним IdP, принимается любым сервисом, аккредитованным в любом другом IdP. Отношения доверия устанавливаются внутри каждой пары IdP вручную. Подобная схема именуется в Liberty однократной регистрацией (SSO). Сервис, к которому обращается клиент, может перенаправить последнего к одному из участников кольца, пользуясь при этом исключительно средствами Liberty. Кроме того, IdP обязан хранить состояние сессии, начатой его клиентами. В принципе, предусмотрен даже механизм возобновления сохраненной сессии в случае повторной идентификации через другой сервер.

Очевидно, что "кольцо доверия" - схема с иной философией, нежели набор схем из WS-Trust и WS-Federation. Причина этого лежит в корнях обеих технологий - WS-* выросла из доменной структуры Windows и Unix/NIS, а первичной целью альянса Liberty было обеспечение пользователей браузера средствами однократной аутентификации на коммерческих Web-сайтах. Хотя ясно, что с помощью обоих семейств можно построить федеративную систему любой разумной топологии.

В отличие от базовой топологии набор протоколов ID-FF практически идентичен тому, что задает WS-Federation, - это протоколы однократной регистрации в федеративной среде, регистрации клиента под альтернативным скрытым именем, прекращения всех сеансов клиента, отображения имени*1. Помимо этого определяется отсутствующий в WS-Federation протокол уведомления участниками друг друга о прекращении ими федеративного обслуживания конкретного клиента.

_____

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

Рис. 3. Структура Liberty Project

Большинство протоколов расширяемы и позволяют передавать в них любые дополнительные данные. Все протоколы - рамочные, т.е. стандартизуют только "верхний слой" технологий аутентификации. Как и в случае с WS-Security, они задают XML-обертки для реальных криптографических технологий и аутентификационных средств. Более того, в базовой спецификации ID-FF определяются лишь абстрактные протоколы и форматы XML-данных без привязок к SOAP или какому-либо протоколу транспортного слоя. Привязки задаются в профилях.

ID-FF: Отношения с SAML

Liberty опирается на SAML, в терминологии которого IdP действует как Asserting Party и Authentication Authority, а провайдер сервиса - как Relying Party. Также активно используются определенные SAML правила применения цифровой подписи. Многие из протоколов Liberty перекочевали в виде аналогов в SAML 2.0. Заметим, что некоторые имеют аналоги и в семействе WS-*, где появились с опозданием.

Например, в профилях определена привязка протокола однократной аутентификации к SOAP/HTTP, почти полностью идентичная аналогичному протоколу SAML 2.0 (эти привязки рассматриваются для разных типов клиентов - от обычного браузера до полнофункционального Liberty-клиента). Вообще, Liberty при привязке к SOAP следует тем же правилам, что и SAML: сообщения пересылаются только в теле SOAP, не более одного запроса на сообщение, нельзя включать дополнительные данные в тело и пр. Как и в SAML, основной сетевой протокол здесь - HTTP.

ID-WSF и ID-SIS

С точки зрения Web-сервисов важным компонентом архитектуры Liberty является ID-WSF - рамочная архитектура для обнаружения и вызова сервисов аутентификации, акцентированная исключительно на SOAP. Она частично дублирует ID-FF, но прорабатывает такие вопросы, как безопасность канала связи между IdP и сервисом, корреляция сообщений SOAP, установление контекста сессии, размещение правил обработки в заголовке SOAP, алгоритмы обнаружения и использования сведений об аутентификационных требованиях сервиса, обмен метаданными между IdP и сервисом и пр. В пакете ID-WSF содержится более десятка документов, разъясняющих разные стороны инфраструктуры. Пакет же ID-SIS состоит из двух документов - описаний профилей клиента и "сотрудника компании". Ниже даны краткие описания главных документов.

ID-WSF SOAP Binding описывает основанную на SOAP рамочную инфраструктуру для взаимодействия клиентов с сервисами идентификации (identity service, IS). А именно: блоки заголовка SOAP, правила обработки, форматы запросов и ответов SOAP. Например, в заголовке SOAP могут присутствовать блоки, содержащие сведения для корреляции сообщений, идентификаторы ПС и афилированных сервисов, контекст обработки запроса, ограничения на время обработки запроса, контекст мандатов*1, директивы использования*2, сведения для переадресации на другую конечную точку и пр.

_____

*1 Данный контекст служит для передачи источнику запроса описания принятой у сервиса политики безопасности в случае отказа в обслуживании.

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

ID-WSF Security Mechanisms описывает подходы к обеспечению безопасности процессов обнаружения и использования IS. Он исходит из того, что все узлы на пути сообщения должны быть идентифицированы, а их действия запротоколированы в заголовках. Приведенные методы защиты данных включают аутентификацию и корреляцию запроса и ответа, защиту от атаки в виде повторения сообщений, защиту целостности, конфиденциальности и приватности (privacy), авторизацию доступа к ресурсам, авторизацию посредника и уменьшение ущерба от атак типа блокирования обслуживания. Все методы опираются на утверждения безопасности и XML-элементы других стандартов - WS-Security, SAML и пр.

ID-WSF Discovery Service определяет сервис, позволяющий разным службам обнаруживать зарегистрированные для данного клиента сервисы идентификации. Например, когда служба хочет узнать персональный профиль клиента, она получает WSDL-описание сервиса идентификации, задаваемого спецификацией Personal Profile Service. Кроме того, Discovery Service может функционировать как сервис ЖБ. Частичная альтернатива этой службе - UDDI-реестр.

Metadata - это отдельный набор схем и протоколов для обмена метаданными в режиме реального времени. В нем определен механизм публикации метаданных и их получения (например, из DNS). Рассматриваются три типа метаданных. Основные (entity) метаданные содержат используемые сущностями ключи, информацию о конечных точках SOAP, а также информацию, специфическую для провайдера сервиса или IS. Метаданные доверия сущностям - основа механизма принятия решений (в первую очередь связанных с бизнесом) на основе типовой доверительной информации. Третий класс составляют сведения о происхождении и проверке документа: цифровой подписи, примененной в протоколе HTTPS во время получения документа, DNS-подписей и подписей уровня документа.

SOAP Authentication Service предлагает универсальный рамочный механизм аутентификации участников SOAP-обмена, допускающий встраивание в него любых отраслевых механизмов. Инфраструктура предназначена для работы в среде SOAP с применением контекста Liberty ID-WSF и состоит из расширенного сервиса и протокола (по сравнению с ID-WSF Discovery Service) аутентификации, а также сервиса SSO. Последний опирается на профиль ID-FF SSO Protocol, но описывает и этап предварительного получения ЖБ у сервиса аутентификации.

ID-SIS Personal Profile Service определяет сервис персональной информации, т.е. сведений о самих клиентах, требующих доступа.

eXtensible Access

Control Markup Language (XACML)

Статус: стандарт OASIS, версия 2.0 утверждена в виде рабочего документа 25 июня 2004.

Авторы: GlueCode Software, Entrust, Sun Microsystems, BEA Systems, OpenNetwork.

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

Именно для этих целей создана группа спецификаций XACML. Ею определяются правила описания федеративно устроенных политик безопасности, а также процедуры обмена данными с узлами управления политиками. Если SAML аналогичен по назначению комбинации WS-Security и WS-Trust (и добавочных спецификаций), то XACML ближе к WS-SecurityConversation и WS-Policy. Как и WS-Policy, этот язык задает теги для описания индивидуальных проверок (правил) и алгоритмы комбинирования их в политику, применяемую для принятия конкретного решения относительно запроса клиента.

Помимо этого XACML формализует процедуры, по которым центр авторизации может комбинировать несколько разных политик в одну общую. В целом эти алгоритмы аналогичны тем, что применяет WS-Policy, но имеют другой синтаксис - методы представления функций почерпнуты из MathML, XQuery 1.0 и XPath 2.0 Functions and Operators. Особенностью XACML является то, что правило - это одновременно и самостоятельная, и зависимая сущность: оно может быть использовано только внутри политики, но при этом правило можно многократно включать в разные политики.

Существенное отличие от WS-Policy состоит и в том, что XACML допускает взаимодействие с одной конечной точкой информационного ресурса разных по возможностям клиентов. Для их различения в рамках политик применяется атрибут под названием категория субъекта (subject-category), имеющий набор стандартных значений. Кроме того, XACML поддерживает концепцию ролей клиента (т.е. ожидаемого поведения), на основе которых можно принимать решение об авторизации.

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

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

Рис. 4. Архитектура XACML.

XACML разделяет логически точки применения политик к потокам данных (Police enforcement point, PEP), хранения политик (Policy administration Point, PAP) и принятия решений о соответствии входных данных политикам (policy decision point, PDP). PEP могут существовать в разных формах (брандмауэры, часть Web-сервера или сервера почты и т. п.), и от них не ожидается соответствия XACML. PDP же осуществляют проверки, но не активные действия, такие, как блокирование доступа клиента к ресурсу. Связь между ними осуществляется через сервис управления контекстом. Таким образом, получается, что один PDP (и одна политика) может обслуживать несколько PEP. Контекст же задает каноническую форму запросов и ответов, принимаемых XACML PDP, - для ее описания имеется соответствующая XML-схема. Если родной формат запросов конкретного PEP основан на XML (например, используется SAML), то преобразование в сервисе контекстов может быть произведено через листы стилей XSLT, если нет, то применяется программирование.

В ряд спецификаций группы XACML приводятся сценарии использования для схем с делегированием функций PAP, PEP и PDP, наработки для построения иерархических систем управления политиками, профили для построения систем с ролевым доступом и пр. Все эти спецификации могут быть бесплатно реализованы в продуктах.

В заключение заметим, что вопросы безопасного соединения, установления доверительных отношений между доменами и т. п. XACML не рассматриваются, хотя в итоговой части спецификации подробно обсуждаются методы защиты PDP от возможных атак. Один из профилей описывает также привязку к SAML 2.0, а именно: правила для применения стандартных SAML-запросов с целью получения атрибутов из центра выдачи атрибутов; формирования утверждений, содержащих авторизованные атрибуты; использования расширенных SAML-тегами XACML-запросов для получения политик из точек PAP; применения расширенных тегами XACML утверждений о политиках, выдаваемых по SAML-запросам; расширения XACML-тегами авторизационных SAML-запросов.

***

На этом мы заканчиваем рассмотрение основных технологий, определяющих сегодняшнее лицо мира Web-сервисов. Число подходов настолько велико и многие спецификации настолько сложны, что проблемы со взаимодействием разных программных продуктов можно считать гарантированными. Отраслевые попытки унификации, наподобие тех, что предпринимает консорциум WS-I, касаются только базового слоя этой архитектуры, но уже на более высоком уровне задач, как мы видели, ведется ожесточенная борьба без явного лидера. Хотя и здесь наблюдаются попытки конвергенции, груз преодоления несовместимости Web-сервисных систем ложится на их пользователя. А это - серьезное отступление от обещания идеологов Web-сервисной отрасли сделать интероперабельным все и вся.

С автором можно связаться по адресу: vlad_borkus@pcweek.ru.