Які проблеми взаємовідносин B2B я маю на увазі? Уявіть, що підприємство, яке випускає велосипеди і що називається Fabrikam, хоче створити веб-додаток, що дозволить уповноваженим дилерам закуповувати велосипеди і запчастини за оптовими цінами. При цьому у підприємства більше двохсот організацій-дилерів, в кожній з яких є кілька людей, яким знадобиться цей додаток. Компанії Fabrikam необхідний захищений механізм входу в систему.
Очевидне рішення полягає в тому, щоб створити базу даних, що містить імена користувачів і паролі, але це рішення може бути дуже дорогим і трудомістким. Якщо хтось подзвонить в Fabrikam, заявивши, що він є посадовцям певного дилера, то як компанія перевірить цю заяву? Ймовірно, їм доведеться зв'язатися з довіреною особою в дилерській організації, щоб перевірити статус службовця перед тим, як надати йому новий обліковий запис. Тепер уявімо собі вартість обслуговування такого облікового запису: люди іноді забувають імена, паролі і мають інші проблеми. А що трапиться, якщо службовець буде звільнений з дилерської організації? Чи всі будуть пам'ятати, що потрібно вчасно повідомити Fabrikam про видалення облікового запису цього користувача? Якщо немає, такий користувач може прийти додому і розмістити помилкові замовлення від імені дилера.
Зауважте, що фактор довіри тут теж грає свою роль. Fabrikam довіряє кожному дилеру в тому, що вони нададуть їй точний список службовців, яким дозволено робити замовлення через веб-додаток Fabrikam.
Рішення із застосуванням ADFS
ADFS допоможе вам встановити довірчі відносини і зменшити потребу в облікових записах користувачів. Навіщо створювати базу даних облікових записів користувачів для вашого застосування, коли у дилерів вже є ПО для аутентифікації своїх користувачів?
архітектура ADFS
Тепер я покажу вам різні частини ADFS і поясню деяку термінологію. У будь-яких федеративних відносинах одна сторона надає користувачів (облікові записи), а інша - додатки (ресурси). Встановивши службу ADFS, ви конфігуріруете її політику довіри через оснащення управління ADFS (вона міститься в папці Administrative Tools) і складаєте список партнерів, з якими хочете встановити федеративні відносини (створити федерацію). Користувачі партнерської організації за наявними в ній облікових записів будуть звертатися до додатків з підтримкою ADFS у партнера по ресурсам. На рис. 1 показано дерево політик довіри ADFS обох сторін, що утворили федерацію.
Мал. 1. Політика для двох партнерів
федеративний вхід
Пам'ятайте веб-агент в додатку, який шукав cookie для входу в систему? Це він запустив всю цю послідовність подій. Тепер, коли cookie існує, веб-агент відкриває його і читає заяви (claims) в маркері SAML, випущеному службою федерації Fabrikam. Після цього веб-агент дозволяє завантаження веб-сторінки додатка. Якщо з додатком потрібно знати ім'я увійшов в систему користувача, йому досить перевірити звичайне місце: HttpContext.User.Identity.Name.
IIdentity, який використовується для передачі цієї інформації, реалізований в типі SingleSignOnIdentity, який також надає ряд корисних засобів, в тому числі метод аутентифікації, застосовуваний партнером по облікових записів для аутентифікації користувача в своїй організації. З цього класу додаток може також дізнатися весь набір заяв, посланий його службою федерації.
Захист федеративного входу в систему
Тепер розглянемо докладніше, як забезпечується безпека входу в систему. Один вектор атаки може полягати в тому, щоб зчитувати маркери SAML, а потім відтворювати їх, підміняючи легітимного користувача. Щоб запобігти цьому, вся взаємодія відбувається по протоколу HTTPS. Це дуже важливо; якщо ви спробуєте встановити ADFS, що не встановивши сертифікат SSL для веб-сайту за замовчуванням в IIS, установник ADFS попередить вас і вийде з режиму установки перш, ніж вона почнеться.
А як щодо використовуваних при вході в систему cookie, що містять заяви? Якби користувач захотів підняти свої привілеї при доступі до додатка, він міг би просто додати заяви в маркер SAML в своєму cookie! Але цей вид підробки даних може бути виявлений, так як кожен маркер SAML підписується закритим ключем, відомим лише випустила його службі федерації. Все це має значення при розгортанні ADFS. Якщо ви виступаєте в ролі партнера по ресурсам, кожен з ваших партнерів по облікових записів повинен надати сертифікати для своїх служб федерації. Ваша служба федерації ресурсів буде використовувати сертифікат партнера по облікових записів, щоб перевіряти підписи в маркерах SAML. Веб-агент повинен робити щось подібне, перевіряючи, що кожен маркер SAML, який він отримує через cookie для входу в систему, підписаний службою федерації партнера по ресурсам.
Сookie, створені ADFS, завжди позначаються двійкового прапором Secure, що вказує, що браузер повинен посилати cookie-тільки по HTTPS, а не HTTP. Тому, якщо будь-яка частина вашого застосування використовує протокол HTTP, cookie для входу в систему буде тут відсутні, і відповідно не буде доступу до інформації про ідентифікацію користувача. Вийде так, ніби користувач є анонімним. Я б порадив виконувати всі додаток із застосуванням SSL, щоб полегшити собі життя і знизити ймовірність попадання конфіденційних даних до зловмисника.
Помилки, пов'язані з викликом крос-сайтовий сценаріїв (cross-site scripting, XSS), можуть мати серйозні наслідки для веб-додатки на основі ADFS, як і в будь-якій системі, що використовує cookie для подання сеансів входу в систему. Сookie легко вкрасти з програми з такою уразливістю, а якщо вдалося роздобути cookie, вдасться і увійти в систему. В якості запобіжного ешелонованої захисту термін дії cookie ADFS для входу в систему мають закінчитися в кінці робочого дня, і цей інтервал можна налаштувати в політиці довіри ADFS. Якщо ви погано знайомі з XSS і з тим, як уникнути їх, витратьте півгодини на інтерактивну лабораторну роботу по XSS, написану мною.
Звідки ти, користувач?
Одна з цілей створення ADFS-додатки - не забивати голову користувачеві такого роду деталями. Магазин Northwind, що торгує велосипедами, може пропустити цей етап, надаючи своїм користувачам доступ до веб-сайту Fabrikam через посилання з магічним параметром в рядку запиту - whr. Веб-агент шукає цей параметр в рядку запиту і, якщо знаходить, витягує його з рядка запиту під час попередньої обробки. Значення цього параметра є URI служби федерації партнера (у кожній служби федерації є свій URI). Тому службовці в магазині Northwind можуть отримати приблизно таку посилання:
Це дасть ADFS достатньо інформації, щоб не виводити користувачеві інтерактивну сторінку зі списком дилерів, в якому він повинен вказати свою організацію.
Заяви та перетворення
Я вже багато говорив про заяви (claims) у цій статті. Представляючи собою нове і все більш важливе поняття, що відноситься до концепції захисту на платформі Windows, заяви є універсальним способом формування тверджень про таку сутності, як користувач. Розглянемо квиток Kerberos, що містить ідентифікатори користувача і доменної групи для увійшов в систему користувача. Насправді це просто набір заяв, підписаний контролером домену, який згенерував квиток. Ідентифікатор користувача - заява про ідентифікацію. Хоча така заява може використовуватися для аудиту або персоналізації, воно зазвичай не застосовується для управління доступом. Більш ймовірно, що для перевірки прав доступу будуть використані групи, зазначені у квитку. Наприклад, якщо ви є членом групи Managers, вам може бути дозволено стверджувати дорогі закупівлі.
Кожна компанія визначає набір заяв для своєї організації; це схоже на створення зрозумілого їй словника. Так, Fabrikam може визначити заяву групи під назвою «Власник», яка представляє власника дилерського магазину, який торгує велосипедами. Але магазин Northwind може розподілити ці ж роль в заяві «Менеджер». Це нормально, якщо ці заяви мають однакове значення, так як власник Northwind може використовувати федеративну політику довіри свого ресурсу, щоб зіставити своє виходить заяву «Менеджер» із заявою «Власник», яке здатна зрозуміти Fabrikam. Адміністратори можуть налаштувати такі зіставлення на обох сторонах, пов'язаних федеративними відносинами. На рис. 3 дан приклад зіставлення заявок в політиці довіри партнера по ресурсам.
Мал. 3. Зіставлення заяв
Деякі зіставлення занадто мінливі, щоб їх можна було уявити у вигляді статичного зіставлення в політиці довіри. Припустимо, що партнеру по ресурсам потрібно заяву під назвою «IsOfLegalVotingAge», щоб упевнитися, що кому-то вже виповнилося 18 років, але ви знаєте лише дату народження користувача у вигляді нестандартного заяви від Active Directory. Значить, вам потрібен модуль перетворення заяв, який є збіркою, де реалізовано керований клас IClaimTransform. Ви можете прив'язати його до вашої політики довіри у вікні властивостей політики довіри (рис. 4). Цей модуль викликається двічі: один раз перед тим, як відбувається звичайне зіставлення політики довіри, і один раз після цього, що дозволяє виконати якусь пре- або постпроцессную обробку. Кожна політика довіри ADFS дає можливість встановити такий модуль, а значить, динамічне перетворення заяв можна виконувати як на стороні партнера по облікових записів, так і на стороні партнера по ресурсам.
Мал. 4. Модуль перетворення заяв
Звідки надходять заявки?
Поки ви не напишете свій модуль перетворення заяв, динамічно генерує заяви, всі ваші заяви будуть надходити зі сховища облікових записів, яким може бути або Active Directory, або ADAM (Active Directory Application Mode) - сервер «полегшеного» каталогу, заснований на кодової базі Active Directory. Працюючи зі сховищем облікових записів Active Directory, ви можете відобразити заяви груп на одну або більше груп в Active Directory; в сховище ADAM ви повинні надати назву атрибута для об'єкта користувача і значення, за яким можна буде з'ясувати, чи потрібно надсилати заяву групи для даного користувача. Кожне нестандартне заяву або заяву ідентифікації відображається безпосередньо на один атрибут об'єкта користувача в каталозі.
Принадність такої схеми в тому, що для інтеграції з партнерами адміністратор може використовувати ідентифікаційні дані, вже наявні в каталозі компанії, і в багатьох випадках писати код не потрібно.
анонімність
У системах на основі заяв є одна дуже цікава річ - часто взагалі немає потреби посилати ім'я користувача. Можливо, партнера цікавить лише одне: чи дійсно користувач уповноважений на даний запит. Але для партнера нерідко дуже зручно мати хоча б якийсь ідентифікує описатель, з якого він може отримати дані персоналізації або інший стан для користувача.
Щоб підтримати цей анонімний режим роботи, є спеціальне вбудоване перетворення для заяв ідентифікації - поліпшений захист ідентифікації (enhanced identity privacy). Якщо ви є партнером по облікових записів і хочете, щоб ваші користувачі залишалися анонімними при роботі з певним партнером по ресурсам, просто включите цю функцію для даного партнера у вашій політиці довіри, і, замість того щоб побачити ім'я користувача:
Щоб згенерувати цей описувач (handle), служба федерації створює хеш-значення з фактичного заяви ідентифікації, URI партнера по ресурсам і якогось значення, відомого тільки вашій службі федерації (в термінології ADFS це називають «ключем конфіденційності»). Завдяки включенню URI партнера описатели є різними для кожного партнера по ресурсам, що перешкоджає можливості скласти досьє на певного користувача. Ключ конфіденційності додається, щоб утруднити атаки по словнику.
Незважаючи на захист ідентифікації від партнера по ресурсам, її все ж можна простежити. Якщо потрібно визначити чиюсь ідентифікацію, її можна знайти в файлі журналу використання ресурсів і передати адміністратору партнера по облікових записів, який може використовувати журнали подій облікових записів, щоб визначити, який саме користувач отримав цю ідентифікацію.
Проксі служби федерації
Причина такого поділу в тому, що клієнтський інтерфейс (служба входу) може розміщуватися на периметрі мережі (який часто називають DMZ, демілітаризованою зоною) і взаємодіяли з серверної частиною служби федерації через веб-сервіс ASMX, що працює у внутрішній мережі. У такій конфігурації клієнтський інтерфейс називається проксі служби федерації.
Чи розділить ваш адміністратор службу федерації, використовуючи проксі на окремій машині, великого значення не має, але в будь-якому випадку корисно знати, що ADFS здатна працювати в DMZ.
Включення в веб-додатки підтримки ADFS
Якщо перед вами стоїть завдання створити веб-додаток, що підтримує вхід через ADFS, вам потрібно зробити кілька речей. Від вас буде потрібно налаштувати свій файл web.config так, щоб завантажувати і конфігурувати веб-агент ADFS. У лістингу 1 показаний файл web.config, який я використовував при підготовці прикладу додатки для цієї статті.
Лістинг 1. Приклад web.config
Налаштувавши файл web.config, ви зможете отримувати дані для входу в систему від ваших ADFS-партнерів по облікових записів. Наступним кроком буде прийняття рішень по організації безпеки на основі заяв.
Якщо ви хочете працювати за схемою федерації, вам потрібно створити додаток, яке розуміє заяви, і при цьому ви не зможете покластися на механізм уособлення (impersonation), так як у вас не буде облікового запису домену Windows, що представляє користувачів ваших партнерів по облікових записів. Ви будете мати справу з веб-агентом, яка не робить ніяких зіставлень з обліковими записами Windows, а передає вам надходять заяви через властивість HttpContext.User. Цей підхід я і застосував у своєму прикладі.
Написати код для перевірки заяв неважко. Насправді, якщо ви в основному покладаєтеся на заяви груп, вам взагалі не потрібно особливо думати про заяви. Просто продовжуйте використовувати HttpContext.User.IsInRole, щоб перевіряти наявність або відсутність таких заяв, розглядаючи їх як ролі додатка. Тобто ви можете використовувати такі елементи управління ASP.NET, як LoginView, які працюють на основі ролей, отриманих через властивість HttpContext.User.
Якщо ви хочете отримувати значення нестандартних заяв, вам знадобиться трохи коду. У цьому фрагменті коду виконується пошук заяви Title:
Іншим цікавим властивістю є AuthenticatingAuthority - URI партнера по облікових записів, який аутентифицироваться даного клієнта. Завжди корисно наявність кнопки Log Off, і тут вам стане в нагоді властивість SignOutUrl.
Додаток-приклад для цієї статті формує таблицю за значеннями всіх відкритих властивостей SingleSignOnIdentity, як показано на рис. 5. Воно також отримує набір властивостей, які стосуються захисту, який показує всі надіслані заяви в їх початковому вигляді. Але, перш ніж запустити цю програму, вам потрібно встановити ADFS.
Лабораторна робота з ADFS
Там же знаходиться і додаток-приклад, включаючи файл конфігурації, який можна використовувати при тестуванні. Просто скопіюйте файли default.aspx і web.config в віртуальний каталог на образі партнера по ресурсам; після цього ви зможете увійти в систему з комп'ютера-клієнта і вказати в своєму браузері веб-додаток партнера по ресурсам, в яке ви хочете увійти.
Показ: успадкувала Захищений