Сейчас все чаще как отдельные пользователи, так и целые учреждения, работающие в науке и промышленности, формируют виртуальные организации, стремясь объединить свои ресурсы и добиться общей цели. Одним из примеров такой виртуальной организации служит программа Partnerships for Advanced Computational Infrastructure (PACI) Национального научного фонда США, предлагающая инфраструктуру следующего поколения для работ в области информатики.

PACI, довольно крупные и давно существующие образования, основанные 5-10 лет назад, объединяют в сумме около 50 институтов и тысячи ученых. Есть и другие виртуальные организации, возможно, существующие не так долго и не такие многочисленные.

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

Наш коллектив создает и развертывает инфраструктуру аутентификации и определения прав доступа, удовлетворяющую этим требованиям: Grid Security Infrastructure [1]. GSI предлагает защищенные процедуры однократной регистрации и сохраняет за отдельными вычислительными узлами контроль за соблюдением правил предоставления доступа и требований локальной защиты. В рамках CGI созданы специальные версии таких распространенных программ, как FTP и rlogin, а также API-интерфейс для создания защищенных приложений. Десятки суперкомпьютеров и центров данных уже используют GSI, чего нельзя сказать о подавляющем большинстве иных инфраструктур защиты.

Многоузловая аутентификация

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

Сообщество PACI

NSF PACI — два консорциума, объединяющие около 50 университетов и государственных лабораторий, созданные с целью разработки инструментария следующего поколения для решения разного рода научных проблем. PACI предоставляют ресурсы не только своим непосредственным участникам, но даже более масштабным и менее формально организованным сообществам пользователей, состоящим из нескольких тысяч исследователей, преподавателей и студентов. Различные подмножества сообщества PACI взаимодействуют по-разному, будь то разработка программной системы следующего поколения, удаленная работа с электронным микроскопом или доступ к суперкомпьютеру. Большинство вовлеченных в сообщество институтов поддерживают определенную форму аутентификации и определения прав доступа.

Институты-участники PACI имеют собственные развитые компьютерные центры, и в каждом из них имеются хорошо продуманные правила и процедуры для различных аспектов работы таких центров, в том числе для компьютерной защиты и, в частности, аутентификации и авторизации. Многими узлами, входящими в виртуальную организацию, используются стандартные для ОС Unix процедуры аутентификации с зашифрованными посредством DES паролями; другие применяют различные версии Kerberos и распределенной вычислительной среды (DCE); некоторые полагаются на механизмы одноразовых паролей.

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

Технические требования

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

Пользователи. С точки зрения пользователей, основное требование — простота: доступ к ресурсам виртуальной организации не должен сильно отличаться от доступа к ресурсам локальной организации. Должна поддерживаться единая процедура регистрации, при которой пользователю необходимо лишь однажды зарегистрироваться и получить возможность обратиться ко всем доступным для него ресурсам. Программы, запускаемые от имени пользователя, должны обладать подмножеством прав пользователя и иметь доступ к соответствующим этим правам ресурсам [2].

Такое решение должно прозрачным образом взаимодействовать с традиционными средствами удаленного доступа: удаленная регистрация через Telnet и rlogin, доступ к файлам посредством FTP, Web-браузеры и такие платформы взаимодействия, как CORBA и MPI. Оно должно также допускать реализацию новых межузловых приложений за счет предоставления стандартизованных API-интерфейсов доступа к функциям защиты. Например, группа, разрабатывающая инструментарий совместного проектирования, должна иметь возможность легко интегрировать механизмы аутентификации и предоставления прав доступа.

Узлы. Функционирование узлов, предоставляющих ресурсы, накладывает на инфраструктуру аутентификации и предоставления прав доступа два следующих ограничения.

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

Во врезке «Технические альтернативы многоузловой аутентификации» объясняется, почему два самых популярных подхода к аутентификации — Kerberos [3] и secure shell (ssh) — не отвечают этим требованиям, в связи с чем и возникла необходимость в создании GSI.

GRID SECURITY INFRASTRUCTURE

GSI представляет собой альтернативный подход к организации межузловой защиты. Его разработка была начата в рамках исследовательского проекта Globus [4] для поддержки распределенных вычислительных сред и Computational Grid [5], которые аналогичны виртуальным организациям. GSI имеет дело с внутренними операциями, предоставляя различные локальные решения защиты для узлов, входящих в Computational Grid. Как показано на рис. 1, GSI обладает следующими важными особенностями.

  • Полномочия, использующие сертификаты стандарта X.509v3 в качестве частных ключей, представляют «личность», или средства идентификации, каждого объекта — пользователя, ресурса или программы, указывая имя объекта и дополнительную информацию, скажем, открытый ключ. Уполномоченный по выдаче сертификатов (certification authority — CA), некая пользующаяся доверием независимая организация, подписывая сертификат, связывает средства идентификации объекта с открытым ключом.
  • Алгоритм аутентификации, определенный протоколом Secure Socket Layer Version 3 (SSLv3), выполняет идентификацию объекта. Достоверность результатов такой проверки определяется степенью доверия к CA, поэтому локальный администратор принимает эти сертификаты, используя их затем для проверки цепочек сертификатов.
  • Объект может делегировать подмножество своих прав (например, процесс, порождающий другой процесс) третьей стороне, создавая временные средства идентификации, называемые посредником (proxy). Сертификаты посредников формируют цепочку, которая начинается с CA, а затем наращивается, когда сначала пользователь, а затем посредники пользователя подписывают сертификаты. Путем проверки цепочки сертификатов процессы, инициированные одним и тем же пользователем на различных узлах, могут аутентифицировать друг друга, проводя проверку обратно по цепочке сертификатов до тех пор, пока не будет найден исходный сертификат пользователя.
  • Каждый ресурс может задавать свои правила для определения того, как надо реагировать на входящие запросы. Первоначально GSI использовала просто список контроля доступа, но в текущей версии реализованы более развитые методы.
  • Протокол аутентификации выполняет проверку подлинности глобальных имен участвующих сторон, но GSI должна преобразовать это имя в локальное (например, регистрационное имя или имя доверителя Kerberos), прежде, чем локальная система защиты сможет его использовать. GSI выполняет эту процедуру на локальном узле, сверяясь с простым текстовым файлом соответствий, который устанавливает связи между глобальными и локальными именами.
  • Стандартный интерфейс GSS-API обеспечивает доступ к функциям защиты [6]. GSI использует OpenSSL или SSLeay (свободно распространяемую реализацию SSLv3) для своих протоколов аутентификации и поддержки сертификатов посредников. SSLv3 широко применяется для обеспечения безопасности в Web.

Рис. 1. Схематическое изображение базовых операций, которые поддерживает GSI
Следуя за жирной линией из верхнего левого угла, можно проследить процесс аутентификации пользователей с помощью инфраструктуры открытого ключа, применяемых к полномочиям пользователей (CU). Затем создаются временные полномочия посредника пользователя (CUP), выполняются запросы к удаленным ресурсам, представленные посредниками ресурсов, содержащим полномочия посредников ресурсов (CR), и, наконец, авторизация и определение соответствия глобального представления локальному на конкретном узле, вытекающее в создание удаленного процесса на Узле 2, со своими собственными делегированными полномочиями (CP). Можно также видеть, каким образом подобный удаленный процесс может использовать делегированные полномочия для инициации дальнейших запросов к другим узлам (в этом случае, запрос на создание процесса к Узлу 1) и участия в во внутренних взаимодействиях, которых требует аутентификация (пунктирная линия).

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

  • С точки зрения пользователей, глобальное имя и полномочия посредников означают, что пользователю для получения доступа ко всем ресурсам необходимо только один раз пройти процедуру аутентификации, а полномочия посредников и процедура делегирования полномочий позволяют программам, работающим от имени пользователя, обращаться к ресурсам. Использование стандартов X.509, SSLv3 и GSS-API стимулирует разработку общего инструментария, ориентированного на GSI и более сложных приложений.
  • С точки зрения узлов, архитектура не требует пересмотра локальной инфраструктуры защиты; вместо этого узлы просто устанавливают относительно простые серверы, поддерживающие GSI, которые используют хорошо известные стандарты. Узлы управляют правилами работы с помощью списка контроля доступа и файла соответствий, поэтому администраторам удобно работать с CSI и они готовы развертывать ее параллельно с ssh и другими механизмами удаленного доступа.

Расширения GSI

Являясь составной частью Globus Toolkit, инфраструктура GSI сейчас работает более чем в 80 организациях. Для удобства развертывания GSI потребовалось разработать несколько расширений, адаптирующих инфраструктуру к потребностям конкретных узлов. Самыми важными из этих расширений являются поддержка множественных уполномоченных по выдаче сертификатов, взаимодействие с локальной средой Kerberos, поддержка смарт-карт и вычислений в Web.

Множественные уполномоченные по выдаче сертификатов

В первоначальной реализации предполагалось, что все полномочия пользователя связаны с единым CA проекта Globus, но на практике оказалось, что пользователи должны иметь возможность предъявлять полномочия, полученные от любого источника: CA их собственного узла, CA, связанного с виртуальной организацией, например, с PACI, или коммерческого CA. Таким образом, узлы должны иметь возможность обрабатывать полномочия, подтвержденные различными CA; в то же время, в рамках политики контроля доступа, они должны сами определять, каким CA они могут доверять и что именно разрешено делать этим CA.

Браузеры, к примеру, часто позволяют управлять перечнем тех CA, которым они «доверяют», но не тем, что разрешается делать этим CA. На практике, однако, администраторы узлов могут захотеть оказать доверие лишь некоторым сертификатам, которые подписывает данный CA. Например, узел, предоставляющий учебные материалы, может доверять CA некоторого вуза, но не доверять сертификатам, выданным этим же CA для пользователей, не являющихся его студентами.

Для решения этих вопросов в GSI была добавлена функция общего контроля доступа, определенная с помощью Generic Authorization and Access Control API [7]. Эта функция позволяет приложениям отказываться от операции аутентификации на основе имени самого субъекта и объектов, подписавших сертификаты в цепочке, а не просто «личности» CA, выпускающего сертификаты. Пользователи могут предоставлять полномочия от любого CA и узел может принимать решение о том, принимать ли эти полномочия.

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

При развертывании GSI оба сообщества PACI создают CA для узлов, которые не хотят использовать свои собственные CA. Создание этих CA потребовало значительных усилий, поскольку приходилось определять политику в отношении сертификатов, приемлемую для всех участников виртуальной организации. В частности, National Computational Science Alliance предпринял активное участие в разработке такой политики, созданной на основе модели сертификационной политики проекта Federal Public Key Infrastructure Project [8].

Получение полномочий Kerberos

Чтобы взаимодействовать с локальной средой защиты в самом простейшем случае, GSI необходимо только определить соответствие глобального имени локальному имени субъекта на основе файла соответствий. Многие вычислительные узлы, однако, используют инфраструктуру защиты Kerberos, поэтому GSI должна также получить набор локальных полномочий в виде мандатов Kerberos. Чтобы получить эти полномочия, GSI должна иметь возможность проводить аутентификацию для области действия Kerberos, ячейки DCE или ячейки файловой системы Andrew, и Kerberos должна иметь возможность выпускать мандаты, на основе аутентификации GSI, включая посредников. Для этого был разработан SSLK5D — модифицированный центр распределения ключей Kerberos, выдающий мандат, который может быть использован как любой мандат, передаваемый Kerberos. Управляя SSLK5D и его базой данных для определения соответствия имен доверителям Kerberos, администратор безопасности сохраняет управление средой Kerberos или ячейкой DCE.

Функциональность SSLK5D похожа на предварительные стандарты PK_INIT, предложенные IETF и DCE RFC 68.4, с одним различием. Мы используем SSL, а не специализированный протокол для взаимодействия с сервером SSLK5D. Однако по мере того, как PK_INIT и RFC 68.4 становятся частью стандартной среды, они могут заменить SSLK5.

Как показано на рис. 2, такая поддержка создания полномочий Kerberos означает, что GSI может взаимодействовать с DCE, но не подменять ее.

Рис. 2. Получение полномочий Kerberos
Инфраструктура GSI использовалась в структуре, где некоторые узлы — A, B и C, а также D и E, используют распределенную вычислительную среду для межузловой аутентификации. GSI дает пользователям возможность обращаться к ресурсам в различных «DCE-облаках», в то же время позволяя использовать DCE и при межузловом взаимодействии там, где это возможно.

Альтернативное управление полномочиями

Как и многие другие инфраструктуры открытого ключа, GSI поддерживает частный ключ пользователя в зашифрованном виде в локальной файловой системе пользователя. При входе в систему пользователь вводит ключевую фразу для дешифровки частного ключа — подход, который имеет три недостатка.

  • Частный ключ может оказаться недоступен, когда пользователь находится в удаленном месте.
  • Легкомысленный пользователь может случайно разгласить ключевую фразу при аутентификации с сетевого терминала.
  • Злоумышленник может восстановить зашифрованный частный ключ, а затем использовать его при атаке в качестве основы для подбора ключевой фразы.

Эти опасения заставили нас расширить GSI таким образом, чтобы она позволяла хранить частный ключ пользователя на смарт-карте — устройстве размером с кредитную карточку, содержащую память емкостью от 4 до 16 Кбайт и микропроцессор, способный выполнять операции 1024-разрядного шифрования. Частный ключ пользователя никогда не остается на карте: при регистрации код генерации посредника обращается к карте для того чтобы получить подписанный сертификат посредника, используя протокол PKCS #11.

Сервер полномочий MyProxy

Одно из преимуществ того, что GSI базируется на сертификатах X.509 и SSLv3, состоит в том, что многие существующие программные продукты могут легко его использовать. Распространенные Web-браузеры могут использовать сертификаты GSI для аутентификации без каких-либо изменений. Браузеры, однако, не могут выполнять делегирование прав, а также поддерживать ограничения для порталов и другие способы организации вычислений на базе Web.

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

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

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

Мы также рассматриваем возможность использования MyProxy в качестве «бумажника полномочий», где пользователи могли бы хранить все свои полномочия для различных узлов. Когда приходят запросы на полномочия, сервер MyProxy может выбрать, какое полномочие делегировать, в зависимости от того, кто прислал запрос.

Создание инфраструктуры

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

Приложения, ориентированные на GSI

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

Что касается созданной нами специальной версией ssh, наши модификации состояли в том, чтобы GSS-API можно было использовать в качестве одного из механизмов аутентификации. Компания Van Dyke Technologies даже реализовала эти модификации в своем коммерческом продукте — SecureCRT. Пользователи могут представить свои полномочия GSI для аутентификации посредством ориентированного на GSI демона sshd, в том числе выполняя делегирование. Поскольку ssh поддерживает различные варианты Kerberos, пары ключей RSA и пароли, это обеспечивает полную обратную совместимость. Мы также используем GSS-API для разработки ориентированных на GSI клиентов и серверов FTP, в том числе широко используемого сервера wu-ftpd, клиента ncftp, ftpd-сервера Unitree и pftpd-сервера HPSS.

Инструментарий, ориентированный на GSI

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

Один инструмент — gss_assist, предлагает множество удобных функций для использования возможностей GSS. GSS-API — богатый и надежный интерфейс, но при этом сложный, а многим приложениям требуется только подмножество функций GSS-API. Gss_assist позволяет разработчикам приложений избежать ненужных сложностей, предоставляя более простой API-интерфейс, который при этом реализует все возможности защиты GSI. Многие функции gss_assist представляют собой простые «проекции» своих аналогов GSS-API с зафиксироавнными подразумеваемыми значениями параметров. Некоторые — более сложные, такие как «проекции» функций инициализации и определения контекста защиты, необходимы пользователям для аутентификации GSS-API и определения контекста.

Globus Toolkit представляет собой приложение на базе GSI, которое предлагает набор служб для создания распределенных приложений. Поскольку Globus Toolkit использует функциональность GSI, любое приложение, которое применяет свои механизмы для организации защиты, по существу, бесплатны. Например, MPICH-G2, расширенная версия популярной технологии Message Passing Interface, использует механизмы Globus Toolkit для инициации удаленных вычислений и, таким образом, нет необходимости делать что-то специальное для решения вопросов аутентификации и предоставления прав доступа при работе на нескольких узлах.

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

Рэнди Балтер (rbutler@ncsa.uiuc.edu) — директор отделения коллективных вычислительных сред Национального центра суперкомпьютерных приложений университета штата Иллинойс. Вон Уэлч (vwelch@ncsa.uiuc.edu) — старший системный инженер-разработчик Национального центра суперкомпьютерных приложений. Дуглас Энгерт (deengert@anl.gov) — сотрудник подразделения электроники и компьютерных технологий Арагонской национальной лаборатории. Ян Фостер (foster@mcs.anl.gov) — ведущий научный сотрудник и заместитель директора подразделения математики и информатики Арагонской национальной лаборатории и профессор информатики Чикагского университета. Стивен Тюке (tuecke@mcs.anl.gov) — менеджер лаборатории распределенных систем Арагонской национальной лаборатории.

Литература

1. I. Foster et al., «A Security Architecture for Computational Grids,» Proc. ACM Conf. Computers and Security, ACM Press, New York, 1998, pp. 83-91.
2. M. Gasser and E. McDermott, «An Architecture for Practical Delegation in a Distributed System,» Proc. 1990 IEEE Symp. Research in Security and Privacy, IEEE CS Press, Los Alamitos, Calif., 1990, pp. 20-30.
3. J. Steiner, B.C. Neuman, and J. Schiller, «Kerberos: An Authentication System for Open Network Systems,» Proc. Usenix Conf., Usenix Assoc., Berkeley, Calif., 1988, pp. 191-202.
4. I. Foster and C. Kesselman, «Globus: A Toolkit-Based Grid Architecture,» The Grid: Blueprint for a Future Computing Infrastructure, I. Foster and C. Kesselman, eds., Morgan Kaufmann, San Francisco, 1999, pp. 259-278.
5. I. Foster and C. Kesselman, eds., The Grid: Blueprint for a Future Computing Infrastructure, Morgan Kaufmann, San Francisco, 1999.
6. J. Linn, «Generic Security Service Application Program Interface, Version 2, Update 1,» RFC 2743, Internet Engineering Task Force, 2000
7. T. Ryutov and C. Neuman, «Access Control Framework for Distributed Applications,» Internet Draft, Internet Engineering Task Force, Nov. 1998
8. Legal Policy Working Group, «Part B-The Model Certificate Policy,» Government Information Technology Services, Federal PKI Steering Committee

A National-Scale Authentication Infrastructure, Randy Butler, Von Welch, Douglas Engert, Steven Tuecke, IEEE Computer, December 2000, pp. 60-66. Copyright IEEE CS, 2000, Reprinted with permission. All rights reserved.

Технические альтернативы многоузловой аутентификации

Два самых популярных подхода к аутентификации — Kerberos и secure shell — не отвечают нашим требованиям.

Kerberos

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

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

Secure shell

Secure shell (ssh) — широко используемая технология регистрации, соответствующая некоторым нашим требованиям: она опирается на аутентификацию с помощью открытого ключа, использует шифрование каналов для защиты полномочий пользователей и легко устанавливается. Пользователям ssh нравится возможность довольно простой реализации таких функций, как удаленная регистрация и копирование файлов. ssh, однако, имеет два серьезных недостатка.

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