Интернет журныл о промышленности в Украине

Інфраструктура аутентифікації в національному масштабі

  1. багатовузловий аутентифікація
  2. Спільнота PACI
  3. Технічні вимоги
  4. GRID SECURITY INFRASTRUCTURE
  5. розширення GSI
  6. Множинні уповноважені з видачі сертифікатів
  7. Отримання повноважень Kerberos
  8. Альтернативне управління повноваженнями
  9. Сервер повноважень MyProxy
  10. створення інфраструктури
  11. Додатки, орієнтовані на GSI
  12. Інструментарій, орієнтований на GSI
  13. література
  14. Технічні альтернативи многоузловой аутентифікації
  15. Kerberos
  16. Secure shell

15.02.2001 Ренді Балтер, Он Уелч, Дуглас Енгерт, Ян Фостер, Стівен пакунку

Зараз все частіше як окремі користувачі, так і цілі установи, що працюють в науці і промисловості, формують віртуальні організації, прагнучи об'єднати свої ресурси і досягти спільної мети. Одним із прикладів такої віртуальної організації служить програма 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.

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 так, щоб скоротити витрати на створення захисту віртуальної організації, щоб додати підтримку вдосконалених можливостей, таких як смарт-карти, і обмежити делегування для забезпечення більш детального контролю доступу.

Ренді Балтер ( [email protected] ) - директор відділення колективних обчислювальних середовищ Національного центру суперкомп'ютерних додатків університету штату Іллінойс. Он Уелч ( [email protected] ) - старший системний інженер-розробник Національного центру суперкомп'ютерних додатків. Дуглас Енгерт ( [email protected] ) - співробітник підрозділу електроніки і комп'ютерних технологій Арагонской національної лабораторії. Ян Фостер ( [email protected] ) - провідний науковий співробітник і заступник директора підрозділу математики та інформатики Арагонской національної лабораторії і професор інформатики Чиказького університету. Стівен пакунку ( [email protected] ) - менеджер лабораторії розподілених систем Арагонской національної лабораторії.

література

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, BC 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-браузери.