Имперсонация и делегирование в ASP.NET (ASP.NET delegation and impersonation)

Источник: http://stump-workshop.blogspot.com/ Автор Sergey Rozovik

Как известно на одном сервере IIS могут быть развернуто несколько web сайтов (только не под XP и IIS5), а на каждом сайте может выполняться несколько web приложений. Причем это могут быть разные приложения: .Net, ISAPI или скриптовые. Мы будем говорить только о .Net приложениях. Для .Net приложения нужен хост. И поэтому IIS запускает специальный серверный процесс, который служит хостом для CLR. В случае IIS 5 этот процесс называется aspnet_wp.exe, а IIS6 использует процесс w3wp.exe. В этом рабочем процессе и создаются домены приложений (AppDomain) для .Net web приложений. Каждое web приложение исполняется в своем AppDomain. Когда приложение завершается соответствующий AppDomain выгружается. Рабочий процесс IIS исполняется под определенной учетной записью. Для IIS5 это может быть локальная учетная запись ASPNET или SYSTEM. Настраивается это в файле machine.config в секции (непосредственно в секции есть обширный комментарий на эту тему). Кроме этих зарезервированных значений в machine.config можно указать любую другую локальную или доменную учетную запись для рабочего процесса IIS. В IIS6 настройка более гибкая. Производится она в MMC консоли IIS. Там можно создать несколько Application Pools, и для каждого указать свои настройки, в том числе и учетную запись. После этого каждому web приложению можно указать, в каком пуле оно должно выполняться. По умолчанию все приложения выполняются в DefaultAppPool под учетной записью Network Service. Физически для каждого Application Pool запускается свой рабочий процесс w3wp.exe.

То, под какой учетной записью выполняется рабочий процесс, оказывает очень большое влияние на поведение web приложения. Существует масса ресурсов, при доступе к которым осуществляется проверка полномочий учетной записи. К таким ресурсам относятся объекты файловой системы NTFS (файлы и каталоги), реестр, EventLog, базы данных и многое другое. Вот это, пожалуй тот минимум, который нам надо знать о рабочих процессах и их учетных записях для того, чтобы мы могли продолжать наш разговор. А вообще это тема необъятная, взять, к примеру, вопросы, связанные с масштабированием приложений под IIS. Интересующихся, я отсылаю к MSDN.

При разработке web приложений встречаются разные ситуации. Иногда нам надо «абстрагироваться» от того, кто инициировал вызов данного кода web приложения, и тогда нам надо использовать учетную запись рабочего процесса. Но встречаются противоположенные ситуации, когда нам необходимо знать, какой пользователь инициировал выполнение серверного кода, и на основании этого принимать решение, имеет ли он право доступа к тому или иному ресурсу, либо вообще, может ли он исполнять данный код. Вот такую задачу и решает встроенный в ASP.NET механизм имперсонации (impersonation). В русском переводе его иногда называют «олицетворением», но те кто давно читают MSDN Russian Edition, знают, что данный термин как то не прижился в сообществе разработчиков.

Всем, наверное, известно, что для обработки запроса пользователя IIS выделяет отдельный поток из пула потоков, и в дальнейшем весь серверный код выполняется в этом потоке. Механизм имперсонации ASP.NET позволяет исполнять код на сервере «от имени» клиента. По умолчанию имперсонация выключена. Для того, чтобы включить механизм имперсонации для web приложения необходимо поместить в секцию его web.config следующий тэг:
 

<identity impersonate="true" />

Context.User.Identity.Name

Thread.CurrentPrincipal.Identity.Name

System.Threading.Thread.CurrentPrincipal.IsInRole("Power Users");

Имеется Front-end server на котором размещены aspx страницы с UI и имеется Back-end server с бизнес логикой. Front-end сервер общается с Back-end сервером посредством вызова его web сервисов. То есть, клиент заходит на aspx страничку, которая расположена на Front-end сервере. В коде aspx странички есть вызов web сервиса, который расположен на Back-end сервере. Если на Front-end сервере у нас включен режим имперсонации, то серверный код aspx страницы выполняется под учетной записью клиента. Было бы здорово, если бы учетные данные клиента передались и на Back-end сервер с вызовом web сервиса, и в результате там тоже сработала имперсонация. И такая возможность у нас есть! Реализуется она при помощи механизма делегирования.
Делегирование в ASP.NET базируется на использовании аутентификации по протоколу Kerberos, который позволяет аутентифицировать не только клиента но и сервер, к которому обращается клиент. Вообще, Kerberos достаточно сложная штука. Однако нам не надо досконально разбираться в деталях этого протокола, чтобы воспользоваться механизмом делегирования. Достаточно знать основные условия, необходимые для работы этого механизма.
Первое и главное, в сети должен использоваться протокол Kerberos. Это автоматически означает, что версия операционной системы должна быть не ниже Windows 2000 и в доменах должна быть установлена Active Directory.
Второе, браузер должен поддерживать протокол Kerberos. Это IE 5.0 и старше (в настройках необходимо включить опцию «Enable Integrated Windows Authentication»). Firefox тоже поддерживает Kerberos.
Далее, настройки сервера и web приложения для делегирования (Front-end server). Для сервера должна быть включена опция «Trust computer for delegation» (настраивается через оснастку MMC «Active Directory Users and Computers»). А для учетных записей пользователей в AD должен быть сброшен флаг «Account is sensitive and cannot be delegated» (настраивается там же).
В самом web приложении должны быть следующие настройки в файле web.config:
 

<identity impersonate="true" />
<authentication mode="Windows" /> 
<authorization>
    <deny users="?" /> 
</authorization>  

EchoService echo = new EchoService();
echo.Credentials = System.Net.CredentialCache.DefaultCredentials;
try
{
 lbAnswer.Text = echo.Ask(TextBox1.Text);
}
catch(Exception ex)
{
 lbAnswer.Text = ex.ToString();
}