Лекція 17. Microsoft .Net Access Services. Ідентифікація на основі тверджень
Як уже згадувалося в попередніх лекція, .Net Access Control Services забезпечує управління доступом до додатків і сервісів і інтеграцію з наявними у замовника засобами авторизації. Підтримуються стандартні механізми аутентифікації (наприклад Windows Live ID, Active Directory). Основою сервісу Access Control є Windows Identity Foundation.
З .Net Access Control Services "хмарні" і локальні додатки можуть об'єднуватися (в т.зв. федерації) і дозволяє використовувати сервіси через firewall. Azure - додаток використовує ту ж систему безпеки каталогів, що і Active Directory, тобто додаток буде вважати, що обліковий запис користувача управляється локально.
Ми не будемо детально торкатися питання про основи ідентифікації та авторизації та їх важливості. Відзначимо тільки парадокс: незважаючи на те, що завдання забезпечення безпеки ніколи не втрачає актуальності і, по суті, будь-який додаток починає роботу з ідентифікації користувача і визначення меж його дій, рідко дана задача розглядається докладно в навчальних курсах.
Основною метою даної лекції є знайомство з ідентифікацією на основі тверджень.
Ідентифікація на основі утвердження
Особливістю ідентифікації на основі тверджень є централізована реалізація сервісів аутентифікації і авторизації поза локальної інфраструктури, поза організації. Власне, саме ці сервіси і надає .Net Access Control.
При реалізації даного виду ідентифікації, користувач передає додатком набір тверджень, якими можуть бути ім'я, посаду, e-mail і т.д. Самі затвердження надаються службою сертифікації, аутентифицирующей користувача. Таким чином, додаток отримує всі необхідні дані, при цьому клієнтську програму (наприклад, браузер), взаємодіючи зі службою сертифікації, підтверджує передані затвердження.
Для забезпечення заявленого, додатки використовують SAML (Security Assertion Markup Language). Твердження передаються SAML - маркерами, кожен маркер несе частину інформації про користувача. Маркери генеруються STS - програмою.
STS (security token service), або сервіс маркерів доступу - створює, підписує і видає маркери доступу. STS приймає запити на отримання маркера (RST - request for token) і повертає відповідь (RSTR).
По суті, STS є елементом служби сертифікації.
Однак, не все так просто, як здається на перший погляд. SAML маркер може не містити тверджень, очікуваних додатком і сервіс, що генерує маркером може не бути довіреною, з точки зору програми. Для вирішення цієї проблеми в процес ідентифікації втягується ще один STS - сервіс, який гарантує, що SAML - маркери будуть містити всю необхідну інформацію. При цьому, .Net Access Control Services, використовую федеративні механізми, встановлює довірену зв'язок між новим STS і сервісом, генеруючим маркери.
Мал. 24.1 показує, як .Net Access Control Services забезпечує перетворення тверджень і федеративну ідентифікацію.
1. На першому етапі клієнт знайомиться з політикою додатки, тобто куди необхідно звертатися для аутентифікації.
2. Генерується запит на отримання SAML - маркера до STS службам, що формує маркери на основі ряду правил.
3. Маркер передається клієнту.
4. Маркер віддається додатком. Додаток приймає тільки маркери підписані службою сертифікації, все інші маркери відхиляються.
На малюнку 24.1 на стороні користувача мається на увазі наявність Smart - клієнта, що генерує запити до STS і взаємодіючі з додатком. У разі використання користувачем браузера, при зверненні до веб - додатку, що використовує ідентифікацію на основі тверджень, кроки процесу ідентифікації будуть наступними:
1. Користувач посилає HTTP - запит веб - додатку.
2. Додаток, оскільки користувач не зареєстрований, перенаправляє його на веб - сторінку, яка надається довіреній службою сертифікації.
3. Служба сертифікації управляє процесом аутентифікації користувача.
4. Після аутентифікації службою сертифікації визначаються необхідні затвердження і формується SAML - маркер.
5. SAML - маркер включається до складу відповіді з java - сценарієм.
6. Сценарій, повернувшись браузеру користувача, передає маркер веб - додатку через POST - запит.
Рис. 24.1.
Використовувані стандарти
Можливість взаємодії всіх цих елементів забезпечується кількома WS -Стандарти (див п.№8 списку матеріалів для самостійного вивчення).
WSDL витягується за допомогою WS-MetadataExchange або простого HTTP-запиту GET, і політика в WSDL структурована відповідно специфікації WS-Policy.
STS служби сертифікації надають кінцеву точку, що реалізує специфікацію WS-Trust, яка описує процеси запиту і отримання маркерів доступу.
SAML - словник XML, який може використовуватися для подання тверджень у формі, що забезпечує можливість взаємодії.
Список матеріалів для самостійного вивчення
Ідентифікація та авторизація користувачів
1. http://articles.security-bridge.com/articles/91/11658/
2. http://www.intuit.ru/department/security/secbasics/10/
.Net Access Control Services
1. http://www.techbubbles.com/microsoft/net-access-control-service/
2. http://msdn.microsoft.com/ru-ru/library/ee872415.aspx
Ідентифікація на основі тверджень
1. http://msdn.microsoft.com/ru-ru/library/ee539091.aspx
SAML
1. http://www.ccc.ru/magazine/depot/04_02/read.html?0501.htm
2. http://www.pingidentity.com/knowledge-center/SAML-Tutorials-and-Resources.cfm
WS - стандарти
1. http://www.ccc.ru/magazine/depot/06_10/read.html?0202.htm
2. WSDL
3. http://xmlhack.ru/texts/03/wsdl.tales/wsdlintralook1.html
(Для ознайомлення з повним текстом статті необхідно залогінитись)