проф. В.К.Толстых, WCF-службы Понятие безопасности Из цикла лекций «Internet-технологии разработки приложений» для студентов 4-го курса кафедры Компьютерных технологий физического факультета Донецкого национального университета проф. В. К. Толстых

Обеспечение безопасности в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-кодом службы и распространяется по всем прокси-клиентам. При связи со службой клиент сравнивает её удостоверение с имеющимся действительным значением. Если значения совпадают, значит клиент связался с ожидаемой конечной точкой службы.Identity EndpointAddress Клиент получает такое же значение свойства identity. DNS-имя удостоверения (сертификат X.509 или учётная запись Windows). Здесь имя сертификата совпадает с именем хоста. WCF автоматически принимает сертификат сервера.

Безопасность передачи Выбор правила режима безопасности передачи является самым главным решением при защите службы. Необходимо обеспечить целостность сообщения, его конфиденциальность и взаимную аутентификацию клиента и сервера. Последнее должно предотвращать атаки замещения (злоумышленное повторное использование допустимого сообщения) и атаки на отказ в обслуживании (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.

Примеры настройки безопасности

Поведения (behaviors) безопасности Поведения безопасности позволяют сервисам управлять учетными данными, проверкой подлинности, авторизацией и журналами аудита. Пример конфигурирования: ... Аутентификация пользователей. В примере – через MembershipProvider в пользовательской БД Авторизация групп пользователей через роли "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. – СПб.: Питер, – 592 с.: ил.