Дополнение к докладу Windows Server 2012 Claims-based authentication.

Автор Михаил Пилинога

В ответ на заслуженную критику (слабо отражено, что такое  утверждения вообще и для чего они нужны) публикую это пропущенное вступление здесь.

«…

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

В мире без межсетевых экранов (firewall) можно было бы обойтись давно существовавшими технологиями (NTLM, Kerberos,Integrated Windows Authentication, DACL, SACL и т.д.). Но в реальном мире не все наши клиенты имеют учетные записи в нашем или доверенном лесах Active Directory. Иногда они вообще не имеют таких учетных записей. К тому же, в билет Kerberos не вставишь дополнительную информацию (адрес электронной почты начальника клиента, например).

Утверждения (claim) разработаны специально для предоставления гибкости, недоступной другим протоколам. Их возможности ограничены только воображением разработчиков и политиками отдела ИТ. В проект сразу закладывалась способность пересекать межсетевые экраны, границы доменов и аппаратных платформ.

Если вы не можете использовать доменные учетные записи, вам придется реализовывать свои механизмы проверки подлинности (включая создание учетных записей, их удаление, смену пароля, сброс пароля и т.п.). Концепция утверждений отделяет аутентификацию от приложения.

 Утверждение (Claim) — это утверждение (простите за тавтологию), которое одна сторона (issuer — поставщик, эмитент) делает о второй стороне (client) для третьей стороны (application — приложение).

Это утверждение может передавать только часть информации о клиенте (например, не указывать его имени, но подтверждать, что он входит в категорию Друзья).

 Небольшое отступление (примеры использования утверждений в обычной жизни).
1. Пассажир подходит в стойке в аэропорту, показывает паспорт и билет.
   После проверки он получает посадочный талон,   по которому дальше
   проходит в самолет.
2. Посетитель режимного объекта предъявляет паспорт в бюро пропусков.
   Охранник смотрит в журнал заявок (или звонит кому-то по телефону),
   а затем выдает временный пропуск (жетон, карту-ключ и т.п.).
   Дальше посетитель прячет паспорт и пользуется пропуском.

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

1) поставщик знал, для какого приложения предназначается маркер безопасности (security token) и включил в него необходимые утверждения;

2) поставщик зашифровал маркер собственным секретным (private) ключом;

3) для защиты от перехвата маркера злоумышленником поставщик может дополнительно зашифровать маркер открытым (public) ключом получателя маркера;

4) клиент включает полученный маркер безопасности приложению.

Но зачем все создавать с нуля, если есть уже готовые технологии.

 Вариант 1. Пассивный клиент (клиент на основе web-браузера)

При этом подходе клиент сначала обращается на web-страницу приложения. Неаутентифицированный запрос перенаправляется на страницу аутентификации у поставщика утверждений. (Это похоже на Forms-based authentification, но отличие должно стать понятно из последующего описания). Клиент подключается к login-странице и проходит там аутентификацию, причем это может быть и Integrated Windows Authentication, в этом случае клиент даже не получит запроса имени и пароля. При Basic-аутентификации браузер выведет свое окно ввода реквизитов, возможны и другие механизмы.

При переадресации поставщику передаются среди прочих два атрибута:

1) действие (action): wa=wsignin1.0 (другий вариант wsignout1.0 при выходе);

2) домен назначения (target realm): wtrealm=http://www.DomainName.com/ApplicationName/

Именно отсюда поставщик узнает, какие утверждения нужно включить в маркер. Построенный маркер передается клиенту в автоматически сгенерированной странице. Страница имеет вид формы с кнопкой, действие Submit которой возвращает клиента на сайт приложения. Но в этом новом запросе на сайт приложения уже будет присутствовать маркер безопасности, и клиент получит доступ. Обычно в коде страницы присутствует Java-скрипт, нажимающий эту кнопку, и клиент может даже ничего и не заметить. Но если скрипты отключены, то кнопочку придется нажать. Для оптимизации работы на время сессии используются cookie.

 Вариант 2. Активный клиент (Smart client)

Используется протокол WS-Trust для получения маркера безопасности и протокол WS-Security для передачи полученного маркера приложению:

1. Клиент получает от приложения WSDL-документ (WSDL — Web Service Definition Language). Из этого документа клиент может извлечь список доверенных поставщиков маркеров безопасности.

2. Клиент обращается к поставщику и в заголовке WS-Trust-запроса передает ему атрибут AppliesTo, включив в него URI приложения.

3. Поставщик возвращает маркер безопасности с необходимыми утверждениями.

4. Клиент отправляет запрос в web-службу, включив этот маркер в заголовок <Security>.

 Вариант 0. Claims-based Autentification в Windows Server 2012.

Конечно, здесь нет всего того богатства, которое есть в теории. В качестве утверждений можно использовать только атрибуты из Active Directory, причем только те, которые есть у объектов некоторых классов (user и т.п.). Зато эти утверждения можно включать в условия в ACE-записи в DACL и SACL).