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 обеспечивает преобразование утверждений и федеративную идентификацию.

Рис. 24.1.

1. На первом шаге клиент знакомится с политикой приложения, т.е. куда необходимо обращаться для аутентификации.
2. Генерируется запрос на получения SAML - маркера к STS службам, формирующим маркеры на основе ряда правил.
3. Маркер передается клиенту.
4. Маркер предается приложению. Приложение принимает только маркеры подписанные службой сертификации, все иные маркеры отклоняются.

На рисунке 24.1 на стороне пользователя подразумевается наличие Smart - клиента, генерирующего запросы к STS и взаимодействующие с приложением. В случае использования пользователем браузера, при обращении к веб - приложению, использующим идентификацию на основе утверждений, шаги процесса идентификации будут следующими:

1. Пользователь посылает HTTP - запрос веб - приложению.
2. Приложение, поскольку пользователь не зарегистрирован, перенаправляет его на веб - страницу, предоставляемую доверенной службой сертификации.
3. Служба сертификации управляет процессом аутентификации пользователя.
4. После аутентификации службой сертификации определяются необходимые утверждения и формируется SAML - маркер.
5. SAML - маркер включается в состав ответа с java - сценарием.
6. Сценарий, вернувшись браузеру пользователя, передает маркер веб - приложению через POST - запрос.

Используемые стандарты

Возможность взаимодействия всех этих элементов обеспечивается несколькими 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
4. http://www.w3.org/TR/wsdl