Имперсонация и делегирование в ASP.NET

(ASP.NET delegation and impersonation)

Эта тема будет интересна тем, кто разрабатывает многоуровневые корпоративные .Net приложения. Вот такая узкая и скучная тема.

SSO - Single Sign On

Итак, те самые парни, о которых я сказал выше, всегда озабочены тем, чтобы пользователям не приходилось постоянно вводить логин / пароль при входе в различные приложения. Потому что пользователи грамотные, и они хотят чтобы «один раз ввели пароль при входе в windows, и он потом везде использовался». И я их в этом целиком и полностью поддерживаю. Когда у нас есть такая замечательная вещь, как Windows Integrated Authentication, мы несомненно должны ее использовать. Но это еще не все. В ASP.NET существуют такие мощные механизмы, как имперсонация (impersonation) и делегирование (delegation), о которых я хочу поговорить. Но прежде, давайте рассмотрим, каким образом .net web приложения исполняются под IIS.

Процессная модель IIS

Как известно на одном сервере 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" />

Кроме того, вам необходимо в свойствах web каталога в консоли IIS включить режим “Integrated Windows Authentication” (вкладка “Directory security”).
Теперь в коде aspx страницы мы можем узнать текущего пользователя вот так:

Context.User.Identity.Name

Либо вот так, результат будет аналогичный:

Thread.CurrentPrincipal.Identity.Name

Теперь мы, к примеру, можем узнать, состоит ли данный пользователь в той или иной группе:

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

Кроме того, все обращения к ресурсам, которые требуют авторизации (NTFS, реестр, Event Log и т.д.) будут производиться от имени пользователя пославшего web запрос.
Вот, пожалуй, и все об имперсонации в ASP.NET, более подробные сведения можно почерпнуть в MSDN. Однако у этой темы есть интересное продолжение - это механизм делегирования.

Делегирование

Рассмотрим, к примеру, систему, в которой различные уровни (tiers) разнесены по разным физическим серверам (см. рисунок).

Имеется 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>  

Это означает, что должна использоваться Windows аутентификация, имперсонация должна быть включена, и анонимный доступ запрещен. Кроме того, следует в свойствах web каталога приложения на вкладке “Directory Security” следует включить флаг “Integrated Windows authentication”.
Теперь если вы разместите на aspx странице вот вакой код вызова web сервиса:

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

Вы задействуете механизм делегации. CredentialCache.DefaultCredentials вернет удостоверения (credentials) клиента вызвавшего aspx страницу и эти удостоверения будут переданы при вызове метода Ask() web сервиса.
Здесь я изложил в самой краткой форме суть понятий имперсонации и делегирования в ASP.NET, а также то, как они могут быть использованы и как настроить environment для их использования. Однако тема далеко не исчерпана. Существуют различные сценарии использования делегирования. Существуют сценарии, когда делегирования надо избежать. Существует масса нюансов при настройке серверов и приложений для делегирования.
Для тех, кто обладает пытливым умом, либо просто заинтересовался данным вопросом, пара ссылок по теме:
How to configure an ASP.NET application for a delegation scenario
Troubleshooting Kerberos Delegation