Об'єднана аутентифікація з використанням ADFS

Наша взаимовыгодная связь https://banwar.org/

Багато компаній зацікавлені в можливості обмінюватися даними з довіреними зовнішніми користувачами через Web. Провайдерам і клієнтам зручно звертатися до ресурсів з використанням власних облікових записів, не створюючи облікових записів в чужій системі. Однак необхідно, щоб доступ отримували тільки перевірені користувачі. Існує кілька рішень, за допомогою яких можна виконати принаймні деякі з цих вимог, зокрема об'єднання аутентифікації. У випущеної в кінці 2005 р операційній системі Windows Server 2003 Release 2 (R2) є відповідне рішення - служби ADFS (Active Directory Federation Services).

Об'єднання аутентифікації - складна технологія, компоненти і термінологія якої знайомі не всім адміністраторам. У даній статті дається короткий опис способів її застосування. Потім розглядаються служби ADFS і наводиться простий приклад функціонування ADFS. В одній з наступних статей будуть більш детально описані компоненти ADFS, принципи їх дії і порядок установки.

завдання

Мета об'єднання аутентифікації - спростити обмін інформацією з перевіреними зовнішніми користувачами компаній. Такі користувачі можуть бути компаніями партнерами або споживачами. Наприклад, виробнича компанія може надати провайдерам доступ до своєї бази даних контролю поставок, а аналітична компанія - відкрити репозитарій публікацій для компаній-клієнтів. Ключова вимога - захист даних і доступ до них тільки перевірених користувачів. Два типових рішення, які при цьому застосовуються, - системи управління доступом в Web і брокери аутентифікації. Об'єднання аутентифікації - третій і, можливо, оптимальний варіант.

Щоб побудувати систему управління доступом в Web, компанії зазвичай застосовують комерційні програмні пакети. Широко відомі приклади - eTrust SiteMinder компанії CA і Oracle Access Manager. Класичні системи управління доступом в Web працюють зі зверненнями до ресурсів компанії, визначаючи індивідуальні облікові записи для зовнішніх користувачів. Цей підхід не завжди вдало масштабується, може привести до збільшення навантаження на адміністраторів і незручний для зовнішніх користувачів. Останній недолік проявляється особливо гостро, якщо користувачам доводиться працювати з системами управління доступом в Web декількох компаній.

Більш вдалий спосіб - надати користувачам єдину обліковий запис для доступу до ресурсів в різних компаніях. Такий підхід застосовується в іншій категорії рішень - брокерів аутентифікації. Широко відомий приклад брокера аутентифікації Microsoft - Windows Live ID (стара назва Microsoft Passport). Брокери аутентифікації - не ідеальна рішення. Основна проблема полягає в небажанні довіряти управління своїми обліковими записами зовнішньому керуючому. Центральний репозитарій для зберігання облікових записів стає головною мішенню атаки і єдиною точкою відмови.

Об'єднання аутентифікації - третє рішення проблеми доступу до даних, і йому не властиві недоліки інших підходів. Об'єднання аутентифікації забезпечує єдиний вхід (SSO) для користувачів і дозволяє компаніям контролювати власні облікові записи. Крім того, при об'єднанні аутентифікації не виникає центральних точок атаки або відмови. З іншого боку, в поточних рішеннях з об'єднанням аутентифікації відсутні деякі можливості, які є, наприклад, в рішеннях управління доступом через Web, такі як проста інтеграція додатків і потужні функції аудиту та звітів.

Принципи об'єднання аутентифікації

Об'єднання аутентифікації (управління об'єднаною аутентификацией) являє собою зв'язування різних провайдерів засобів аутентифікації і ресурсів. Компанія може бути провайдером аутентифікації, провайдером ресурсів або виконувати обидві ці ролі. Провайдер ресурсів надає і управляє доступом до таких ресурсів, як захищений паролем. Більшість компаній комбінують ці функції: вони надають ресурси компаніям-партнерам і керують обліковими записами власних співробітників.

В контексті об'єднання аутентифікації провайдери аутентифікації і ресурсів іноді називаються «островами» (island); цей термін підкреслює їх ізольованість один від одного. «Острова» існують між компаніями, але можуть бути і всередині однієї організації. Поширена помилка полягає в тому, що об'єднання аутентифікації відноситься тільки до організації обміну та захисту даних між компаніями. У компаніях часто є внутрішні «острова», створені з метою безпеки або з політичних міркувань. У таких випадках об'єднання аутентифікації теж може бути ефективним.

Зв'язування різних островів перетворює об'єднання у федерацію в цікаву технологічну задачу. Зазвичай островам компанії притаманні свої особливості і способи вирішення завдань. У них застосовуються власні стандарти іменування облікових записів і механізми перевірки аутентифікації (перевірка справжності) і управління доступом до ресурсів (авторизація). Стандарти об'єднання забезпечують спільну мову для представлення даних про облікові записи, перевірки автентичності та авторизації в форматі, зрозумілому для різних провайдерів засобів аутентифікації і ресурсів, а також для обміну цією інформацією між партнерами по федерації.

На сьогодні існує три основних набору стандартів об'єднання, іменованих потоками. У кожного потоку є свої прихильники; Microsoft, IBM і VeriSign віддають перевагу набору специфікацій Web Services-Federation (WS-Federation). Під врізки «Стандарти об'єднання аутентифікації» коротко описані WS-Federation і конкуруючі потоки. Компаніям, які мають намір організувати федерацію, переважно використовувати один стандарт об'єднання. Але це не обов'язкова умова: деякі рішення (такі, як HP OpenView Select Access і IBM Tivoli Federated Identity Manager) сумісні з різними стандартами об'єднання або перетворять формати різних стандартів.

У специфікацію WS-Federation входять два федеративних профілю: один об'єднує пасивних клієнтів (профіль пасивного запитувача), інший - активних клієнтів (профіль активного запитувача). Пасивні клієнти - браузери, які просто підтримують протокол HTTP і захист на рівні гнізд (SSL), щоб убезпечити HTTP-трафік. Пасивний клієнт «не знає», що він об'єднаний в федерації.

В діях активного клієнта враховуються вимоги протоколів об'єднання; він більш гнучкий, потужний і безпечний, ніж пасивний клієнт. Активні клієнти спочатку сумісні з протоколом Simple Object Access Protocol (SOAP).

Зараз Microsoft ADFS будує маркери, сумісні з Security Assertion Markup Language (SAML) 1.1, і підтримує пасивних, але не активних клієнтів WS-Federation.

архітектура ADFS

ADFS задіє інші будівельні блоки управління посвідченнями Microsoft, такі як Active Directory (AD) і Active Directory Application Mode (ADAM), і тісно інтегрується з Microsoft IIS. На рис. 1 показані основні компоненти простого примірника ADFS: сервери федерації, на яких функціонує компонент ADFS Federation Service; агент ADFS Web Agent і репозитарій AD або ADAM. На рис. 1 інфраструктура ADFS дозволяє користувачам браузера з провайдера аутентифікації звертатися до Web-додатком на сервері IIS, розташованому в провайдера ресурсів. Користувачі браузера задіють обліковий запис AD, певну провайдером аутентифікації.

Інструментарій ADFS відповідає вимогам сертифікатів X.509, це дозволяє встановити довірена відношення між провайдером аутентифікації і провайдером ресурсів і забезпечити безпечний обмін даними між ними. Довірені відносини ADFS - односторонні. На рис. 1 провайдер ресурсів довіряє провайдеру аутентифікації. Довірчі відносини - нетранзитивність, т. Е. Якщо A довіряє B, а B довіряє C, то це не означає, що A автоматично довіряє C. Найбільш важливі компоненти ADFS - сервери федерації на провайдера аутентифікації і провайдера ресурсів.

• Сервер федерації на провайдера аутентифікації використовує AD або ADAM для перевірки автентичності користувачів. Якщо перевірка користувача виконана успішно, то сервер федерації провайдера аутентифікації генерує cookie, файли-маяки аутентифікації і маркери безпеки. Ці маркери безпеки містять запити про користувача. Приклади типової заявки - ім'я користувача, членство в групі і адресу електронної пошти. Сервер федерації провайдера аутентифікації підписує маркери безпеки, щоб захистити їх від незаконних змін.
• Сервер федерації на провайдера ресурсів перевіряє cookie-файли аутентифікації і маркери безпеки, отримані від користувачів, які намагаються звернутися до його Web-додатком. Сервер федерації також перетворює cookie-файли та маркери в формат, прийнятний для Web-додатки, і передає їх в Web-додаток.

У наступному розділі пояснюється процес обміну cookie-файлами аутентифікації і маркерами безпеки між серверами федерації провайдерів аутентифікації і ресурсів.

Агенти Web ADFS Agent дозволяють Web-додатків на базі IIS брати участь в федерації ADFS. Агенти Web ADFS Agent можуть взаємодіяти з серверами федерації і обробляти cookie-файли аутентифікації і маркери безпеки ADFS. Щоб перетворити існуюче Web-додаток в ADFS-сумісний, іноді потрібно внести зміни в початковий текст. В основному зміни пов'язані з можливістю приймати заявки в маркерах безпеки ADFS (т. Е. З їх допомогою перевіряти користувачів). Щоб підготувати Web-додаток для ADFS, можна задіяти механізм Authorization Manager (настройка проводиться з оснащення Authorization Manager консолі Microsoft Management Console) або один з інтерфейсів ASP.NET API (IsInRole або чисті заявки). Додаток Microsoft SharePoint Portal Server готове для роботи з ADFS без змін в початковому тексті.

функціонування ADFS

На рис. 2 показані повідомлення ADFS передача даних між основними елементами ADFS. В даному прикладі ADFS дозволяє користувачеві браузера, визначеному в провайдера аутентифікації, звернутися до Web-додатком на провайдера ресурсів. В процесі обміну пересилаються наступні повідомлення, що відносяться до ADFS.

• Крок 1. Користувач браузера, визначений у провайдера аутентифікації, намагається звернутися до додатка Web-сервера, розміщеному в провайдера ресурсів.
• Крок 2. Агент Web ADFS Agent виявляє, що користувач не пройшов перевірку автентичності в ADFS, і відсилає його в сервер федерації провайдера ресурсів.
• Крок 3. На даному етапі, відомому як виявлення домашньої області, користувач браузера надає інформацію про своє домені сервера федерації провайдера ресурсів. Домашній домен - місце, в якому визначено і обслуговується посвідчення користувача, іншими словами, провайдер посвідчення користувача. При першому підключенні користувача до Web-додатком користувач надає такі відомості, як ім'я провайдера посвідчення або адресу електронної пошти. При повторних запитів сервер федерації провайдера ресурсів відшукує ці дані в cookie-файлі, переданому користувачем.
• Крок 4. В залежності від даних, переданих в процесі виявлення домашньої області, сервер федерації провайдера ресурсів перенаправляє браузер користувача на сервер федерації провайдера посвідчення для перевірки автентичності.
• Крок 5. Користувач браузера проходить перевірку автентичності в сервері федерації свого провайдера аутентифікації з використанням свого облікового запису AD і відповідних облікових даних.
• Крок 6. Сервер федерації провайдера аутентифікації перевіряє облікові дані користувача в AD. Якщо перевірка завершується успішно, то сервер федерації провайдера аутентифікації генерує cookie-файл аутентифікації і маркер безпеки ADFS.
• Крок 7. Сервер федерації провайдера аутентифікації перенаправляє браузер користувача разом з маркером безпеки і cookie-файлом аутентифікації на сервер федерації провайдера аутентифікації.
• Крок 8. Сервер федерації провайдера ресурсів перетворює заявку в маркері безпеки в набір заявок, які розпізнаються Web-додатком, розміщеним в провайдера ресурсів, і вставляє їх в новий маркер безпеки. Цей процес відомий як перетворення заявки. Сервер федерації також генерує cookie-файл аутентифікації і перенаправляє користувача браузера (разом з новим маркером безпеки і cookie-файлом аутентифікації) в агент Web ADFS Agent Web-додатки. Web ADFS Agent перевіряє cookie-файл аутентифікації, витягує заявку з маркера безпеки і передає її в Web-додаток.
• Крок 9. Web-додаток інтерпретує заявки в ході перевірки автентичності і передає відповідні Web-матеріали в браузер користувача.

ADFS для єдиної процедури реєстрації в Web

ADFS - рішення для єдиного Web-входу, за допомогою якого компанії можуть розширити сферу застосування своїх додатків на базі Web і AD на інші компанії. Користувачам Windows 2003, які потребують єдиному Web-вході, слід звернути увагу на ADFS. Звичайно, ADFS не вистачає деяких передових можливостей чистих Web-рішень, таких як CA eTrust SiteMinder або HP OpenView Select Access. А для розробки та інтеграції Web-додатків може знадобитися більше часу, але це безкоштовний компонент Windows 2003 R2, тісно інтегрований з Web-сервером IIS і SharePoint Portal Server компанії Microsoft.

Для успішного застосування ADFS Web-додатки AD і IIS повинні взаємодіяти з провайдерами ресурсів і аутентифікації, відмінними від Microsoft. Кілька провайдерів програм вже приєдналися до ADFS і випустили або обіцяють випустити ADFS-сумісні рішення, які розширюють область дії ADFS на середовища, що базуються нема на продуктах Microsoft. Як приклад можна привести рішення компаній Centrify і Quest Software, які дозволяють поширити єдину Web-реєстрацію ADFS на Web-сервери не на основі IIS, такі як Apache Tomcat і IBM WebSphere. Компанія Microsoft продемонструвала можливість взаємодії ADFS з продуктами управління посвідченнями від IBM, CA, Oracle, BMC Software, Ping Identity і RSA Security.

Підходящої відправною точкою для вивчення ADFS буде оглядовий документ, підготовлений компанією Microsoft, який можна завантажити за адресою http://www.microsoft.com/windowsserver2003/r2/identity_management/adfswhitepaper.mspx .

Жан де Клерк

( [email protected] ) - співробітник Security Office компанії HP. Спеціалізується на управлінні ідентифікаційними параметрами і безпекою в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (видавництво Digital Press).

додаткова література

Ресурси Microsoft Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2, http://www.microsoft.com/windowsserver2003/r2/identity_management/adfswhitepaper.mspx

Стандарти об'єднання аутентифікації

Існує три основних потоку стандартів об'єднання аутентифікації.

• Потік Security Assertion Markup Language (SAML) належить організації з розвитку структурованих інформаційних стандартів (OASIS). SAML надає діалект мови XML для вбудовування ідентифікаційних даних в XML-повідомлення. В даний час в федераціях використовуються версії SAML 1.2 і 2.0. Версію SAML 2.0 можна розглядати як з'єднання SAML 1.2 зі специфікацією Liberty Identity Federation Framework (ID-FF) 1.1. Додаткові відомості можна знайти за адресою http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security .
• Потоки Liberty ID-FF 1.2 і Liberty Identity Web Services Framework (ID-WSF) 1.1 підтримуються галузевим консорціумом Liberty Alliance, в який входить більше 150 компаній і організацій, зацікавлених у стандартизації об'єднання аутентифікації. Додаткові відомості наводяться за адресою http://www.projectliberty.org .
• Потік WS-Federation підтримують компанії IBM, Microsoft і VeriSign. Він являє собою частину більш широкого набору специфікацій для Web-служб. WS-Federation - порівняно незалежний потік, що має деякі спільні риси з потоками Liberty Alliance. У 2005 р компанії Sun Microsystems і Microsoft оголосили про специфікації, яка забезпечує взаємодію між стандартами WS-Federation і Liberty ID-FF для єдиного Web-входу (SSO). Додаткові відомості про WS-Federation см. За адресою http://schemas.xmlsoap.org/ws/2003/07/secext ; додаткові відомості про взаємодію між WS-Federation і Liberty ID-FF можна знайти за адресою http://xml.coverpages.org/WebSSO-InteropProfile200505.pdf .