Федеративное управление удостоверениями

Несмотря на возрастные, психологические и внешние изменения личности, ее характеристики в основном постоянны — Ева и Драммонд всегда останутся Евой и Драммондом. Но это не относится к цифровому удостоверению. В данный момент адрес eve@xmlgrrl.com  связан с Евой, но в будущем, возможно, будет связан с другим лицом или вообще исчезнет. Это лишь одна из проблем, возникающих с цифровыми удостоверениями.

Федеративное управление удостоверениями — набор технологий и процессов, посредством которых компьютерные системы динамически распространяют сведения об удостоверениях и делегируют соответствующие задачи по доменам безопасности. Федеративное удостоверение — средство, с помощью которого Web-приложения обеспечивают однократный вход между доменами (Single-Sign On, SSO); в результате пользователи могут пройти проверку подлинности один раз и получить доступ к защищенным ресурсам и сайтам в других доменах.

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

В статье описана модель федеративных удостоверений и рассмотрены риски безопасности и конфиденциальности, а также архитектурные проблемы. Кроме того, представлены три широко распространенных протокола удостоверений для реализации модели: язык SAML [1], спецификация OpenID [2, 3] и спецификация InfoCard, которая составляет основу компонента Microsoft Windows CardSpace [4].

Управление удостоверениями и единая процедура входа

Цифровые удостоверения имеются у многих объектов (от оборудования с радиочастотными маяками до программных продуктов и компаний), но самые интересные задачи, которые необходимо решить как в контексте предприятия, так и в открытой Сети, связаны с удостоверениями для людей.

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

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

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

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

Обзор: модель федеративных удостоверений

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

• Пользователь — лицо, которому назначается определенное удостоверение для взаимодействия с оперативным сетевым приложением.
• Агент пользователя — браузер или другое приложение, выполняемое на любом оборудовании, от ПК до мобильного телефона или медицинского устройства. Оперативные взаимодействия пользователя всегда проходят через агент, который пассивно пропускает поток идентификационной информации или активно управляет им.
• Сайт поставщика услуг (SP) — Web-приложение (например, приложение подготовки отчетов о затратах или открытое сообщество), делегирующее проверку подлинности третьей стороне, которая также может переслать поставщику услуг некоторые атрибуты пользователя. Поскольку поставщик услуг использует внешнюю информацию, его часто называют «проверяющей стороной» (relying party, RP).
• Поставщик удостоверений (identity provider, IdP, иногда используется термин «провайдер идентификации») — Web-сайт, на котором регистрируются пользователи и иногда хранятся атрибуты, представляющие общий интерес для разных поставщиков услуг.

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

Архитектурное отделение источника информации об удостоверении от ее использования выгодно всем.

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

Слабая связь задач идентификации становится причиной ряда проблем, относящихся к безопасности, конфиденциальности и архитектуре.

Вопросы безопасности

Как и любой аутсорсинг, федеративные удостоверения могут обеспечить лучшие услуги по более низкой цене, но несут с собой новые риски. Во-первых, федеративные удостоверения пересекают домены безопасности. В идеальном случае все участники должны защитить свои каналы связи от атак с повторной передачей пакетов, атак «злоумышленник в середине», захвата сеанса и других угроз, которые могут привести к злоупотреблениям информацией пользователя или Web-ресурсами. В контексте HTTP архитекторы безопасности считают базовым уровнем Secure Sockets Layer/Transport Layer Security (SSL/TLS) со взаимной проверкой подлинности. Тем не менее при развертывании программ этот шаг часто пропускают, забывают или реализуют лишь частично.

Проверка подлинности пользователя — еще одно слабое звено в цепи Web-идентификации. Сегодня большинство сайтов используют пары «имя пользователя — пароль», так как этот метод представляет наименьшую начальную нагрузку для пользователей и администраторов сайта.

Для поставщиков услуг федеративные удостоверения связаны с меньшими затратами, чем реализация высококачественной инфраструктуры проверки подлинности, так как задача проверки подлинности возлагается на поставщика удостоверений. Однако единый вход на основе IdP может значительно усугубить последствия кражи пароля, так как расширяется область злонамеренных действий. Большинство протоколов единого входа обеспечивают способы снижения этой опасности. Например, можно ограничить минутой или меньше время существования маркера безопасности, пересылаемого поставщиком удостоверения поставщику услуг; некоторые протоколы также обеспечивают единый выход (Single LogOut, SLO) для почти мгновенного выхода из всех сайтов с единым входом.

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

Вопросы конфиденциальности

Обмен информацией, которую можно связать с конкретными лицами, — важнейшая задача управления конфиденциальностью, защиты данных и достижения соответствия законодательным актам, однако при федеративной идентификации обмен такой информацией часто является ключевой целью. Например, в процедуре единого входа сайту поставщика услуг может стать известным идентификатор GUID (user’s globall unique digital identifier), даже если не обязательно знать личность пользователя. С учетом этого необходимо проанализировать степень конфиденциальности и по минимуму раскрывать сведения на базовом уровне, то есть на уровне идентификаторов, служащих метками цифровой идентификации. Федеративные системы идентификации часто управляют многими типами идентификаторов, назначенных различными поставщиками удостоверений в различных контекстах. Эти идентификаторы могут быть:

• абсолютными (контекстно-независимыми и ненаправленными) или относительными (контекстно-зависимыми и направленными);
• одноэлементными уникальными значениями, иерархическими сегментами или многоэлементными объединенными ключами;
• необработанными, хэшированными или шифрованными;
• анонимными, псевдонимами или полностью открывающими реальную личность пользователя.

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

В реальном мире мы предъявляем идентификационные документы различным третьим лицам без ведома организации, выдавшей документ. Например, Алиса может показать водительские права бармену, чтобы доказать, что она достигла возраста, когда разрешено покупать алкоголь. Чтобы добиться аналогичной «развязки», федеративные протоколы идентификации должны применять специальные потоки данных и тщательное шифрование для скрытия взаимоотношения пользователя с поставщиками услуг от поставщика удостоверения [5].

Вопросы архитектуры

Слабые связи федеративных удостоверений ведут к интересным задачам проектирования.

Обнаружение поставщика удостоверений. Чтобы обеспечить инициируемый поставщиком удостоверений единый вход в стиле портала, администраторы могут настроить IdP на обращение к тем сайтам поставщиков услуг, которые хочет посетить Алиса. Но если единый вход инициирует поставщик услуг, то возникает проблема с обнаружением поставщика удостоверений. Каким образом поставщик услуг узнает, куда отправлять запрос проверки подлинности, когда Алиса хочет получить доступ к cth, предоставляемой по удостоверению? У этой проблемы «откуда вы?» есть несколько возможных решений.

Если поставщик услуг состоит в заранее установленном партнерстве с IdP («круг доверия», который часто охватывает деловые контракты и соглашения о юридической ответственности), можно статически задать местонахождение поставщика удостоверений. Если поставщик услуг должен выбрать одного из нескольких поставщиков удостоверений (то есть связи с IdP не заданы, в круг доверия входят несколько IdP или поставщик услуг входит в несколько кругов доверия), то Алисе придется указать местонахождение своего поставщика удостоверений. Этот сценарий известен как упрощенный вход. Другой вариант — предоставить Алисе пользовательский агент с достаточным интеллектом, чтобы знать ответ.

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

Наиболее распространенные федеративные идентификаторы — это идентификаторы сетей данных, такие как IP-адреса и DNS. Web-стандарты URI и IRI (Internationalized Resource Identifier — «международный идентификатор ресурсов») позволяют создателям Web-контента объединять эти идентификаторы в иерархические глобальные идентификаторы. Новым добавлением к этим стандартам стал XRI (Extensible Resource Identifier — «расширяемый идентификатор ресурсов»), спроектированный специально для цифровых удостоверений [6]. XRI обеспечивает уровень абстракции для IP-адресов. Например, можно преобразовать личный XRI, такой как drummond.reed i-name, в несколько URI-идентификаторов, которые представляют Драммонда в различных контекстах, в том числе в блоге, Skype ID и т.д.

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

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

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

Протоколы федеративных удостоверений

Сегодня широкое распространение получили три протокола для реализации различных аспектов федеративных удостоверений: SAML (Security Assertion Markup Language), OpenID и спецификация Identity Selector Interoperability Profile (часто именуемая как InfoCard), служащая основой для компонента Windows Cardspace. Из них SAML — наиболее зрелая и всеобъемлющая технология, варианты которой были стандартизованы в 2002-м и 2005 годах. OpenID появился в 2005 году, сейчас он представлен вторым поколением и продолжает активно развиваться. Протокол Cardspace появился позже, и его поддерживает компания Microsoft. На рис. 1 представлены общие черты и различия протоколов.

Стандарт SAML

SAML — стандарт OASIS и ITU (ITU-T X.1141), который обеспечивает XML-инфраструктуру для обмена информацией о безопасности и удостоверениях через границы доменов. SAML — нечто вроде универсального раствора удостоверений, а его архитектура удовлетворяет различным нуждам, в том числе поддерживает неодушевленных держателей удостоверений. Его структура определяется строгими требованиями к доверию, транзакциям высокой ценности и конфиденциальности. Несмотря на гибкость инфраструктуры и использование некоторых его компонентов другими технологиями (в том числе CardSpace и различными расширениями OpenID), SAML обеспечивает собственные решения для типовых задач.

Как показано на рис. 2, ядро SAML состоит из «утверждений» (assertion), то есть XML-пакетов, составленных из идентификатора держателя удостоверения, состояния проверки подлинности и атрибутов. Утверждения и сообщения протокола можно подписывать, шифровать и объединять в профили.

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

SAML стыкуется со стандартом Identity Web Services Framework (ID-WSF) организации Liberty Alliance, который охватывает задачи для автономных пользователей и Web-служб на основе соединений [7]. В состав ID-WSF входит настраиваемая служба взаимодействия. Например, Алиса может попросить своего биржевого агента отправлять ей текстовые сообщения, когда она не подключена к сети, но должна одобрить биржевые сделки, соответствующие ранее сделанным ею заявкам на покупку.

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

InCommon Federation иллюстрирует другой стиль обнаружения поставщика удостоверений. Членами федерации являются университеты и другие учреждения, и все они служат поставщиками удостоверений друг для друга. InCommon использует Shibboleth — протокол на основе SAML, чтобы помочь студентам, преподавателям и сотрудникам совместно обращаться к ценным сетевым ресурсам. Например, Корнеллский университет в роли поставщика удостоверений может предоставить своим студентам и преподавателям доступ к защищенным ресурсам Стэнфордского университета, который выполняет роль поставщика услуг, и наоборот. Когда Алиса, студентка Корнеллского университета, посещает Web-сайт Стэнфорда, протокол Shibboleth позволяет ей выбрать Корнелл из раскрывающегося списка и пройти проверку подлинности.

OpenID

SAML отличается широким охватом, а OpenID первоначально проектировался Брэдом Фитцпатриком для использования в сообществе LiveJournal в качестве облегченного, децентрализованного способа проверки подлинности комментаторов и борьбы со спамом в блогах.

OpenID функционирует как закрытый цикл проверки подлинности: когда Алиса оставляет комментарий в блоге Боба, она предоставляет URL-адрес собственного блога, который используется блогом Боба для перенаправления на блог Алисы — или, в соответствии с инструкциями ее блога, на указанного ею поставщика удостоверений — с запросом проверки подлинности. Как показано на рис. 3, такое взаимодействие обеспечивает упрощенный вход, позволяя пользователю зарегистрироваться с использованием идентификатора OpenID (собственно URL-адреса) на любом сайте, совместимом с OpenID. Поскольку пользователи могут выбирать и даже размещать собственных поставщиков OpenID, этот стандарт иллюстрирует важный подход к философии удостоверений, ориентированных на пользователя. Сейчас Web располагает экосистемой OpenID, основанной главным образом на открытых реализациях; многие такие сайты бесплатно предлагают удостоверения OpenID пользователям, и несколько тысяч сайтов принимают их.

Стандарт OpenID быстро развивается. В первой версии допускались только URL-идентификаторы, но впоследствии появилась поддержка идентификаторов XRI и их формата Extensible Resource Descriptor Sequence [8], что позволило усовершенствовать способы обнаружения поставщиков удостоверений и их возможностей. В новых версиях OpenID стороны процесса федеративной идентификации могут обмениваться основными атрибутами пользователей. В OpenID пока не решены более сложные задачи, такие как управление федеративными удостоверениями и единый выход.

При использовании OpenID обнаружение происходит, когда пользователи предоставляют универсально разрешаемые идентификаторы поставщику услуг. В результате поставщики удостоверений и услуг, которые никогда не встречались, могут успешно общаться. Такой тип масштабируемости сознательно заимствован из Web. Это может вызвать проблемы конфиденциальности: как архитектура, в которой предусмотрен широкий обмен пользовательской информацией, OpenID позволяет и даже поощряет согласование деятельности пользователей между различными поставщиками услуг. Однако спецификация OpenID Authentication версии 2.0, выпущенная в декабре 2007 года, также поддерживает вход с использованием псевдонима, то есть Алиса может представить идентификатор своего поставщика удостоверений вместо собственного. OpenID также позволяет поставщику удостоверений видеть поставщиков услуг, посещаемых Алисой. Единственный способ не раскрывать этой информации постороннему IdP — обзавестись собственным поставщиком удостоверений OpenID.

Модель обнаружения поставщиков удостоверений OpenID также не позволяет выполнить истинно единый вход, в котором поставщик услуг может напрямую обратиться на сайт IdP, не требуя, чтобы пользователь указал его местонахождение. (Многие экземпляры SAML обеспечивают истинно единый вход, но SAML можно использовать и аналогично OpenID, позволяя пользователям дать поставщику услуг разрешаемый идентификатор, указывающий местонахождение IdP [9].)

Протокол InfoCard и Windows CardSpace

Windows CardSpace — новый компонент Microsoft .Net, который обеспечивает пользователям унифицированный способ ввода цифрового удостоверения с применением специализированного пользовательского агента. Компания Microsoft документировала протокол, реализованный компонентом CardSpace в спецификации InfoCard. Центральная процедура CardSpace — сбор данных пользователей, именуемых «информационными картами» (information card) и представленных в программном интерфейсе в стиле бумажника, называемого «селектором удостоверений» (identity selector). Каждая карта представляет различное удостоверение, и, когда поставщик услуг запрашивает учетные данные, пользователь выбирает удостоверение из селектора.

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

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

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

Развертывание любой специальной клиентской технологии сопряжено с затратами, но позволяет найти более элегантные решения таких задач, как обнаружение поставщика удостоверений. Клиентская технология — центральный элемент расширенного профиля клиента SAML; похожее решение применяется в спецификациях ID-WSF Advanced Client. В модели InfoCard проблема решается путем отмены соединения поставщика услуг с поставщиком удостоверений: при использовании карт с самоподтверждением клиентское устройство может быть поставщиком удостоверений; при использовании управляемых карт IdP хранит адреса в карте для собственного использования селектора удостоверений.

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

Сейчас протокол InfoCard совместим только с протоколами WS-* на основе WS-Trust [10]. Однако в рамках открытого проекта Higgins Project (www.eclipse.org/higgins ) организации Eclipse Foundation идет работа над схожим с Apache подходом к идентификации, цель которого — обеспечить доступность модели информационных карт и архитектуры модульных API-интерфейсов, совместимых со многими протоколами.

Проблемы взаимодействия

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

• SAML и OpenID обеспечивают упрощенный вход, но по-разному;
• InfoCard и SAML обеспечивают решения на основе интеллектуальных клиентов, но оптимизируют их для разных целей;
• OpenID и InfoCard предоставляют идентификацию, ориентированную на пользователя, но под одним термином понимаются различные и подчас несовместимые цели.

Тем не менее по мере роста популярности эти технологии часто используются совместно: проверка подлинности поставщиком удостоверений SAML или OpenID с использованием информационной карты, или применение OpenID вместо SAML в качестве первого шага к запуску Web-сервиса с удостоверениями Liberty.

Первый шаг к решению проблем взаимодействия — понять степень различия между технологиями. В качестве примера Джефф Хьюз дает сравнение OpenID и SAML [11]. В отрасли также начинаются попытки координировать взаимодействие между технологиями, чтобы унифицировать обработку удостоверений в разных сетях, подобно тому как в сетях TCP/IP добивались единого распространения IP-пакетов. Например, в рамках проекта Concordia (www.projectconcordia.org ) ведется исследование проблем, возникающих при развертывании нескольких протоколов, и разрабатываются сценарии на основе комбинированных технологий, а рабочая группа Open Source Identity System (osis.idcommons.net) организации Identity Commons помогает тестировать взаимную совместимость открытых проектов управления удостоверениями, таких как Higgins, Bandit (www.bandit-project.org ) и OpenXRI (www.openxri.org ).

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

Попытки разрешить эти конфликты предприняты в рамках двух проектов. Цель проекта Sasso лаборатории NTT Labs — позволить пользователям надежно проходить проверку подлинности в регулярном сеансе единого входа на основе браузера с применением обычных SIM-карт мобильного телефона по протоколам SAML [12]. Наряду с устранением компромисса «безопасность/развертывание» и «удобство/специальный протокол», подход Sasso обеспечивает такие ориентированные на пользователя возможности, как сбор сведений о согласии в реальном времени и самостоятельно размещаемые удостоверения.

В рамках другого проекта Identity Commons организовала рабочую группу Identity Rights Agreements (wiki.idcommons.net/moin.cgi/IdentityRightsAgreementsCharter) по образцу чрезвычайно успешной модели Creative Commons для лицензирования авторских прав (www.creativecommons.org). Цель Identity Rights Agreements — создать малый набор унифицированных соглашений, каждое из которых представлено узнаваемой пиктограммой, через которые сайты могут предоставлять, а частные лица выбирать условия обмена личной информацией.

И наконец, в течение нескольких лет на ежегодном семинаре ACM Digital Identity Management Workshop представляются новые исследования в области цифровых удостоверений. В 2007 году внимание было обращено на принятие пользователями парадигмы цифрового удостоверения в приложениях Web 2.0 (www2.pflab.ecl.ntt.co.jp/dim2007).

Литература

1. Security Assertion Markup Language (SAML) V2.0, Oasis, 2007.
2. OpenID Authentication 2.0, OpenID Foundation, 2007.
3. OpenID Attribute Exchange 1.0, OpenID Foundation, 2007.
4. Identity Selector Interoperability Profile 1.0, Microsoft, 2007.
5. A. Pfitzmann and M. Hansen, Anonymity, Unlinkability,Undetectability, Unobservability, Pseudonymity, and Identity Management-A Consolidated Proposal for Terminology v0.31, 15 Feb. 2008.
6. Extensible Resource Identifier (XRI) Syntax 2.0, Committee Specification, Oasis, 2005.
7. Identity Web Services Framework 2.0, Liberty Alliance, 2006.
8. G. Wachob et al., eds., Extensible Resource Identifier (XRI) Resolution 2.0, Committee Draft, Feb. 2008.
9. J. Hodges, OpenID-SAML Lightweight Web Browser SSO Profile, IdentityMeme, 21 Sept. 2007.
10. A. Nadalin et al., eds., WS-Trust 1.3, Oasis Web Services Secure Exchange Technical Committee, 19 Mar. 2007.
11. J. Hodges, Technical Comparison: OpenID and SAML, IdentityMeme, 17 Jan. 2008.
12. T. Abe, H. Itoh, and K. Takahashi, «Implementing Identity Provider on Mobile Phone,» Proc. ACM Workshop on Digital Identity Management (ACM DIM), ACM Press, 2007.

Ева Малер (eve.maler@sun.com ) — ведущий инженер компании Sun Microsystems;
Драммонд Рид (drummond.reed@cordance.net ) — главный архитектор компании Cordance и вице-президент по инфраструктуре компании Parity Communications, сопредседатель технических комитетов Oasis Extensible Resource Identifier (XRI) и XRI Data Interchange (XDI).