Сразу оговорюсь, что рассматриваемые подходы ни в коем случае не претендуют на истину в последней инстанции и в конкретных условиях могут быть использованы другие решения.

Итак, будем исходить из следующих предпосылок в нашем сценарии:

1. Приложение используется внутри корпоративной сети
2. Пользователи приложения имеют учетные записи Windows
3. Уровень компонент бизнес логики вынесен на сервер приложений, т.е. приложение построено в трехуровневой модели
4. С системой работают только аутентифицированные пользователи и основная авторизация происходит на уровне бизнес компонент
5. Пользовательский интерфейс может быть решен в виде GUI приложений и в виде тонкого Web клиента
6. SQL сервер используется для хранения данных.

Протокол взаимодействия уровня пользовательского интерфейса и уровня бизнес компонент

Прежде чем перейти к рассмотрению механизмов аутентификации и авторизации, необходимо определиться с протоколами взаимодействия уровней нашей системы. При разработке с использованием .NET Framework у нас есть две основные возможности организации удаленного взаимодействия объектов - .NET Remoting и Web Services. Не останавливаясь на подробном анализе этих двух подходов, выберем SOAP в качестве протокола взаимодействия компонент бизнес-логики с уровнем пользовательского интерфейса. Естественным образом для такого сценария в качестве Сервера Приложений будет выступать Internet Information Server (IIS) в совокупности с технологиями ASP.NET, Web Services и Enterprise Services.

Такой подход позволит:

• Использовать одни и те же интерфейсы для взаимодействия различных типов клиентов с сервером приложений
• При необходимости использовать возможности взаимодействия по SOAP поверх HTTP при разнесении уровней приложения через Firewall
• Обеспечить возможность интеграции сервера приложений с другими системами, в том числе и реализованными на других программных платформах
• В дальнейшем использовать серверы интеграции приложений для увязывания различных подсистем в сложных сценариях взаимодействий

Аутентификация и авторизация

• избежать передачи идентифицирующих данных по каналам связи в незащищенном виде
• использовать встроенные механизмы операционной системы для проверки идентичности пользователя
• централизовать управление правами пользователей системы
• использовать стандартные административные средства для управления пользователями

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if ( wp.IsInRole("PowerUser") )
{
  // пользователь авторизован и включен в роль PowerUser
}

Модуль FileAuthorizationModule осуществляет проверки ACL по отношению к оригинальному вызывающему для типов файлов, которые отображены в IIS для aspnet_isapi.dll фильтра. Для статических файлов, таких как .jpg, .gif и .htm , IIS осуществляет проверку доступа, используя идентити оригинального вызывающего пользователя. Вы должны обеспечить достаточное гранулирование Windows групп в соответствие с потребностями системы безопасности. Безопасность, основанная на .NET ролях, определяет принадлежность пользователя к роли по его вхождению в Windows группу. Windows группа, используемая для управления ролями, может быть локальной для этого компьютера или группой домена.

Соединение с базой данных

Транзакции на однородных источниках ( в рамках одной базы данных) могут реализованы через обращение к соответствующим классам .NET Framework. При необходимости использования распределенных транзакций при взаимодействии с внешними приложениями могут быть использованы службы COM+ приложений и координатор распределенных транзакций (DTC) . В этом случае .NET компоненты должны использовать классы Enterprise Services и устанавливаться в COM+ приложения.

Поддержка пула соединений с базой данных осуществляется провайдером доступа к SQL серверу. Пул соединений поддерживается на уровне пользователя в системе. Поэтому для его использования необходимо придерживаться подхода установления доверительного отношения между сервером приложений и сервером баз данных. При таком подходе сервер приложений аутентифицируется на сервере баз данных под одной учетной записью. Это в целом соответствует нашему сценарию, когда основная авторизация пользователей осуществляется на уровне сервера приложений, а не на уровне баз данных. При необходимости авторизации пользователей системы на уровне сервера баз данных информация об аутентифицированном пользователе будет передаваться на уровне логики приложения - через параметры вызываемых хранимых процедур, параметры Transact SQL запросов.

Для обеспечения такого соединения с базой данных будем использовать режим интегрированной аутентификации в SQL Server и одну учетную запись в Windows. Режим интегрированной аутентификации в SQL Server позволит избежать хранения в строке соединения учетных данных.

Примечание

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

Общая схема реализации системы безопасности

Аутентификация

• Пользователь аутентифицируется через вход в Windows домен (1).
• IIS осуществляет интегрированную Windows аутентификацию (2)
• Web Service использует Windows аутентификацию, предоставляемую ASP.NET, без имперсонации, В этом случае просто используется контекст безопасности, предоставляемый IIS аутентификацией (3)
• Из Web Service уровень бизнес логики через вызов .NET компонент использует соединение с Базой Данных с интегрированной Windows аутентификацией (4)
• Сервер приложений ( Web Service) осуществляет запрос к Базе Данных под единой доверительной учетной записью. Под этой же учетной записью выполняется ASPNET процесс на сервере приложений. (5)

Авторизация

• Ресурсы в каталоге Web приложения, содержащего Web Services уровня бизнес логики, конфигурируются через Списки Управления Доступом (ACL) по отношению к пользователю, вызывающему слой бизнес логики из клиентского приложения (2)
• Web Service осуществляет авторизацию по отношению к контексту безопасности оригинального вызывающего пользователя по .NET ролям для ограничения доступа к тем или иным методам Web Services или объектам уровня бизнес логики. В случае c Windows аутентификаций в ASP.NET Web Service .NET роли отображаются в Windows группы. (3)

Защита каналов данных

• При необходимости можно обезопасить канал данных между клиентским приложением и сервером приложений (6) с использованием HTTPS
• При необходимости можно обезопасить канал данных между сервером приложений и сервером баз данных (7) с использованием Internet Protocol Security (IPSec) (См. Step-by-Step Guide to Internet Protocol Security )

Конфигурирование подсистем безопасности

Примечания

1. Для организации соединения с базой данных мы использовали две локальные учетные записи с одинаковыми credentials - на сервере приложений и на сервере баз данных. Управление двумя учетными записями несет дополнительную нагрузку при администрировании системы. Выходом может быть создание одной непривилегированной доменной учетной записи и использование ее на обоих серверах. Но при таком подходе придется указать имя доменного пользователя в атрибуте user . ASPNET_WP.EXE будет запускаться под этим пользователем и ему необходимо предоставить права для выполнений ASP.NET приложений.
2. ASP.NET приложение, реализующее Web Service, запускается в нашем сценарии без имперсонации, т.е. из под непривилегированной учетной записи ASPNET с минимумом требуемых привилегий. Это понижает потенциальный ущерб при прорыве систем безопасности.
3. При вызове из клиентского приложения методов Web Service по протоколу SOAP в случае NTLM аутентификации будем наблюдать передачу двух HTTP запросов на каждый вызов метода. Этого невозможно избежать по причине механизмов работы NTLM протокола. Это может вызывать существенные задержки при общении слоя представления данных со слоем бизнес логики. Избежать посылки двух HTTP запросов можно только при использовании Kerberos протокола. Выбор NTLM или Kerberos протокола при интегрированной аутентификации зависит от настроек конфигурации на сервере и на клиенте. В случае использования Kerberos протокола для посылки Credentials в первом запросе необходимо выставить на Proxy объекте следующие свойства:

    

   proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
   proxy.PreAuthenticate = true;
   

4. На IIS 5.x всегда запускается один экземпляр ASPNET_WP.EXE процесса и установки для ASP.NET учетной записи конфигурируются на уровне всей машины (в machine.config). Это может быть неудобным, когда на одном IIS сервере мы хостим несколько Web приложений/Web Services c разными настройками для ASPNET пользователя. Хорошей новостью является то, что в Everett (следующая версия .NET Framework и Visual Studio.NET) и IIS6.0 данный недостаток будет ликвидирован.
5. Мы храним пароль для ASPNET учетной записи в machine.config в открытом виде. И хотя напрямую из web приложений нет доступа к конфигурационным файлам, это является потенциальной слабостью нашей системы безопасности. В Everett будет реализована возможность использования Win32 Data Protection API (DPAPI) для работы с конфигурационными файлами на уровне ASP.NET.

Использование COM+ служб

Для доступа к другим ресурсам системы (например, факс сервер стороннего производителя, дополнительный сервис и т.п.) может потребоваться имперсонация под специализированным пользователем. Использование Logon API внутри ASP.NET приложения для имперсонации ASPNET_PW.EXE процесса под другой учетной записью является нецелесообразным, поскольку мы должны будем дать ASPNET учетной записи право "act as part of operating system", что потенциально ослабляет систему безопасности. (хорошим правилом является назначение минимума необходимых прав любому объекту в системе)

Мы можем решить, передавать или не передавать контекст пользователя до COM+ приложения. Если нам не нужно проводить дополнительной авторизации пользователя на уровне COM+ приложения, то контекст передавать не будем и обращение к COM+ приложению будет осуществляться из под ASPNET пользователя (не забывайте - мы не используем имперсонацию на уровне ASP.NET и наше ASP.NET приложение выполняется под ASPNET учетной записью).

Если мы захотим передавать контекст пользователя до COM+ приложения, то нам придется включить имперсонацию в ASP.NET приложении через изменение Web.config:

<identity impersonate="true">

<processModel 
    comImpersonationLevel="Impersonate"

Такой подход может так же быть использован, когда необходимо обеспечить доступ к различным источникам данных в SQL Server в пределах одного приложения и, соответственно, предоставлять различные Credentials для доступа к этим источникам.

Заключение

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

• ресурсы, требующие защиты на уровне приложения
• уровни приложения, на которых будет осуществляться аутентификация и авторизация пользователя
• применяемые механизмы аутентификации и авторизации
• использование собственных или доступных на уровне операционной системы механизмов
• определение пользователей (объектов) по отношению, к которым работает система безопасности приложения
• гранулированность (степень детализации) при авторизации
• передача идентити пользователя между уровнями приложения (делегирование)
• выполнение обращений от имени идентити (имперсонация) на разных уровнях приложения
• взаимодействие уровня бизнес логики с внешними приложениями/службами
• защита каналов передачи данных