WCF службы - Поняте безопасности

Из цикла лекций «Internet-технологии разработки приложений» для студентов 4-го курса
кафедры Компьютерных технологий физического факультета Донецкого национального университета
проф. В. К. Толстых
WCF-службы
Понятие безопасности
проф. В.К.Толстых,
www.tolstykh.com
Обеспечение безопасности вWCF
Традиционно безопасность сетевой информационной системы состоит из:
1. Аутентификация,
2. Авторизация пользователя на сервере и серверного приложения для клиента
(проверка подлинности службы),
3. Безопасность передачи сообщений,
4. Выбор идентичности (личности) от имени которой на сервере будут выполняться
операции,
5. Дополнительные меры безопасности в организации – общая политика
безопасности организации.
WCF поддерживает ряд механизмов аутентификации, безопасности передачи,
авторизации и идентичности. Необходимо выбрать подходящую привязку и
настроить её.
Рассмотрим подробнее…
Аутентификация
Аутентификацией называется процедура, которая выясняет, является ли вызывающая
сторона именно тем, за кого она себя выдаёт. WCF поддерживает ряд механизмов
аутентификации:
•
Без аутентификации – служба не проверяет от кого поступили вызовы. Обращение
разрешено практически любому желающему.
•
Аутентификация Windows – служба работает с удостоверениями клиента
(credentials) и проверяет их средствами Windows.
•
Имя пользователя и пароль – служба проверяет полученные имя и пароль по
некоторому источнику, например, по учётным записям Windows или по
пользовательской БД .
•
Сертификат X509 – клиент идентифицирует себя при помощи сертификата. Служба
обращается на сервере для подтверждения подлинности сертификата, а
следовательно и клиента. Служба также может автоматически доверять стороне
выдавшей сертификат.
•
Пользовательский механизм – WCF позволяет заменить механизм аутентификации
любым протоколом и типом удостоверений, например, биометрическими данными.
•
Выдача электронного ключа – например, Windows CardSpace.
Авторизация
Авторизация определяет какие действия разрешены вызывающей стороне, обычно –
какие операции службы разрешено вызывать клиенту. Авторизация бессмысленна
без аутентификации. Служба должна найти роль вызывающей стороны в своём
хранилище и убедиться в том, что вызывающая сторона принадлежит к
запрашиваемой роли.
WCF, аналогично ASP.NET, поддерживает несколько типов хранения авторизационных
удостоверений. Наиболее популярные – это:
1. Группы (учётные записи) Windows,
2. Провайдеры ASP.NET для хранения пользовательских учётных записей.
WCF позволяет идентифицировать и проверять подлинность службы для защиты от
фишинга. Удостоверение конечной точки службы (свойство Identity класса
EndpointAddress) генерируется WSDL-кодом службы и распространяется по всем
прокси-клиентам. При связи со службой клиент сравнивает её удостоверение с
имеющимся действительным значением. Если значения совпадают, значит клиент
связался с ожидаемой конечной точкой службы.
<endpoint...
<identity>
<dns value="localhost" />
</identity>
DNS-имя удостоверения (сертификат
X.509 или учётная запись Windows).
Здесь имя сертификата совпадает с
именем хоста. WCF автоматически
принимает сертификат сервера.
Клиент получает такое же значение свойства identity.
Безопасность передачи
Выбор правила режима безопасности передачи является самым главным решением при
защите службы. Необходимо обеспечить целостность сообщения, его
конфиденциальность и взаимную аутентификацию клиента и сервера. Последнее
должно предотвращать атаки замещения (злоумышленное повторное использование
допустимого сообщения) и атаки на отказ в обслуживании (DoS – фиктивные
сообщения высокой частоты для снижения доступа к службе).
Режимы передачи данных:
1. None – служба не получает удостоверение клиента, сообщения передаются открыто;
2. Transport – передача данных шифруется при HTTPS, TCP, IPC, MSMQ. Здесь
обеспечивается целостность и конфиденциальность данных. Взаимная
аутентификация реализуется шифрованием удостоверений (Credentials) клиента
вместе с содержимым. Это самый простой и производительный способ гарантии
безопасности при подключении клиента к службе без посредников;
3. Message – шифрование сообщения, обеспечивает конфиденциальность, целостность
и проверку подлинности на уровне сообщений SOAP (вместо транспортного уровня)
для небезопасных протоколов, таких как HTTP.
4. TransportWithMessageCredential – объединяет в себе два предыдущих режима.
Типы учётных данных клиентов
При установке того или иного режима передачи данных указывается и тип учётных
данных клиентов – clientCredentialType и, возможно, прокси –
proxyCredentialType при его использовании клиентом из домена через HTTP.
Возможные значения типов учётных данных клиентов:
1. None – без проверки подлинности клиента. Задаётся по умолчанию.
2. Basic – соответствует методу обычной проверки подлинности в IIS. При
использовании этого режима на сервере IIS должны быть настроены учетные
записи пользователей Windows и соответствующие разрешения файловой системы
NTFS.
3. Windows – проверка подлинности встроенной системой безопасности Windows в IIS.
При задании этого значения также предполагается, что сервер находится в домене
Windows, в котором для взаимодействия с контроллером домена используется
протокол Kerberos.
4. Certificate – в IIS предусмотрена функция, требующая, чтобы клиенты входили в
систему с использованием сертификата.
5. Digest – дайджест-проверка подлинности подобна обычной проверке, но учетные
данные передаются в виде хэша, а не открытого текста.
6. Ntlm – позволяет серверу использовать NTLM для проверки подлинности в случае
сбоя протокола Kerberos.
Примеры настройки безопасности
Режим безопасности <bindings>
Transport
<basicHttpBinding>
Тип учётной записи для
Transport - Windows
<binding name="wcfService"
<security mode="Transport">
<transport clientCredentialType="Windows"
proxyCredentialType="None" />
Проверка сертификата на
прокси не реализуется
</security>
...
Эту конфигурацию можно использовать для привязки basicHttpBinding, когда сервер
IIS и клиент находятся в одном домене Windows.
<bindings>
Режим безопасности Message
<WSHttpBinding>
Тип учётной записи для
Message - Windows
<binding name="wcfService"
<security mode="Message">
<message clientCredentialType="Windows" />
</security>
...
Эта конфигурация используется по умолчанию для безопасности сеансов в привязке
wsHttpBinding.
Поведения (behaviors) безопасности
Поведения безопасности позволяют сервисам управлять учетными данными, проверкой
подлинности, авторизацией и журналами аудита. Пример конфигурирования:
Аутентификация пользователей. В примере – через
<behavior name="...">
MembershipProvider в пользовательской БД
<serviceCredentials>
<userNameAuthentication userNamePasswordValidationMode=
"MembershipProvider"/>
</serviceCredentials>
<serviceAuthorization principalPermissionMode="UseAspNetRoles"
roleProviderName ="CustomRolesProvider" />
...
</behavior>
Авторизация групп пользователей через роли
"CustomRolesProvider" в пользовательской БД
Клиент передаёт пользовательские учётные данные в сервис через свой прокси:
proxy.ClientCredentials.UserName.UserName = "login";
proxy.ClientCredentials.UserName.Password = "PWD";
Сервис их получает как
ServiceSecurityContext ssc = ServiceSecurityContext.Current;
if (!ssc.IsAnonymous && ssc.PrimaryIdentity != null)
{string userName=ServiceSecurityContext.Current.PrimaryIdentity.Name;}
Для реализации данного механизма необходимо использовать сертификаты.
Личность и перевоплощение службы
Личность Windows (WindowsIdentity) – это учётная запись Windows или
электронный ключ с которым подключается клиент. При обслуживании запросов
клиентов хостовый процесс сервиса и его программные потоки запускаются
(выполняются) от системной учётной записи. Например, для IIS 7 – это Network
Service.
Перевоплощение позволяет службе запускаться от личности клиента. Например, это
может использоваться для авторизованного, персонального доступа к файловой
системе, SQL-серверу и т. д. Пример перевоплощения операции:
Public viod MyMethod()
{
using(ServiceSecurityContext.Current.WindowsIdentity.Impersonate())
{
}
}
//Работа с использованием личности клиента
Если при проектировании системы используется многоуровневая архитектура, то
каждый уровень работает под своей личностью. В тоже время, перевоплощение
требует передачи личности далее и далее, вплоть до низкоуровневых ресурсов.
Здесь количество ресурсов будет совпадать с количеством клиентов, что не всегда
верно и возможно.
Источники
•
Джувел Лёве. Создание служб Windows Communication Foundation. –
СПб.: Питер, 2008 . – 592 с.: ил.
•
http://msdn.microsoft.com