Asp безопасность приложений iis

Содержание

работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0 (стр. 1 из 3)

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Построение веб-приложения на основе ASP.NET и архитектуры сервера IIS 7.0

Выполнил: студент 367 гр.

Введение

В настоящее время сложно переоценить роль интернета. Это одна из наиболее динамично развивающихся отраслей, даже в условиях кризиса.

А что такое интернет без веб страниц и, соответственно, веб серверов?

Сейчас на рынке можно достаточно большое количество самых разных веб серверов. Один из наиболее распространенных – это Internet Information Server корпорации Microsoft. Учитывая последние тенденции к комплексным решениям Microsoft выпустила IIS 7.0, дающий разработчикам и администраторам новые возможности при создании и управлении сайтами.

В своей работе я ознакомился с новыми возможностями и применил их на практике.

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

Задачи:

1. Изучить новые возможности IIS 7.0

2. Познакомится с ASP.NET

3. Написать модуль аутентификации

Теоретическая часть

Безопасность в сети необходима, особенно если дело касается денег. Злоумышленники прибегнут к всевозможным ухищрениям лишь бы добраться до номера вашего банковского счета, логина и пароля в интернет-магазине. Данный проект написан на C# с применением технологии ASP.NET неслучайно. Существует множество готовых решений и предусмотренных классов для обеспечения безопасности соединения. Microsoft предлагает комплексные решения для многих задач. Продукты этой фирмы используются почти всеми, как в корпоративной сети, так и в обычной жизни. Интересующая нас задача — это создание и сопровождение полноценных защищенных веб приложений, таких как интернет магазин например.

Для создания безопасного веб-приложения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.

Давайте рассмотрим поближе систему безопасности ASP.NET

Чтобы обеспечить безопасность веб-приложений, ASP.NET используется совместно с Microsoft .NET Framework и службами Microsoft Internet Information Services (IIS). Для создания безопасного приложения ASP.NET следует выполнить две основные функции:

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

· Авторизация (Ограничивает право доступа, предоставляя определенные разрешения или отказывая в них удостоверенной личности)

ASP.NET в сочетании со службами Microsoft Internet Information Services (IIS) может выполнять проверку подлинности учетных данных пользователя, например имен и паролей, используя любой из перечисленных ниже методов проверки подлинности:

· Windows: стандартная, шифрованная или встроенная проверка подлинности Windows (NTLM или Kerberos).

· Проверка подлинности в формах, в которых разработчик создает страницу входа и управляет проверкой подлинности в приложении.

· Проверка подлинности с помощью сертификатов клиента.

Рассмотрим Архитектуру безопасности ASP.NET

Рис.1 Архитектура безопасности ASP.NET

Как показано на рисунке, все веб-клиенты взаимодействуют с приложениями ASP.NET с помощью служб IIS. При необходимости IIS проверяет подлинность запроса и затем определяет местонахождение запрошенного ресурса (например, приложение ASP.NET). Если клиент авторизован, ему предоставляется доступ к этому ресурсу.

Во время выполнения приложение ASP.NET может использовать встроенные средства безопасности ASP.NET. Кроме того, в приложении ASP.NET могут использоваться средства безопасности платформы .NET Framework.

Два стандартных стандартных сценария обеспечения безопасности: олицетворение(проверка подлинности Windows) и проверки подлинности с помощью форм с использованием файлов «cookies».

Олицетворение

Рис.2 Олицетворение. На рисунке показана следующая последовательность событий:

1. Запрос поступает в службы IIS от клиента сети.

2. Службы IIS проверяют подлинность клиента, используя стандартную, шифрованную или встроенную безопасность Windows (NTLM или Kerberos).

3. Если клиент проходит проверку подлинности, службы IIS передают удостоверенный запрос в ASP.NET.

4. Приложение ASP.NET олицетворяет клиент, выполняющий запрос, используя лексему доступа, переданную из IIS, и использует разрешения NTFS-файла для предоставления доступа к ресурсам. Приложение ASP.NET должно только проверить, что в файле конфигурации ASP.NET для олицетворения задано значение true ; код безопасности для ASP.NET писать не требуется. Если олицетворение не включено, приложение запускается с удостоверением процесса ASP.NET. Для Microsoft Windows 2000 Server и Windows XP Professional удостоверением по умолчанию является локальная учетная запись с именем ASPNET, которая создается автоматически при установке ASP.NET. Для Microsoft Windows Server 2003 удостоверением по умолчанию является удостоверение пула приложений для приложения IIS (по умолчанию учетная запись NETWORK SERVICE).

5. Если доступ разрешен, приложение ASP.NET возвращает запрошенный ресурс через IIS.

Проверка подлинности с помощью форм

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

Рис.3 Проверка подлинности форм. На рисунке показана следующая последовательность событий:

1. Пользователь создает запрос на защищенный ресурс.

2. Службы IIS получают запрос, и так как IIS разрешают анонимный доступ, они не выполняют никакой проверки подлинности пользователя и передают запрос приложению ASP.NET.

3. Так как ASP.NET использует режим поверки подлинности с помощью форм, приложение ASP.NET проверяет билет проверки подлинности на основе форм для запроса (отдельный файл «cookie»). Если к запросу не приложен билет проверки подлинности, ASP.NET перенаправляет запрос на страницу входа в систему, указанную в файле конфигурации приложения. На странице входа в систему пользователь вводит необходимые учетные данные, обычно имя и пароль. Код приложения проверяет учетные данные, чтобы подтвердить их подлинность. Если учетные данные проходят проверке подлинности, код приложения вкладывает билет проверки подлинности в ответ, который представляет учетные данные пользователя. (Пароль не включается). Если проверка подлинности не пройдена, ответ возвращается с сообщением об отказе в доступе, либо форма входа в систему представляется повторно.Выпущенный билет проверки подлинности включается в следующий запрос к приложению ASP.NET. ASP.NET проверяет допустимость использования билетом проверки подлинности сообщения (MAC).

4. Если пользователь проходит проверку подлинности, ASP.NET проверяет подлинность и может разрешить доступ к изначально запрошенному ресурсу, перенаправить запрос на другую страницу или на пользовательский модуль проверки подлинности, где учетные данные тестируются для разрешения доступа к защищенным ресурсам. Если авторизация завершается неуспешно, ASP.NET перенаправляет пользователя на страницу входа в систему.

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

IIS 7.0 Особенности

В основе выпуска IIS 7.0 лежит полностью модульный веб-сервер, включающий более 40 компонентов, которые можно объединять в компактные веб-серверы, оптимизированные для необходимой роли в топологии приложения. Эти компоненты создаются на основе нового слоя расширяемости, что позволяет разработчикам расширять или замещать практически любую функцию сервера в машинном коде или с помощью Microsoft® .NET Framework. IIS 7.0 предлагает расширяемость компонентов этапа выполнения, управления и рабочих компонентов, облегчая создание комплексных решений в соответствии с конкретными потребностями. На базе основной платформы IIS 7.0 берется за решение многих проблем, связанных с управляемостью и эксплуатацией сервера. Он обладает принципиально новой системой настройки, обеспечивающей полностью делегированное управление узлами и, в конечном итоге, делающей реальностью развертывание веб-приложений с использованием xcopy. Новые интерфейсы API для целей управления и диагностические компоненты делают процедуры развертывания, администрирования и устранения неполадок сервера значительно проще и удобнее, чем когда-либо прежде.

Реферат: работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Построение веб-приложения на основе ASP.NET и архитектуры сервера IIS 7.0

Выполнил: студент 367 гр.

Введение

В настоящее время сложно переоценить роль интернета. Это одна из наиболее динамично развивающихся отраслей, даже в условиях кризиса.

А что такое интернет без веб страниц и, соответственно, веб серверов?

Сейчас на рынке можно достаточно большое количество самых разных веб серверов. Один из наиболее распространенных – это Internet Information Server корпорации Microsoft. Учитывая последние тенденции к комплексным решениям Microsoft выпустила IIS 7.0, дающий разработчикам и администраторам новые возможности при создании и управлении сайтами.

В своей работе я ознакомился с новыми возможностями и применил их на практике.

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

Задачи:

1. Изучить новые возможности IIS 7.0

2. Познакомится с ASP.NET

3. Написать модуль аутентификации

Теоретическая часть

Безопасность в сети необходима, особенно если дело касается денег. Злоумышленники прибегнут к всевозможным ухищрениям лишь бы добраться до номера вашего банковского счета, логина и пароля в интернет-магазине. Данный проект написан на C# с применением технологии ASP.NET неслучайно. Существует множество готовых решений и предусмотренных классов для обеспечения безопасности соединения. Microsoft предлагает комплексные решения для многих задач. Продукты этой фирмы используются почти всеми, как в корпоративной сети, так и в обычной жизни. Интересующая нас задача — это создание и сопровождение полноценных защищенных веб приложений, таких как интернет магазин например.

Для создания безопасного веб-приложения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.

Давайте рассмотрим поближе систему безопасности ASP.NET

Чтобы обеспечить безопасность веб-приложений, ASP.NET используется совместно с Microsoft .NET Framework и службами Microsoft Internet Information Services (IIS). Для создания безопасного приложения ASP.NET следует выполнить две основные функции:

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

· Авторизация (Ограничивает право доступа, предоставляя определенные разрешения или отказывая в них удостоверенной личности)

ASP.NET в сочетании со службами Microsoft Internet Information Services (IIS) может выполнять проверку подлинности учетных данных пользователя, например имен и паролей, используя любой из перечисленных ниже методов проверки подлинности:

· Windows: стандартная, шифрованная или встроенная проверка подлинности Windows (NTLM или Kerberos).

· Проверка подлинности в формах, в которых разработчик создает страницу входа и управляет проверкой подлинности в приложении.

· Проверка подлинности с помощью сертификатов клиента.

Рассмотрим Архитектуру безопасности ASP.NET

Рис.1 Архитектура безопасности ASP.NET

Как показано на рисунке, все веб-клиенты взаимодействуют с приложениями ASP.NET с помощью служб IIS. При необходимости IIS проверяет подлинность запроса и затем определяет местонахождение запрошенного ресурса (например, приложение ASP.NET). Если клиент авторизован, ему предоставляется доступ к этому ресурсу.

Во время выполнения приложение ASP.NET может использовать встроенные средства безопасности ASP.NET. Кроме того, в приложении ASP.NET могут использоваться средства безопасности платформы .NET Framework.

Два стандартных стандартных сценария обеспечения безопасности: олицетворение(проверка подлинности Windows) и проверки подлинности с помощью форм с использованием файлов «cookies».

Олицетворение

Рис.2 Олицетворение. На рисунке показана следующая последовательность событий:

1. Запрос поступает в службы IIS от клиента сети.

2. Службы IIS проверяют подлинность клиента, используя стандартную, шифрованную или встроенную безопасность Windows (NTLM или Kerberos).

3. Если клиент проходит проверку подлинности, службы IIS передают удостоверенный запрос в ASP.NET.

4. Приложение ASP.NET олицетворяет клиент, выполняющий запрос, используя лексему доступа, переданную из IIS, и использует разрешения NTFS-файла для предоставления доступа к ресурсам. Приложение ASP.NET должно только проверить, что в файле конфигурации ASP.NET для олицетворения задано значение true ; код безопасности для ASP.NET писать не требуется. Если олицетворение не включено, приложение запускается с удостоверением процесса ASP.NET. Для Microsoft Windows 2000 Server и Windows XP Professional удостоверением по умолчанию является локальная учетная запись с именем ASPNET, которая создается автоматически при установке ASP.NET. Для Microsoft Windows Server 2003 удостоверением по умолчанию является удостоверение пула приложений для приложения IIS (по умолчанию учетная запись NETWORK SERVICE).

5. Если доступ разрешен, приложение ASP.NET возвращает запрошенный ресурс через IIS.

Проверка подлинности с помощью форм

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

Рис.3 Проверка подлинности форм. На рисунке показана следующая последовательность событий:

1. Пользователь создает запрос на защищенный ресурс.

2. Службы IIS получают запрос, и так как IIS разрешают анонимный доступ, они не выполняют никакой проверки подлинности пользователя и передают запрос приложению ASP.NET.

3. Так как ASP.NET использует режим поверки подлинности с помощью форм, приложение ASP.NET проверяет билет проверки подлинности на основе форм для запроса (отдельный файл «cookie»). Если к запросу не приложен билет проверки подлинности, ASP.NET перенаправляет запрос на страницу входа в систему, указанную в файле конфигурации приложения. На странице входа в систему пользователь вводит необходимые учетные данные, обычно имя и пароль. Код приложения проверяет учетные данные, чтобы подтвердить их подлинность. Если учетные данные проходят проверке подлинности, код приложения вкладывает билет проверки подлинности в ответ, который представляет учетные данные пользователя. (Пароль не включается). Если проверка подлинности не пройдена, ответ возвращается с сообщением об отказе в доступе, либо форма входа в систему представляется повторно.Выпущенный билет проверки подлинности включается в следующий запрос к приложению ASP.NET. ASP.NET проверяет допустимость использования билетом проверки подлинности сообщения (MAC).

4. Если пользователь проходит проверку подлинности, ASP.NET проверяет подлинность и может разрешить доступ к изначально запрошенному ресурсу, перенаправить запрос на другую страницу или на пользовательский модуль проверки подлинности, где учетные данные тестируются для разрешения доступа к защищенным ресурсам. Если авторизация завершается неуспешно, ASP.NET перенаправляет пользователя на страницу входа в систему.

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

IIS 7.0 Особенности

В основе выпуска IIS 7.0 лежит полностью модульный веб-сервер, включающий более 40 компонентов, которые можно объединять в компактные веб-серверы, оптимизированные для необходимой роли в топологии приложения. Эти компоненты создаются на основе нового слоя расширяемости, что позволяет разработчикам расширять или замещать практически любую функцию сервера в машинном коде или с помощью Microsoft® .NET Framework. IIS 7.0 предлагает расширяемость компонентов этапа выполнения, управления и рабочих компонентов, облегчая создание комплексных решений в соответствии с конкретными потребностями. На базе основной платформы IIS 7.0 берется за решение многих проблем, связанных с управляемостью и эксплуатацией сервера. Он обладает принципиально новой системой настройки, обеспечивающей полностью делегированное управление узлами и, в конечном итоге, делающей реальностью развертывание веб-приложений с использованием xcopy. Новые интерфейсы API для целей управления и диагностические компоненты делают процедуры развертывания, администрирования и устранения неполадок сервера значительно проще и удобнее, чем когда-либо прежде.

IIS 7.0 разбивает веб-сервер на небольшое ядро сервера и более чем 40 модулей компонентов, подключаемых к этому ядру. Эти модули — такие, как StaticFileModule, который позволяет загружать статическое веб-содержимое, или WindowsAuthModule, поддерживающий встроенную проверку подлинности NTLM, — можно устанавливать на сервере независимо, чтобы обеспечить именно те функциональные возможности, которые необходимы.

Эти модули можно в любое время полностью удалить с сервера или намеренно отключить на время работы конкретного приложения, которому они не требуются. Такая возможность позволяет администраторам сервера быстро развертывать серверы минимальной конфигурации со значительным уменьшением мест, доступных для атак, и существенным увеличением производительности за счет выполнения только необходимого кода. Архитектура, построенная из независимых компонентов, является важнейшим свойством IIS 7.0, ведущим к снижению рисков нарушения безопасности и минимизации необходимости вносить исправления. Она делает возможными специализированные развертывания сервера, для которых объединяются выбранные компоненты IIS и специальные составляющие, оптимизированные для конкретной роли сервера в топологии приложения, например, обратных прокси и кэширующих серверов, серверов балансировки нагрузки протокола HTTP или SSL и серверов безопасности Sentinel.

Все компоненты сервера, поставляемые с IIS 7.0, созданы на основе новых общедоступных интерфейсов API расширяемости. У разработчика имеется возможность заместить любой из существующих компонентов сервера своим собственным или создать новый модуль для добавления его к набору компонентов IIS 7.0. Новые интерфейсы API расширяемости являются фундаментальным усовершенствованием предыдущей модели расширяемости ISAPI и позволяют расширить возможности сервера за счет большей гибкости и простоты использования. Практически каждая отдельная характеристика сервера, начиная с ядра сервера, и вплоть до его конфигурации, управления и диагностики, обеспечивает расширяемость, что позволяет расширять сервер и формировать его в соответствии с конкретными потребностями.

Упрощенное развертывание и настройка

Централизованное хранилище конфигураций предыдущих версий IIS, известное как метабаза, ушло в прошлое. Для IIS 7.0 характерна новая система делегированной настройки, основанная на иерархии распределенных файлов настройки в формате XML. Данная иерархия обобщена в глобальном файле applicationHost.config, в котором содержатся значения по умолчанию для настройки уровня сервера, и распределенных файлах web.config, находящихся в структуре каталогов приложения. Это те же самые файлы, которые используются инфраструктурой приложения ASP.NET для хранения параметров в переносимом виде. Это позволяет хранить одновременно конфигурации IIS и ASP.NET, используя четкие и жестко структурированные директивы XML. Вот один пример:

В прошлом для того, чтобы приложение IIS работало надлежащим образом, требовалось точно настроить параметры приложения в хранилище метабазы на уровне компьютера. В случае распределенных файлов web.config приложения инкапсулируют требуемую настройку сервера в структуру своих каталогов. Это существенно упрощает развертывание, позволяя независимые приложения просто копировать в каталог приложения на целевом сервере и незамедлительно запускать подготовленные приложения с требуемыми параметрами.

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

В полном соответствии основной идее IIS 7.0 система настройки является полностью расширяемой. Новые модули могут добавлять собственные схемы настройки, позволяя приложениям настраивать свои компоненты наряду с настройкой IIS и ASP.NET:

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

IIS 7.0 продолжает поддерживать существующий код настройки, использующий для записи в традиционную метабазу интерфейсы API объекта ABO (Admin Base Object) или сценарии, использующие интерфейсы высокого уровня ADSI (Active Directory® Service Interfaces) и объекты WMI (Windows Management Instrumentation) для настройки IIS. Это достигается посредством предоставления слоя совместимости, который эмулирует интерфейсы API объектов ABO, являющиеся основой для всех других традиционных интерфейсов API настройки, позволяя таким сценариям читать и изменять настройку тем же способом, как они делали это в предыдущих версиях IIS. В то время как новый формат настройки с использованием структурированного XML облегчает работу с конфигурацией в привычном текстовом редакторе, IIS предоставляет администраторам также узел с инструментами управления и интерфейсы API, облегчающие управление сервером и делающие возможной автоматизированную настройку и развертывание.

.NET Framework и создание сценариев

Кроме администрирования сервера вручную с помощью IIS Manager или инструмента командной строки appcmd.exe IIS 7.0 предоставляет множество возможностей программного администрирования. Во-первых, можно использовать интерфейс API Microsoft.Web.Administration для управления сервером из приложений .NET. Или использовать новый интерфейс API COM для непосредственного управления системой настройки IIS, либо получить к ней доступ из среды создания сценариев, например ASP или Windows® Script Host (WSH). Существует также новый поставщик WMI и поддержка традиционных поставщиков WMI и ADSI посредством слоя совместимости метабазы.

Microsoft.Web.Administration, новый интерфейс API администрирования .NET, облегчает приложениям управляемого кода обеспечивать программную поддержку узлов и приложений IIS, получать доступ к важной информации о состоянии и диагностическим данным и изменять настройку сервера. Способность приложений на основе .NET Framework беспрепятственно получать доступ к информации о настройке IIS и данным о состоянии открывает необъятный простор для написания приложений настройки с использованием .NET и управляющих приложений или даже выполнения задач управления непосредственно из страниц ASP.NET.

Создание компонентов веб-сервера

IIS 7.0 дает возможность сформировать сервер в соответствии с конкретными потребностями, позволяя добавлять или заменять в сервере любой компонент для обеспечения требуемого набора функций. В основе этой возможности лежит совершенно новый интерфейс расширяемости веб-сервера, на основе которого создаются все существующие компоненты HTTP IIS 7.0. Этот интерфейс API является открытым, что означает возможность реализации любого из компонентов, поставляемых с IIS 7.0. Для IIS это самое важное и фундаментальное усовершенствование по сравнению с предыдущей ограниченной моделью расширяемости ISAPI.

Новый интерфейс расширяемости представляет собой набор интуитивных классов C++, определяющих объектную модель и дающих возможность модулю предоставлять службы обработки запросов на IIS. Эти классы определяются в заголовочном файле в Windows Vista SDK.

В сравнении с ISAPI эти интерфейсы API являются как более мощными, так и намного более простыми в использовании. Как такое возможно? Во-первых, для нового интерфейса API характерна хорошо инкапсулированная модель с безопасными типами. Разработка существенно облегчается благодаря использованию новой объектной модели сервера, предоставляющей специализированные интерфейсы для всех основных объектов сервера и задач. К ним относятся:

· Проверка запроса с помощью класса IHttpRequest

· Управление откликом с помощью класса IHttpResponse

· Использование полезных функций служебных программ класса IHttpServer

· Обеспечение проверки подлинности с помощью класса IHttpUser

· Получение доступа к разделу пользовательской настройки вашего модуля с помощью интерфейсов API настройки

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

Разработчики получат преимущество также благодаря усовершенствованным шаблонам для управления памятью и состоянием. Большинство интерфейсов API сервера IIS 7.0 используют для возвращаемых данных память, управляемую сервером, вместо запроса на выделение буферов и управления ими, как это делает ISAPI и большинство существующих интерфейсов API в Win32®. В прошлом это был один из наиболее подверженных ошибкам и утомительных этапов разработки ISAPI. Новый интерфейс API упрощает также многие сложные задачи обработки запросов, например, буферизацию отклика, проверку подлинности и подготовку данных отклика для клиента

Интеграция ASP.NET

В составе сервера IIS 7.0 ASP.NET приходит в двух версиях: Режим Classic и режим Integrated Режим Classic работает точно так же, как он работал в предыдущих версиях IIS. Режим Integrated, являющийся платформой по умолчанию, использует совершенно новый обработчик для обеспечения интеграции высочайшего уровня с веб-сервером IIS. В режиме Integrated интерфейсы API ASP.NET можно использовать для разработки модулей IIS 7.0, которые напрямую интегрируются с веб-сервером и в состоянии предоставлять практически все возможные службы благодаря лежащему в основе интерфейсу API на C++,.

По существу, это оптимальный вариант — знакомые интерфейсы и удобные службы приложений .NET Framework и ASP.NET 2.0, такие, как управление членством и ролями, плюс неограниченная возможность расширения сервера, ранее доступная только составляющим ISAPI, написанным на C.

В добавление к возможности написания новых модулей ASP.NET, основанной на особых преимуществах режима Integrated, многие унаследованные модули ASP.NET можно сделать гораздо более мощными простым изменением нескольких параметров настройки в файле web.config.

Рис 4. Жизненный цикл ASP.NET

Для разработчиков ASP.NET преимущества интегрированного конвейера заключаются в следующем:

  • Интегрированный конвейер может вызывать все события, объявленные в объекте HttpApplication, что позволяет существующим HTTP-модулям ASP.NET работать в интегрированном режиме IIS 7.0.
  • И модули машинного кода, и модули управляемого кода можно настраивать на уровне веб-сервера, веб-узла и веб-приложения. Это относится и к встроенным модулям управляемого кода ASP.NET для управления состоянием сеанса, проверкой подлинности форм, профилями и ролями. Более того, поддержку модулей управляемого кода можно включить или отключить для всех запросов, независимо от того, предназначен ли запрос для ресурса ASP.NET, например ASPX-файла.
  • Модули управляемого кода можно вызывать на любом этапе конвейера. Это можно сделать до обработки запроса на сервере, после обработки на сервере или в любой момент во время обработки.
  • Регистрация, включение и отключение модулей выполняется в файле Web.config приложения.

Модули управляемого кода в службах IIS 7.0

  • FormsAuthenticationModule
  • ProfileModule
  • RoleManagerModule
  • SessionStateModule

Разработка настраиваемых модулей управляемого кода

Жизненный цикл приложения ASP.NET можно расширить с помощью модулей, в которых реализован интерфейс IHttpModule. Модули, в которых реализован интерфейс IHttpModule, являются модулями управляемого кода. Интегрированный конвейер ASP.NET и IIS 7.0 также можно расширить с помощью модулей машинного кода, которые в данном разделе не рассматриваются. Модуль управляемого кода можно задать как файл класса в папке App_Code приложения. Также можно создать модуль как проект библиотеки классов, скомпилировать его и добавить в папку Bin приложения. После создания настраиваемого модуля его необходимо зарегистрировать с помощью IIS 7.0. Для управления модулями управляемого кода IIS 7.0 можно воспользоваться одним из описанных ниже методов. Например, чтобы зарегистрировать модуль управляемого кода только для одного приложения, можно изменить файл Web.config этого приложения. Если модуль находится в папке App_Code или Bin и зарегистрирован в файле Web.config приложения, этот модуль вызывается только для этого приложения. Чтобы зарегистрировать модуль Web.config приложения, необходимо изменить элемент modules в разделе system.webServer . Изменения, внесенные с помощью IIS Manager или средства Appcmd.exe, вносятся в файл Web.config приложения.

Модули управляемого кода также можно зарегистрировать в элементе modules хранилища конфигурации IIS 7.0 (файл ApplicationHost.config). Модули, зарегистрированные в файле ApplicationHost.config, обладают глобальной областью действия, поскольку они зарегистрированы для всех веб-приложений, размещенных с помощью служб IIS 7.0. Модули машинного кода, заданные в элементе globalModules файла ApplicationHost.config, также обладают глобальной областью действия. Если глобальный модуль в веб-приложении не используется, его можно отключить.

Практическая часть

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

При правильной настройке сервера действия, прописанные в модуле будут вызываться всякий раз при обращении пользователя к любому ресурсу сервера. Хоть система безопасности отклоняет «подозрительные» запросы к ресурсам, можно в написать свой модуль или обработчик, анализирующий и отклоняющий опасные запросы и попытки атак.

Модуль реализован с применением стандартного класса IHttpModule.

public class userAuth : IHttpModule

public void Init(HttpApplication app)

app.AuthenticateRequest += new EventHandler(this.Authorize);

При каждом обращении к странице возникает событие AuthenticateRequest, на которое модуль реагирует обработчиком события Authorize

public void Authorize(Object source, EventArgs e)

HttpApplication application = (HttpApplication)source;

Приложение II. Использование ASP.NET без IIS

Приложение II. Использование ASP.NET без IIS

В учебном процессе или при тестировании приложений иногда возникает потребность работы с веб службами ASP . NET без использования IIS . При использовании . NET Framework 2.0 и операционной системы Windows XP SP2 или Windows Server 2003 можно достаточно просто создать свой носитель веб служб на основе классов HttpListener и HttpRuntime , при этом служба IIS может быть не установлена в системе. Далее приведен пример простого класса, позволяющего осуществлять размещение приложений ASP . NET в учебных целях.

Далее приведен пример использования этого класса, позволяющий хранить ASP страницы в поддиректории www и обращаться к ним по локальным адресам и порту 8080.

Используемый при вызове метода ApplicationHost.CreateApplicationHost тип (в данном случае – AspHost ) должен находиться, как один из вариантов, в глобальной сборке. Далее приводится make файл для создания простейшего носителя ASP . NET .

После команды nmake && nmake install в поддиректорию www можно помещать страницы ASP . NET с расширениями aspx и asmx .

Средства безопасности ASP.NET. Аутентификация

Давайте теперь перейдём к описанию процесса аутентификации непосредственно в рамках среды ASP.NET, где для вашего выбора предоставлены 3 вида аутентификации:

* Аутентификация Windows
* Формой
* Паспортом

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

Как и следует из названия, этот метод основывается на использовании учётных записей Windows. Такой метод уместен, если вы создаёте приложение для локальной сети, и все действующие учётные записи и группы хранятся на заранее определённом домене. При этом нужно быть очень осторожными, назначая права доступа пользователям, поскольку вы одновременно задаёте и права для работы в Windows. Для того, чтобы настроить ASP.NET на работу в режиме Windows аутентификации необходимо изменить файл настройки Web-проекта Web.config или при необходимости конфигурационный файл всего сервера, расположенный по адресу WINDOWS_FOLDERMicrosoft.NET

Framework.NET versionCONFIGMachine.config. В нашем примере мы будем работать исключительно с файлом проекта – Web.config, в котором вам нужно найти раздел authentication и присвоить его атрибуту mode значение Windows:

Теперь можно приступить непосредственно к программированию и реализации аутентификации на основе Windows. В помощь вам класс WindowsIdentity, который служит специально для работы с аутентификацией Windows. Вообще, для аутентификации, базирующейся на Windows, существуют два основных класса, предоставляемых .NET Framework:

* GenericIdentity – только реализует интерфейс IIdentity и не относится к какому-то определённому типу аутентификации
* WindowsIdentity – также является реализацией интерфейса IIdentity, но плюс ещё и включает методы, характерные только для аутентификации на основе Windows

Имя пользователя и группы хранятся в объекте WindowsIdentity в следующем формате: DOMAINUserName и DOMAINGroup соответственно. Исключение составляют лишь встроенные группы, например группа Administrators, для обращения к ней можно использовать строку подключения через WindowsIdentity: BUILTINAdministrators. Или же можно задать встроенную группу из перечисления System.Security.Principal.WindowsBuiltInRole.

Из рис. 1 видно, что объект WindowsIdentity позволяет получить имя пользователя; определить тип аутентификации; установить, была ли аутентификация проведена анонимно; также можно узнать, прошёл пользователь аутентификацию или нет, гость он или системный пользователь.

Рис. 1 – Объект WindowsIdentity

Поскольку в приложениях ASP.NET для обращения к объекту WindowsIdentity нужно будет выстроить следующую цепочку:

HttpContext.Current.User.Identity, то вы сможете также определить, к какой роли принадлежит текущий пользователь. Это можно достичь благодаря тому, что свойство User в этой цепочке реализует интерфейс Iprincipal, который позволяет определить принадлежность пользователя к определённой роли путём вызова функции IsInRole, имеющей следующий синтаксис:

Но давайте ненадолго отойдём от голой теории и попробуем реализовать практический пример. Для этого создайте новый проект ASP.NET Web Application и введите следующий код:
Default.aspx:

Если был выбран режим аутентификации Windows и настройки IIS не вызвали никаких конфликтных ситуаций, то вы получите соответствующую информацию о своём текущем пользователе. Если же поле имени пользователя и типа аутентификации оказались пустыми, то вам нужно просто настроить IIS, для этого выполните следующие действия:

1. Откройте IIS и найдите виртуальный каталог с этим приложением
2. Откройте окно свойств для этого каталога и перейдите во вкладку Безопасность каталога. В рамке Анонимный доступ и проверка подлинности нажмите кнопку Изменить…
3. В появившемся окне (рис. 2) снимите флажок Анонимный доступ

Рис. 2 – Настройка IIS

На этом мы закончим рассмотрение аутентификации на основе Windows и перейдём к аутентификации формой.

Аутентификация формой:

Аутентификация формой или, как её ещё называют аутентификация на основе Cookie-файлов, имеет ряд преимуществ над аутентификацией Windows.

* Во-первых, вы имеете возможность самому определить на свой вкус и цвет или на вкус и цвет пользователя внешний вид формы регистрации вместо однотипного окна регистрации Windows.
* Во-вторых, вы полностью контролируете вводимую информацию
* Сведения о пользователях теперь может храниться не только в SAM или Active Directory, но и в любом другом хранилище, в частности: база данных, каталог LDAP, XML-файлы или же обычный текстовый файл.
* Отпадает необходимость связывать политику безопасности сервера с политикой Web-приложения, поскольку, как уже было ранее сказано, все сведения о пользователях можно вынести в отдельное хранилище данных без каких-либо пересечений с учётными записями ОС.

Модель безопасности ASP.NET

Безопасность – важнейшая часть Web-приложений, и она должна приниматься во внимание с первой стадии процесса разработки. По существу, безопасность – это все, что касается защиты вашего имущество от неавторизованных действий. И для ее обеспечения используется несколько механизмов, включая идентификацию пользователей, выдачу или отъем прав доступа к важным ресурсам, а также защиту информации, хранящейся на сервере и передающейся по проводам. Во всех этих случаях вам необходим некий фундаментальный каркас, обеспечивающий базовую функциональность безопасности. ASP.NET удовлетворяет эту потребность благодаря встроенным средствам, которые вы можете использовать для построения защиты ваших приложений.

Каркас безопасности ASP.NET включает классы для аутентификации и авторизации пользователей, а также для обращения с аутентифицированными пользователями в ваших приложениях. Более того, .NET Framework сам по себе предоставляет набор базовых классов для обеспечения конфиденциальности и целостности посредством шифрования и цифровых подписей.

С появлением ASP.NET 2.0 инфраструктура безопасности была существенно расширена за счет высокоуровневой модели управления пользователями и ролями, воплощенной как программно, так и посредством встроенных административных инструментов. Эта функциональность (доступная через программные интерфейсы Membership и Roles) строится на базе существующей инфраструктуры безопасности, которая появилась еще в ASP.NET 1.x. Но лучше всего то, что эта инфраструктура безопасности является полностью расширяемой через проектный паттерн “поставщика”, как вы увидите в главе 26. Пользовательские поставщики Membership.

В данной статье представлен общий путеводитель по средствам безопасности ASP.NET. В последующих главах 20-26 книги «Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов» вы сможете углубите свои познания по каждой теме из представленных здесь. А пока мы проведем краткое представление ключевых средств обеспечения безопасности .NET. Вы увидите, как структурированы поставщики аутентификации .NET и модули авторизации и узнаете о том, как пользовательский контекст безопасности представлен идентичностью и ведущими (principal) объектами. Более важно то, что вы получите общее представление о том, как можно встроить средства безопасности в вашу программную архитектуру и дизайн и увидите, какие факторы наиболее важны при создании безопасного программного обеспечения.

Что означает создание безопасного программного обеспечения

Хотя каркас безопасности, представленный .NET и ASP.NET, достаточно мощный, все же стоит постоянно иметь в виду базовые принципы и правильно применять эти средства в нужный момент. Слишком во многих проектах забота о безопасности проявляется запоздало, архитекторы и разработчики не думают о ней на ранних стадиях проекта. Но если вы не думаете о безопасности с самого начала, а именно — при разработке дизайна и архитектуры приложения, — как вы сможете правильно и вовремя применить средства защиты, предоставленные .NET Framework?

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

Понятие потенциальной угрозы

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

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

Однако моделирование угроз важно по еще одной причине. Как вы, возможно, знаете, не все потенциальные угрозы могут быть смягчены применением технологий защиты, — такими как аутентификация и авторизация. Другими словами, некоторые из них вообще невозможно разрешить технически. Например, банковское онлайновое решение может использовать SSL для защиты трафика Web-сайта. Но как пользователи могут знать, что они действительно используют банковскую страницу, а не хакерский поддельный Web-сайт? Хорошо, единственный способ убедиться в этом – проверить сертификат, используемый для установки канала SSL. Но пользователи должны быть предупреждены об этом, а потому вы должны каким-то образом их информировать. Поэтому “техника смягчения” угроз – это не только технологии защиты. Это включает требование того, чтобы все ваши пользователи знали, как проверить сертификат. (Конечно, вы не можете заставить их это делать, но ели ваша система спроектирована соответствующим образом, все же можно большинство из них стимулировать к этому). Моделирование угроз – метод анализа, помогающий выявить обстоятельства вроде этих, а не только факторы технического порядка.

Моделирование угроз – обширная тема, которая выходит далеко за пределы нашей книги. Если интересуетесь, — обратитесь к источникам: Майкл Говард (Michael Howard) и Дэвид Лебланк (David LeBlanc) «Разработка безопасного кода», второе издание (Microsoft Press, 2002) или Фрэнк Свидерски (Frank Swiderski) и Виндоу Снайдер (Window Snyder) «Моделирование угроз» (Microsoft Press, 2004).

Правила безопасного кодирования

Конечно, только безопасная архитектура и дизайн не могут сделать ваше приложение абсолютно защищенным. Это только один из наиболее важных факторов. После того, как вы разработали безопасную архитектуру и дизайн, вы должны также написать безопасный код. Опять же, «Разработка безопасного кода», второе издание (Microsoft Press, 2002) – великолепный источник подробной информации для каждого разработчика. При написании кода web-приложений вы всегда должны иметь в виду следующие правила:

  • Никогда не доверяйте пользовательскому вводу: Предполагайте, что каждый пользователь – дьявол, пока он не докажет обратного. Таким образом, всегда строго проверяйте пользовательский ввод. Разрабатывайте свой код валидации так, чтобы он проверял ввод только правильных значений, а не неправильных (Неправильных значений всегда больше, чем вы можете себе представить во время разработки приложения).
  • Никогда не используйте конкатенации строк для формирования предложений SQL: Всегда используйте параметризованные предложения, чтобы ваше приложение не было уязвимо для атак вмешательством в SQL, как описано в главе 7. Основы ADO.NET.
  • Никогда не выводите данные, введенные пользователем, на Web-страницу перед их проверкой и кодированием: Пользователь может ввести некоторые фрагменты кода HTML (например, скрипты), которые инициируют меж-сайтовую скриптовую уязвимость. Поэтому всегда используйте HttpUtility.HtmlEncode() для защиты специальных символов, — таких, как , перед выводом их на страницу, или используйте web-элемент управления, который выполняет такое кодирование автоматически.
  • Никогда не размещайте важные данные, критичную для бизнеса информацию, или данные, касающиеся внутренних правил безопасности в скрытых полях вашей Web-страницы: Скрытые поля могут быть легко изменены простым просмотром исходного кода Web-страницы, модификацией и сохранением в файле. Затем злоумышленник просто может отправить локальную модифицированную копию Web-страницы на сервер. Плагины броузеров могут сделать такой подход настолько же простым, как написание e-mail в Microsoft Outlook.
  • Никогда не сохраняйте важные или критичные для бизнеса данные в виде состояния: Вид состояния (state view) – это просто еще одно скрытое поле на Web-странице, и оно может быть легко декодировано и просмотрено. Если вы используете установку EnableViewStateMAC=true для своей страницы, то вид состояния будет подписан кодом аутентификации сообщений, созданном на базе ключа машины, находящегося в серверном machine.config. Мы рекомендуем использовать EnableViewStateMAC=true немедленно после включения данных в ваш вид состояния, который не должен быть изменен пользователями, просматривающими вашу Web-страницу. Подробнее о защите вида состояния читайте в главе 6. Управление состоянием.
  • Включайте SSL при использовании Basic-аутентификации или аутентификации форм ASP.NET: Аутентификация форм описана в главе 20. Аутентификация с помощью форм. Об SSL мы поговорим позднее в данной статтье, в разделе “Понимание SSL”.
  • Защищайте свои cookie: Всегда защищайте свои аутентификационные cookie при использовании аутентификации форм и устанавливайте таймауты насколько возможно, короткими и не длиннее, чем это действительно необходимо.
  • Применяйте SSL: Вообще, если ваше Web-приложение обрабатывает важные данные, защищайте весь Web-сайт с помощью SSL. Не забывайте защищать даже директории с графическими образами или другими файлами, которые не управляются приложением напрямую через SSL.

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

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

Понятие сторожа

Хороший способ повысить степень защиты вашего приложения – размещать компоненты в таком месте, которое требует защиты. Концептуальный паттерн сторожей (Gatekeepers) применяет модель конвейера к организации инфраструктуры безопасности. Эта модель помогает укрепить безопасность.

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

На рис. 1 показан конвейер сторожей. В конце этого конвейера можно видеть защищенный ресурс (которым может быть что угодно, даже ваш собственный код страницы). Защищенный ресурс будет доступен или исполнен только в том случае, если все сторожа откроют к нему доступ. Если хотя бы один из них откажет в доступе, обработка запроса будет прекращена и клиенту отправлено исключение безопасности.

Реализация центрального механизма безопасности в такой манере – вообще хорошая идея. Точно так же вы можете защитить бизнес-уровень своего приложения. Инфраструктура приложений ASP.NET также применяет этот механизм. ASP.NET включает несколько сторожей, каждый из которых проверяет несколько условий, таким образом, защищая ваше приложение. Далее вы познакомитесь со сторожами, которые включает в себя каркас ASP.NET, и с зоной ответственности каждого из них.

Gatekeeper 1-4 — Сторож 1-4

Protected Resource Защищенный ресурс

Рис.1. Конвейер сторожей.

Понятие уровней безопасности

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

  • Аутентификация: Прежде всего вы должны аутентифицировать пользователей. Аутентификация задает вопрос: кто идет? В конечном итоге она определяет, кто работает с вашим приложением на другом конце.
  • Авторизация: Во-вторых, как только вы узнали, кто работает с вашим приложением, ваше приложение должно решить, какие операции данный пользователь может выполнять и к каким ресурсам обращаться. Другими словами, авторизация отвечает на вопрос: каков ваш уровень допуска?
  • Конфиденциальность: Когда пользователь работает с приложением, вы должны гарантировать, что никто другой не сможет видеть важные данные, которые он обрабатывает. Таким образом, вы должны шифровать канал между броузером клиента и Web-сервером. Более того, возможно, вам придется шифровать данные, сохраняемые на заднем плане (или в форме cookie на клиенте), чтобы даже администратор базы данных или другой персонал вашей компании не мог видеть эти данные.
  • Целостность: И наконец, вы должны гарантировать, что данные, передаваемые между клиентом и сервером, не изменяются в результате неавторизованного вмешательства. Цифровые подписи позволяют снизить уровень этой угрозы.

ASP.NET включает базовую инфраструктуру для выполнения аутентификации и авторизации. Библиотека базовых классов .NET Framework включает некоторые классы в пространстве имен System.Security, предназначенные для шифрования и подписи данных. Более того, SSL – стандартизованный способ обеспечения конфиденциальности и целостности данных, передаваемых между клиентским броузером и Web-сервером. Теперь мы рассмотрим подробнее каждую из этих концепций.

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

Аутентификация – процесс определения идентичности пользователя и обеспечения гарантий этой идентичности. Процесс аутентификации аналогичен регистрации участников конференции. Во-первых, вы предъявляете некоторое свидетельство, доказывающее вашу идентичность (как паспорт или водительские права). Во-вторых, как только ваша идентичность проверена по этой информации, вы получаете личный значок участника конференции, или токен, который постоянно носите с собой на протяжении всей конференции. Любой, кто вас встретит на конференции, может легко определить вашу идентичность, взглянув на этот значок, который обычно содержит базовую идентифицирующую информацию, — такую, как ваше имя и фамилия. Весь этот процесс – пример аутентификации. Как только ваша идентичность установлена, ваш токен подтверждает ее, так что куда бы вы ни пошли в пределах конкретной области, ваша личность известна.

В приложениях ASP.NET аутентификация реализуется одной из четырех возможных аутентифицирующих систем:

  • Аутентификация Windows
  • Аутентификация форм
  • Паспортная аутентификация
  • Пользовательский процесс аутентификации

В каждом случае пользователь предъявляет некоторое удостоверение при регистрации в системе. Идентичность пользователя отслеживается разными способами, в зависимости от типа аутентификации. Например, операционная система Windows использует 96-битное число, называемое SID (security identifier – идентификатор безопасности) для идентификации каждого входящего пользователя. В аутентификации форм ASP.NET (подробно описанной в главе 20. Аутентификация с помощью форм ), пользователю выдается аутентифицирующий билет формы, который представляет собой комбинацию значений, которые шифруются и помещаются в cookie.

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

Имперсонификация

Имперсонификация – процесс исполнения кода в контексте (или от имени) другого пользователя. По умолчанию код ASP.NET исполняется от имени фиксированного, специфичного для конкретной машины, пользовательского бюджета (обычно ASP.NET на IIS 5.x, или Network Service на IIS 6.0). Чтобы исполнить код, используя другую идентичность, можно воспользоваться встроенными в ASP.NET возможностями имперсонификации. Можно использовать предопределенный пользовательский бюджет, либо предположить пользовательскую идентичность, если пользователь уже был аутентифицирован с применением бюджета Windows.

Вы можете использовать имперсонификацию по двум причинам:

  • Чтобы выдать каждому Web-приложению разные права: В IIS 5 для исполнения всех Web-приложений на компьютере используется бюджет по умолчанию, указанный в файле machine.config. Если вы захотите предоставить разным Web-приложениям разные права, то можете применить имперсонификацию для назначения разных бюджетов Windows каждому приложению. Это особенно важно для сценариев хостинга, когда нужно соответствующим образом изолировать Web-приложения разных заказчиков (так, чтобы, например, web-приложение заказчика A не могло получить доступ к директориям или базам данных web-приложения заказчика B).
  • Чтобы использовать существующие права доступа пользователя Windows: Например, представим приложение, которое извлекает информацию из различных файлов, для которых уже установлены специфичные для пользователей и групп наборы прав доступа. Вместо того, чтобы кодировать логику авторизации в вашем приложении ASP.NET, можно использовать имперсонификацию для установки идентичности текущего пользователя. Таким образом, Windows выполнит авторизацию для вас, проверив права доступа, как только вы попытаетесь обратиться к файлу.

Эти два сценария принципиально различны. В первом из них имперсонификация определяет один, специфический бюджет. В этом случае не важно, какой пользователь обращается к приложению, и не важно, какого рода защита уровня пользователя применяется, — код будет запущен от имени того бюджета, который вы установили. Во втором сценарии пользователи должны быть аутентифицированы IIS. Код Web-страницы будет исполнен с идентичностью соответствующего пользователя. Подробнее об этих опциях вы прочтете в главе 20. Аутентификация с помощью форм .

Авторизация

Авторизация – процесс определения прав и ограничений, назначенных аутентифицированному пользователю. Если взять аналогию с конференцией, то авторизация – это процесс выдачи допуска на определенные мероприятия, — например, на главный доклад. На большинстве конференций можно подписаться на разные уровни доступа, — на полный доступ, только вступительное заседание, или только на посещение выставочного зала. Это значит, что если вы захотите посетить главное заседание Конференции Профессиональных Разработчиков Microsoft, чтобы послушать, что скажет Билл Гейтс, то должны для этого иметь соответствующие права доступа. Как только вы войдете в зал заседаний, сотрудник службы безопасности проверит вашу эмблему участника конференции. На основании указанной на ней информации он либо пропустит вас, либо скажет, что вы не можете войти. Это пример авторизации. В зависимости от информации идентифицирующей вас, вам либо открывается, либо закрывается доступ к запрошенным ресурсам.

Пример с конференцией представляет случай авторизации на базе ролей, — когда авторизация определяется правами группы, к которой принадлежит пользователь, а не на тем, кто он такой. Другими словами, вы авторизуетесь для доступа в зал заседаний на основании роли (типа допуска), а не вашей специфичной идентифицирующей информации (имени и фамилии). Во многих случая авторизация на базе ролей предпочтительна, поскольку ее гораздо легче реализовать. Если сотрудник безопасности должен будет сверять имя каждого гостя со списком допущенных, то процесс авторизации сильно замедлится. То же самое верно и для Web-приложений, хотя более вероятно, что роли будут следующими: менеджеры, администраторы, гости, продавцы, клиенты и т.п.

В Web-приложениях разные типы авторизации происходят на разных уровнях. Например, на самом верхнем уровне ваш код может проверять идентичность пользователя и решать, — можно ли продолжать данную операцию. На нижнем уровне можно настроить ASP.NET так, чтобы запрещать доступ к определенным Web-страницам или директориям для определенных пользователей или ролей. На еще более низком уровне, когда ваш код выполняет различные задачи, — такие, как подключение к базе данных, открытие файла запись в протокол событий, и т.п., — операционная система Windows проверяет права бюджета Windows, исполняющего данный код. В большинстве ситуаций вы не захотите полагаться на этот самый нижний уровень, поскольку ваш код всегда будет исполняться от фиксированного бюджета. В IIS 5.x этот бюджет называется ASPNET. В IIS 6.0 – это фиксированный бюджет Network Service (в обоих случаях вы можете переопределить бюджет по умолчанию, как описано в главе 18. Развертывание Web-сайтов ).

Есть несколько причин для использования фиксированного бюджет для запуска кода ASP.NET. Почти во всех приложениях права, выданные пользователю, не соответствуют правам, которые требуются приложению, работающему от имени пользователя. Как правило, ваш код нуждается в более широком наборе привилегий, чтобы выполнять задачу идентификации, и вы не захотите выдавать такие права каждому пользователю, который может обращаться к вашему приложению. Например, вашему коду может понадобиться создавать протокольные записи о возможных сбоях, даже если данному пользователю не разрешено напрямую писать в протокол событий Windows, в файл или в базу данных. Аналогично приложения ASP.NET всегда должны иметь право доступа в директорий c:\[WinDir]\Microsoft.NET\[Version]\Temporary ASP.NET Files, чтобы создавать и кэшировать версии ваших Web-страниц на машинном языке. И наконец, вы можете пожелать использовать систему аутентификации, которая вообще никак не взаимодействует с Windows. Например, приложения электронной коммерции могут проверять адреса e-mail пользователей по базе данных серверной стороны. В этом случае идентичность пользователя никак не соответствует пользовательскому бюджету Windows.

В некоторых редких случаях вы можете предоставить вашему коду временно предполагать идентичность пользователя. Такой подход чаще всего используется при создании приложений ASP.NET для локальных сетей, в которых пользователи уже имеют четко определенные наборы привилегий Windows. В этом случае вам придется пополнить свой арсенал средств защиты имперсонификацией, как это описано в главе 22. Аутентификация Windows

Конфиденциальность и целостность

Конфиденциальность – означает обеспечение невидимости данных для неавторизованных пользователей во время передачи их по сети или сохранении в хранилищах, — таких, как базы данных. Целостность – обеспечение невозможности изменения данных никем во время передачи по сети или сохранения в хранилище. И то, и другое основано на шифровании.

Шифрование – процесс кодирования данных, делающий невозможным их прочтение другими пользователями. Шифрование в ASP.NET – полностью отдельное средство от аутентификации, авторизации и имперсонификации. Вы можете применять его в комбинации с этими средствами, либо самостоятельно.

Как уже упоминалось ранее, вы можете пожелать шифровать Web-приложения по двум причинам:

  • Для защиты коммуникаций (передачи данных по проводам): Например, вы хотите сделать невозможной кражу номеров кредитных карт, используемых в вашей системе электронной коммерции по открытым каналам Internet. Стандартный подход к этой проблеме заключается в применении SSL. SSL также реализует цифровые подписи для обеспечения гарантий целостности. SSL не реализуется ASP.NET. Это средство, предоставляемое IIS. Код вашей Web-страницы (или Web-службы) не зависит от того, применяется SSL или нет.
  • Для защиты постоянной информации (в базе данных или в файле): Например, вы можете пожелать сохранить номер кредитной карточки пользователя в базе данных для будущего использования. Хотя вы можете сохранять эти данные в простом тексте и надеяться, что Web-сервер не будет взломан, но это плохая идея. Вместо этого вам следует использовать шифрующие классы, которые предлагает .NET, чтобы вручную шифровать данные перед их сохранением.

Не важно, что классы .NET, выполняющие шифрование, не связаны напрямую с ASP.NET. Фактически вы можете использовать их в любых приложениях .NET. Подробнее о шифровании и цифровых подписях, а также управлении настраиваемым шифрованием будет рассказано в главе 25. Криптография.

Свяжем все вместе

Итак, как же заставить работать вместе аутентификацию, авторизацию и имперсонификацию в Web-приложении? Когда пользователи впервые заходят на Web-сайт, они анонимны. Другими словами, ваше приложение не знает (и не заботится о том), кто они такие. Если только вы не аутентифицируете их, все так и останется.

По умолчанию анонимные пользователи могут обращаться к любой странице ASP.NET. Но когда пользователь запрашивает Web-страницу, анонимный доступ к которой закрыт, выполняется несколько шагов (показанных на рис. 2):

  1. Запрос присылается на Web-сервер. Поскольку идентичность пользователя в этот момент не известна, ему предлагается зарегистрироваться (log-in), используя специальную Web-страницу или диалоговое окно регистрации броузера. Специфические детали процесса регистрации зависят от типа используемой аутентификации.
  2. Пользователь представляет свое удостоверение, которое затем верифицируется, — либо вашим приложением (в случае аутентификации формы), или автоматически средствами IIS (в случае аутентификации Windows).
  3. Если удостоверение пользователя подтверждается, ему предоставляется доступ к web-странице. Если же оно оценивается, как не легитимное, ему предлагается повторить попытку регистрации, либо он выполняется переадресация на страницу с сообщением “доступ закрыт”.

Название: работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0
Раздел: Остальные рефераты
Тип: реферат Добавлен 07:15:35 30 августа 2011 Похожие работы
Просмотров: 170 Комментариев: 6 Оценило: 1 человек Средний балл: 4 Оценка: неизвестно Скачать

Request for Restricted Resource Запрос ограниченного ресурса
User is authenticated Пользователь аутентифицирован
Yes Да
No Нет
Resource Ресурс
Login Регистрация

Рис. 2. Запрос Web-страницы, требующей аутентификации.

Когда пользователь запрашивает защищенную Web-страницу, которая открыта только для определенных пользователей или ролей, процесс аналогичен, но добавляется дополнительный шаг (см. рис. 3):

  1. Запрос присылается на Web-сервер. Поскольку идентичность пользователя в этот момент не известна, ему предлагается зарегистрироваться (log-in), используя специальную Web-страницу или диалоговое окно регистрации броузера. Специфические детали процесса регистрации зависят от типа используемой аутентификации.
  2. Пользователь предъявляет свое удостоверение, которое проверяется приложением. Это стадия аутентификации.
  3. Удостоверение или роли аутентифицированного пользователя сравниваются со списком разрешенных пользователей и ролей. Если пользователь есть в списке, ему открывается доступ к ресурсу; в противном случае доступ закрыт.
  4. Пользователи, которым отказано в доступе, либо приглашаются на повторную регистрацию, либо перенаправляются на Web-страницу с сообщением “доступ закрыт”

Рис. 3. Запрос Web-страницы, требующей аутентификации и авторизации.

Средства безопасности Internet Information Services

Прежде, чем исполняющей системы ASP.NET даже коснется входящий запрос, IIS проверяет безопасность в соответствии со своей собственной конфигурацией. Таким образом, перед тем, как изучать подробности средств безопасности ASP.NET, вы должны познакомиться с первым сторожем в конвейере безопасности вашего Web-приложения – IIS.

IIS представляет несколько важных механизмов защиты, которые выполняют функции сторожей, еще до того, как ASP.NET начинает обработку запросов. В основном, речь идет о следующих механизмах:

  • Аутентификация: IIS поддерживает следующие виду аутентификации: Basic, Digest, Passport и Windows, а также сертификатную аутентификацию по каналу SSL. Любая аутентификация IIS в конечном итоге сводится к аутентификации пользователя Windows. Таким образом, IIS поддерживает только аутентификацию пользователей Windows.
  • Авторизация: IIS поддерживает встроенную поддержку ограничений IP-адресов и оценку списков доступа Windows ACL.
  • Конфиденциальность: Шифрование может быть обеспечено средствами SSL.

В последующих разделах вы познакомитесь с деталями настройки безопасности IIS. Другие последующие главы 21-26, связанные с безопасностью, будут в основном посвящены деталям инфраструктуры безопасности ASP.NET. Вы всегда должны помнить о безопасности IIS, поскольку она оказывает влияние на поведение ASP.NET при разных настройках защиты, установленных в web.config.

Например, если ваше приложение ASP.NET желает использовать аутентификацию Windows, вы должны настроить IIS на использование либо Windows, либо Basic (Digest) аутентификации. Если ваше приложение ASP.NET не желает использовать бюджеты Windows (и потому, использовать собственную аутентификацию форм), вы должны настроить IIS так, чтобы он разрешал вход анонимным пользователям.

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

Как упоминалось ранее, IIS поддерживает несколько механизмов аутентификации. Любые другие конфигурационные настройки безопасности (и, следовательно, аутентификации) устанавливаются для всего Web-сайта. Вы можете найти эти настройки на закладке Directory Security свойств виртуальных директориев. Рис. 4 показывает опции аутентификации IIS.

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

Windows-аутентификация настраивает IIS для валидации удостоверений пользователей по зарегистрированным пользовательским бюджетам Windows, — либо на локальной машине, либо внутри домена. Работая в домене, пользователи не обязаны вводить свои имена и пароли, если они уже зарегистрированы на клиентской машине в сети, потому что “билет” клиентской аутентификации передается для аутентификации на сервер автоматически.

IIS также поддерживает Basic-аутентификацию. Это метод аутентификации, разработанный W3C, который определяет дополнительный заголовок HTTP для передачи имен и паролей пользователей по проводам. Информация передается в кодировке Base64. Таким образом, вы должны использовать только Basic-аутентификацию с SSL. Как и в случае Windows-аутентификации, удостоверения, введенные пользователями, оцениваются по бюджетам Windows. Однако способ их передачи по проводам отличается. В то время, как Basic-аутентификация передает информацию в заголовке HTTP, Windows-аутентификация использует для передачи информации либо NTLM, либо Kerberos.

Рис. 4. Опции аутентификации IIS.

Аутентификация Digest подобна аутентификации Basic. Вместо пересылки удостоверений по кабелю в кодировке Base64, на хэширует пользовательский пароль и передает по сети хэшированную версию. Хотя это выглядит более безопасным, Digest-аутентификация не слишком распространена. В результате, она редко используется вне контролируемых сред (таких, как intranet).

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

И, наконец, IIS поддерживает один дополнительный метод аутентификации, — сертификационную аутентификацию, которой нет на рис. 3, поскольку она конфигурируется через SSL.

Примечание. Для отладки приложений ASP.NET должна быть включена Windows-аутентификация, поскольку Windows определяет, разрешено ли вам заниматься отладкой, на основе выданных вам прав внутри Windows.

Авторизация IIS

Рис 5 показывает, как можно конфигурировать ограничения IP-адресов с IIS. Ограничения IP-адресов обеспечивают возможность ограничить доступ к Web-серверу только с машин, указанный в списке разрешенных. Это имеет смысл, если вы хотите только нескольким известным партнерам по бизнесу открыть доступ к своему Web-серверу.

Рис. 5. Ограничения IP-адресов на IIS.

IIS и Протокол Защищенных Сокетов (SSL

Технология SSL позволяет шифровать коммуникации по HTTP. SSL поддерживается широким кругом броузеров и гарантирует, что передача информации между клиентом и Web-сервером не может быть дешифрована злоумышленниками. SSL важен для сокрытия важной информации, — такой, как номера кредитных карт и конфиденциальные сведения внутрифирменного характера, но также она важна и для аутентификации пользователей. Например, если вы создаете страницу регистрации, на которой пользователь подтверждает свое имя и пароль, то должны применять SSL для шифрования этой информации. В противном случае злонамеренный хакер сможет перехватить удостоверение пользователя и использовать его для проникновения в систему.

IIS представляет SSL, как встроенный, готовый к использованию сервис. Поскольку SSL работает под HTTP, его использование не изменяет способа работы с HTTP-запросами. Всю шифровку и дешифровку берут на себя средства SSL программного обеспечения Web-сервера (в данном случае – IIS). Единственное отличие в том, что адрес, защищенный SSL, начинается с https://, а не http://www.realcoding.net/redir.php?url=http://. Трафик SSL также проходит через другой порт (обычно Web-серверы используют порт 443 для SSL-запросов, и порт 80 – для обычных запросов).

Чтобы сервер поддерживал SSL-соединения, он должен иметь инсталлированный сертификат X.509 (имя X.509 было выбрано для соответствия стандарту директориев X.500). Чтобы реализовать SSL, вы должны приобрести сертификат, инсталлировать его, и соответствующим образом конфигурировать IIS. В следующих разделах мы подробно раскроем все эти шаги.

Понятие сертификатов

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

Сам по себе сертификат содержит некоторую идентифицирующую информацию. Он подписывается защищенным ключом CA, что гарантирует его аутентичность и отсутствие модификаций. Промышленный стандарт сертификатов, известный, как x.509v3, включает следующую базовую информацию:

  • Имя, наименование организации и адрес держателя.
  • Открытый ключ держателя, который будет использоваться для реализации ключа SSL-сессий, для шифровки коммуникаций.
  • Даты проверки сертификата.
  • Серийный номер сертификата.

В дополнение сертификат также может включать специфичную для бизнеса информацию, — такую, как отрасль промышленности держателя, длительность присутствия его на рынке и т.п.

Два крупнейших центра сертификации следующие:

Если вам не нужно идентифицировать функцию валидации CA (например, если ваши сертификаты будут использоваться только в локальной сети intranet), вы можете создавать и использовать свои собственные сертификаты, и настроить все клиенты, чтобы они доверяли им. Для этого потребуется служба Active Directory b Certificate Server (которые встроены в Windows 2003 Server и Windows 2000 Server). За более подробной информацией обращайтесь к специальным книгам по администрированию сетей Windows.

Понятие SSL

Как было описано в предыдущем разделе, каждый сертификат включает открытый ключ. Открытый ключ – часть асимметричной пары ключей. Основная идея в том, что открытый ключ свободно предоставляется всем, кто в нем заинтересован. Соответствующий защищенный ключ хранится под замком, и доступен только серверу. Трюк заключается в том, что все, что зашифровано с одним из этих ключей, поддается расшифровке с помощью другого. Это значит, что клиент может получить открытый ключ и использовать его для кодирования секретного сообщения, которое может быть расшифровано с помощью соответствующего защищенного ключа . Другими словами, клиент может создавать сообщения, которые сможет прочесть только сервер.

Этот процесс называется асимметричным шифрованием, и он является базовым строительным блоком SSL. Важным принципом асимметричного шифрования является то, что вы не можете реконструировать защищенный ключ, анализируя соответствующий ему открытый ключ. Сделать это было бы чрезвычайно дорого по вычислительным ресурсам (даже сложнее, чем взломать одно из зашифрованных сообщений). Однако асимметричное шифрование также имеет свои пределы, а именно: оно намного медленнее и генерирует большие по объему сообщения, чем симметричное шифрование.

Симметричное шифрование – это разновидность шифрования, с которым интуитивно знакомо большинство людей. В нем один и тот же секретный ключ используется для шифровки и расшифровки сообщения. Недостаток симметричного шифрования в том, что оба участника должны знать секретное значение для того, чтобы осуществлять обмен сообщениями. Однако вы не можете передавать эту информацию по Internet, поскольку злоумышленники могут перехватить ее и в результате получить возможность расшифровывать все последующие сообщения. Главный трюк SSL в том, что он комбинирует асимметричное и симметричное шифрование. Асимметричное шифрование используется только при начальной передаче ключа, — другими словами, соглашения о секретном значении. Затем это секретное значение используется для симметричной шифровки последующих сообщений, что гарантирует наилучшую возможную производительность.

Весь процесс работает так:

  1. Клиент посылает запрос на соединение с сервером.
  2. Сервер подписывает свой сертификат и отправляет его клиенту. Это завершает фазу “рукопожатия”.
  3. Клиент проверяет, издан ли сертификат CA, которому он доверяет. Если это так, он переходит к следующему шагу. В сценарии с Web-броузером клиент может предупредить пользователя угрожающим сообщением о том, что он распознал CA и разрешает пользователю решать – продолжать ли дальше.
  4. Клиент сравнивает информацию в сертификате с информацией, присланной сайтом (включая доменное имя и его открытый ключ). Клиент также проверяет правильность сертификата стороны сервера, — что он не был отменен и издан заслуживающим доверия CA. Затем клиент принимает соединение.
  5. Клиент сообщает серверу, какие ключи шифрования он поддерживает для коммуникации.
  6. Сервер выбирает наибольшую подходящую длину ключа и информирует клиента.
  7. Используя указанную длину ключа, клиент случайным образом генерирует симметричный ключ шифрования. Он будет использован в период транзакции между сервером и клиентом. Это гарантирует оптимальную производительность, поскольку симметричное шифрование намного быстрее асимметричного.
  8. Клиент шифрует ключ сессии, используя открытый ключ сервера (из сертификата), и затем посылает зашифрованный сессионный ключ серверу.
  9. Сервер принимает зашифрованный сессионный ключ и расшифровывает его, используя свой защищенный ключ. После этого и клиент, и сервер имеют общий секретный ключ, и могут использовать его для шифрования коммуникаций в период, пока длится сессия.

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

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

Инсталляция сертификатов в IIS

При развертывании приложения возможно, вы пожелаете приобрести сертификаты от авторитетного CA, — такого, как VeriSign. Это, в частности, касается web-сайтов и Internet-броузеров, которые распознают ограниченное число центров сертификации автоматически. Если, например, вы используете тестовый сертификат для шифрования коммуникаций с защищенной частью web-сайта, то клиентский броузер отобразит предупреждение о том, что сертификат поставлен неизвестным CA.

IIS Manager позволяет автоматически формировать запрос сертификата. Для этого, прежде всего, запустите IIS Manager. Откройте группу Web Sites, щелкните правой кнопкой мышки элемент, соответствующий вашему Web-сайту (часто озаглавленному Default Web Site), и выберите Properties. На закладке Directory Security вы найдете кнопку Server Certificate (см. Рис. 6).

Рис. 6. Настройка безопасности директориев.

Щелкните кнопку Server Certificate для запуска помощника IIS Certificate Wizard (см. Рис. 7). Этот помощник запросит некоторую базовую организационную информацию и сгенерирует файл запроса. Кроме того, вы должны будете указать длину ключа в битах. Чем длиннее ключ, тем он надежнее.

Рис. 7. Создание запроса сертификата сервера.

Сгенерированный файл может быть сохранен в виде текста, но в конечном итоге он должен быть отправлен по e-mail CA. Пример файла запроса (слегка сокращенный) выглядит так:

CA вернет сертификат, который вы сможете инсталлировать в соответствии с его инструкциями. По принятому соглашению следует запускать все коммуникации SSL через порт 443, а нормальный web-трафик – через порт 80.

Кодировка информации с SSL

После того, как сертификат инсталлирован, довольно легко использовать коммуникации SSL. Единственный необходимый для этого шаг – модифицировать ваш запрос так, чтобы использовался URL, начинающийся с https:// вместо http://www.realcoding.net/redir.php?url=http://. Обычно это означает поправку в предложении Response.Redirect() вашего кода. Поскольку вся шифровка и расшифровка происходит непосредственно перед отправкой сообщения (или немедленно после его получения), вашему приложению не приходится беспокоиться о ручной дешифровке данных, манипулировании байтовыми массивами, использовании правильной кодировки символов и т.п.

На стороне сервера вы также можете инициировать соединения SSL таким образом, чтобы было невозможно взаимодействовать с web-службой без шифрования коммуникаций. Просто щелкните правой кнопкой по Web-сайту а IIS Manager, и выберите закладку Directory Security. В разделе Secure Communication щелкните кнопку Edit (которая доступна только после инсталляции сертификата). Затем выберите Require Secure Channel (см. Рис. 8).

Рис. 8. Инициализация SSL-доступа.

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

Приведем пример, проверяющий, передается ли текущий запрос по безопасному соединению, используя свойство HttpRequest.IsSecureConnection:

Примечание Общей ошибкой является использование localhost или любого другого псевдонима для имени хоста сервера в SSL-соединении. Это не будет работать, поскольку клиент пытается проверить, что часть CN (common name – общее имя) субъекта имени серверного сертификата соответствует имени хоста, содержащегося в запросе HTTP во время фазы “рукопожатия” SSL-обмена.

С SSL будет зашифрован весь трафик, а не только важные данные. По этой причине многие Web-серверы используют аппаратные ускорители для повышения производительности шифрования SSL.

Примечание Помните, что SSL не встроен в ASP.NET. Если вы хотите узнать больше об SSL, обратитесь к книгам, посвященным вопросам безопасности и IIS, — таким, как IIS Security (Osbourne/McGraw-Hill, 2002).

Архитектура безопасности ASP.NET

ASP.NET реализует концепцию сторожей (представленную выше) через модули HTTP. Каждый модуль – это класс, реализующий интерфейс IHttpModule, и каждый модуль выполняет функцию сторожа в инфраструктуре ASP.NET. Конечно, модули HTTP используются и для других задач, но многие из них связаны с безопасностью. Как видно на рис. 9, ASP.NET включает несколько модулей аутентификации и авторизации.

Поскольку Web-приложения используют бесстатусный HTTP, никакая информация не сохраняется между пользовательскими запросами. В результате пользователь должен быть аутентифицирован и авторизован в начале каждого запроса. ASP.NET справляется с этим посредством инициации глобальных событий приложения. Модули аутентификации могут обрабатывать эти события для осуществления аутентификации пользователя. Но не все запросы требуют аутентификации или авторизации. Однако события все равно инициируются всегда. Эти события обрабатываются конфигурированными модулями HTTP, как показано на рис. 9. Конечно, вы также можете обрабатывать события через глобальный класс приложения (эти события определены в классах кода заднего плана в файле Global.asax), но для большей степени повторной применяемости мы рекомендуем создавать отдельные модули HTTP, потому что это очень легко.

Рис. 9. Классы IHttpModule, в качестве сторожей безопасности ASP.NET.

Два главных события, с которыми вам нужно иметь дело, это AuthenticateRequest и AuthorizeRequest. Это не все события, которые здесь инициируются, но наиболее полезные. На рис. 10 показан порядок возникновения событий, связанных с системой безопасности.

HttpContext become available Становится доступен HttpContext
Populates the managed security context Наполняется управляемый контекст безопасности
Raised after the security context has been established Происходит после установления контекста безопасности
Handles any custom authorization needs Обрабатывает любые пользовательские нужды авторизации
Occurs after the current user request has been authorized Происходит после авторизации текущего запроса
Session state becomes accessible Становится доступно состояние сессии

Рис. 10. События приложения, связанные с безопасностью.

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

Событие AuthenticateRequest возбуждается объектом HttpApplication, когда запрос нуждается в аутентификации. Как только пользователь аутентифицирован (обычно предъявив некоторое удостоверение, — такое, как cookie с информацией о себе), следующий шаг – убедиться, что информация, идентифицирующая пользователя, полностью готова для остальной части цикла обработки страницы. Чтобы достичь этого, нужно создать новый объект с пользовательской информацией и присоединить ее к свойству User текущего HttpContext.

Событие AuthorizeRequest возбуждается после того, как пользователь аутентифицирован в событии AuthenticateRequest. Модули авторизации используют AuthorizeRequest для проверки того, авторизован ли пользователь для доступа к запрошенному ресурсу.

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

Аутентификация реализуется в ASP.NET через специализированные модули HTTP, как показано на рис. 9 и 10. Вы выбираете модуль аутентификации, который хотите использовать, в элементе конфигурационного файла web.config. Все модули аутентификации реализуют интерфейс IHttpModule, который предоставляет доступ к событиям приложения (как описано в главе 5. Приложения ASP.NET). Это позволяет им обрабатывать событие HttpApplication.AuthenticateRequest. Каждый модуль также представляет собственное событие Authenticate, которое вы можете обработать в global.asax.

ASP.NET представляет три центральных модуля аутентификации:

  • FormsAuthenticationModule
  • WindowsAuthenticationModule
  • PassportAuthenticationModule

Следующие разделы кратко описывают каждый модуль.

FormsAuthenticationModule

Модуль FormsAuthenticationModule использует аутентификацию форм, что позволяет вам разрабатывать собственные страницы регистрации (login-pages), писать собственную логику аутентификации, при этом полагаясь на ASP.NET для отслеживания информации о пользователе и роли, используя шифрованные cookie. Модуль FormsAuthenticationModule активен, когда элемент установлен следующим образом:

Глава 20. Аутентификация с помощью форм более подробно описывает аутентификацию форм. (Вы также можете использовать аутентификацию форм с программными интерфейсами Membership API и Roles API, которые мы представим позднее в этой статтье раскроем в деталях в главе 20. Аутентификация с помощью форм).

WindowsAuthenticationModule

Модуль WindowsAuthenticationModule работает в сочетании с IIS для выполнения аутентификации Windows. Этот модуль активен, когда элемент в файле web.config установлен следующим образом:

Более подробно Windows-аутентификация рассматривается в главе 22. Аутентификация Windows .

PassportAuthenticationModule

PassportAuthenticationModule активен, когда элемент в файле web.config установлен следующим образом:

Модуль PassportAuthenticationModule представляет “обертку” для службы аутентификации Microsoft Passport. При использовании Passport пользователь аутентифицируется по информации в базе данных Microsoft Passport (та же технология, которая поддерживается бесплатной почтовой системой Hotmail). Выгода от Passport в том, что вы можете использовать существующие удостоверения пользователей (такие, как адрес e-mail и пароль), не заставляя пользователя проходить отдельный процесс регистрации. Недостаток же в том, что вы должны заключать лицензионное соглашение с Microsoft и платить за пользование этой системой.

ASP.NET не включает полную поддержку аутентификации Passport. Чтобы успешно ее использовать, вы должны выгрузить и инсталлировать на свой Web-сервер Passport .NET SDK. В этой книге мы не рассматривает Passport, но вы можете узнать больше (и выгрузить SDK) на http://www.realcoding.net/redir.php?url=http://www.microsoft.com/net/ser. .

Авторизация

Как только пользователь аутентифицирован, такая информация, как имя пользователя и контекст безопасности становится автоматически доступна посредством инфраструктуры ASP.NET. Вы можете обратиться к ней через объект HttpContext.Current.User и использовать эту информацию, чтобы реализовать авторизацию в своем коде. Более того, ASP.NET включает следующие встроенные модули для реализации авторизации:

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

Внимание! Применение имперсонификации коварно (если не опасно). Оно требует правильной конфигурации элементов ACL по каждому объекту для каждой группы, а иногда даже еще и по каждому пользователю. Простая ошибка в конфигурации может привести к дырам в системе безопасности вашего приложения. По мере роста количество пользователей (и групп Windows) ситуация становится все более и более сложной, а потому ошибки в конфигурации вполне возможны. Вы должны применять имперсонификацию, если только это действительно необходимо. Всегда предпочтительнее создавать специальные роли пользователей приложения и выполнять авторизацию на базе этих ролей.

Более того, вы можете реализовать авторизацию посредством написания специального кода в своих страницах или компонентах, используемых web-приложением. В этом случае вы ссылаетесь на объект HttpContext.Current.User и принимаете решение на основе принадлежности к ролям или непосредственно по имени пользователя. О дизайне и реализации авторизации будет рассказано подробно в главе 23. Авторизация и роли. Но прежде, чем изучать детали аутентификации и авторизации вы должны понимать значение контекста безопасности (security context)

Контекст безопасности

Независимо от системы аутентификации, ASP.NET использует в основе одну и ту же модель представления информации о пользователе и роли. Пользователям, которые регистрируются в Web-приложении, на основе предъявленных ими удостоверений выделяется принципал (principal) и идентичность. Объект-принципал представляет текущий контекст безопасности данного пользователя. Он комбинирует самого пользователя (идентичность) с информацией, сохраняемой в записях бюджета текущего пользователя, — такой, как роди, привилегии, и многое другое. Таким образом, это позволяет вам выполнять авторизацию, основанную на ролях, и представляет ссылку на соответствующий объект идентичности. Объект идентичности представляет успешно авторизованного пользователя и потому предоставляет информацию о пользователе, — такую, как его имя.

Интерфейс IPrincipal

Все объекты-принципалы реализуют интерфейс IPrincipal, который определяет центральный набор функциональности. Когда вы обращаетесь к свойству User текущей Web-страницы (System.Web.UI.Page), или из текущего контекста HTTP (HttpContext.Current), то получаете доступ к объекту IPrincipal, представляющему контекст безопасности текущего пользователя.

Интерфейс IPrincipal определяет единственное свойство по имени Identity, которое извлекает объект IIdentity, представляющий информацию о текущем пользователе. Интерфейс IPrincipal также определяет единственный метод по имени IsInRole(), позволяющий вам проверить, является ли текущий пользователь членом специфической роли.

Приведем пример, использующий метод IsInRole() для проверки того, является ли текущий пользователь сленом роли под названием Admin:

При использовании аутентификации Windows или аутентификации форм объект-принципал создается автоматически. Однако этот объект можно также создать “на лету”, с информацией о пользователе и роли, извлеченной из другого места, — такого, как пользовательская база данных. Примеры обоих способов вы сможете найти в последующих главах из этой книги.

Интерфейс IIdentity

Подобно интерфейсу IPrincipal, интерфейс IIdentity представляет соглашение, не зависящее от используемой схемы аутентификации. Все объекты идентичности должны реализовывать IIdentity.

Интерфейс IIdentity определяет базовую информацию, необходимую для представления текущего пользователя. Как минимум, это включает в себя три следующих свойства, доступных только для чтения:

  • AuthenticationType: Возвращает тип используемой аутентификации, как строку (forms, Passport, NTLM или пользовательский тип аутентификации)
  • IsAuthenticated: Возвращает булево значение, указывающее на то, был ли пользователь аутентифицирован (true), или же он является анонимным (false)
  • Name: Возвращает имя текущего пользователя в виде строки.

Вы можете обращаться к объекту IIdentity, представляющему текущего пользователя, через объект IIPrincipal. Приведем пример, использующий эту технику для проверки того, был ли пользователь аутентифицирован:

Тип объекта идентичности зависит от типа используемой аутентификации. Всего четыре класса идентичности включены в .NET Framework:

  • System.Web.Security.FormsIdentity: Представляет пользователя, который зарегистрировался, используя аутентификацию форм.
  • System.Security.Principal.WindowsIdentity: Представляет бюджет пользователя Windows.
  • System.Web.Security.PassportIdentity: Представляет класс для использования модулем PassportAuthenticationModule.
  • System.Security.Principal.GenericIdentity: Представляет обобщенную идентичность пользователя (Вы можете использовать это для создания идентичности при создании собственной системы аутентификации).

Программные интерфейсы Membership и Roles API

Как вы увидите в главе 20. Аутентификация с помощью форм, при использовании аутентификации форм, вы должны аутентифицировать своих пользователей по специальному собственному хранилищу. Это значит, что вы должны сделать намного больше, чем просто создать базовую страница регистрации для проверки имен и паролей пользователей. Конечно, вам нужен способ управления пользователями и назначения их на роли. В ASP.NET 1.x вам нужно было самостоятельно создавать такие инструменты управления и программные компоненты. ASP.NET 2.0 представляет эту инфраструктуру через программные интерфейсы Membership API, Roles API и Profiles API.

Membership API

Membership API – полная система управления пользователями. Она помогает вам создавать, редактировать и удалять пользователей, а также включает функциональность восстановления паролей. Этот API можно применять для программного выполнения этих управленческих задач, или же использовать Web-ориентированный инструмент конфигурирования ASP.NET для графического администрирования ваших пользователей. Благодаря этой инфраструктуре, вы можете сэкономить много времени, поскольку более нет необходимости создавать свои собственные приложения администрирования пользователей, потому что они уже существуют в каркасе ASP.NET 2.0. Более того, он включает также функциональность валидации комбинаций имен и паролей, вводимых пользователями.

Подробнее о Membership API вы узнаете из главе 21. Интерфейс Membership API.

Roles API

Во многих случаях авторизация выполняется для групп пользователей, называемых ролями. Одна роль может включать в себя множество пользователей, и один пользователь может назначен на много ролей. ASP.NET 2.0 включает готовый к применению программный интерфейс, позволяющий при необходимости назначать пользователей на роли. Опять же, вы можете делать это программно через Roles API, или же с помощью утилиты конфигурирования ASP.NET.

В главе 23. Авторизация и роли вы изучите все детали применения Roles API в ваших приложениях.

Profiles API

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

Опять же, ASP.NET 2.0 включает готовую к использованию инфраструктуру управления профилями в ваших приложениях.

Из главы 24. Профили вы узнаете, как использовать Profile API в вашем приложении.

Cервер приложений Internet Information Services (IIS)

Администраторам и разработчикам Web-приложений необходим надежный, легкоуправляемый, высокопроизводительный и защищенный Web-сервер. В Internet Information Services (IIS) 6.0 и Microsoft ® Windows ® Server 2003 появилось много новых возможностей, обеспечивающих надежность, доступность, управляемость, масштабируемость и безопасность сервера Web- приложений.

IIS 6.0 — ключевой компонент платформы приложений Windows Server 2003 — представляет собой интегрированный набор сервисов и средств, обеспечивающих разработку и развертывание высокопроизводительных Web-сайтов, Web-приложений и Web-сервисов.

Роль сервера приложений в семействе продуктов Windows Server 2003 сочетает в себе следующие серверные технологии:

1. Internet Information Services (IIS) 6.0 Информационные службы Интернета (IIS) 6.0. Они являются полноценным веб-сервером, оптимизированным для запуска веб-приложений и служб на узле.

2. Microsoft .NET Framework;

Это компьютерная платформа, разработанная для упрощения разработки приложений в распределенной среде Интернета. Microsoft .NET Framework предоставляет среду для объектно-ориентированного программирования, гарантирующую безопасное выполнение кода, и исключает затруднения, связанные с обеспечением быстродействия сценариев. В Microsoft .NET Framework входят два основных компонента:

· общая языковая среда выполнения

· библиотека классов Microsoft .NET Framework.

ASP.NET использует общую языковую среду выполнения для предоставления таких базовых служб, как управление памятью, управления потоками и удаленный доступ, совмещенный со строгой системой защиты и другими формами, обеспечивающими безопасность и устойчивость кода. Основным назначением этой среды является управление кодом. Код, предназначенный для работы в ней, называется управляемым, а код, не предназначенный для работы в ней — неуправляемым.

Библиотека классов Microsoft .NET Framework — собрание повторно используемых объектов, которые можно применять при создании приложений ASP.NET.

3. ASP.NET это часть Microsoft .NET Framework. ASP.NET представляет собой откомпилированную среду, основанную на технологии .NET. Имеется возможность создавать приложения на любом совместимом с .NET языке, в том числе на Visual Basic .NET, C# и JScript .NET. Кроме того, возможности среды .NET Framework, в том числе управляемая общая языковая среда времени выполнения, безопасность типов и наследование, доступны любому приложению ASP.NET

4. ASP; Active Server Pages (ASP) — активные серверные страницы. Страницы ASP являются средой создания серверных сценариев для разработки динамических интерактивных приложений веб-серверов. Они позволяют разработчикам объединять нужным образом страницы в формате HTML, команды сценариев и компоненты COM для создания мощных и гибких веб-приложений.

5. UDDI-сервисы; UDDI (Universal Description, Discovery and Integration) — это промышленный стандарт публикации и поиска сведений о веб-службах. В некоторые продукты семейства Windows Server 2003 включаются службы UDDI, веб-службы, обеспечивающие использование возможностей UDDI на предприятиях или в организациях. Службы UDDI являются стандартной веб-службой XML. Они позволяют разработчикам предприятия эффективно изучать, открывать совместный доступ и повторно использовать веб-службы непосредственно через средства разработки. Они не включены в Windows Server 2003, Web Edition. Кроме того, Windows Server 2003, Standard Edition поддерживает только изолированную установку служб UDDI. Поддержка распределенной установки доступна в Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition. При изолированной установке служб UDDI компоненты веб-сервера UDDI и баз данных UDDI устанавливаются на один компьютер. При распределенной установке компоненты UDDI распределены по нескольким серверам.

6. COM+; расширение модели объектных компонентов (COM). COM+ основано на интегрированных службах и свойствах COM, облегчая разработчикам создание и использование компонентов программного обеспечения на любом языке и используя любые средства.

7. Microsoft Message Queuing (MSMQ). Сервер очередей сообщений Microsoft. Очередь сообщений создается для взаимодействия приложений в распределенной среде (на разных компьютерах). Особенность MSMQ в том, что компьютеры не обязательно должны быть одновременно в сети. То есть можно отправить сообщение, можно получить, а за всем этим следит сервер MSMQ.

Таким образом, сервер приложений позволяет разработчикам Web-приложений и администраторам осуществлять хостинг динамических приложений, например для управления базой данных приложений Microsoft ASP.NET, не надо устанавливать на сервере дополнительное программное обеспечение.

В Windows Server 2003 сервер приложений можно настроить двумя способами: через мастер Configure Your Server или из приложения Add/Remove Components.

Архитектура обработки запросов в IIS 6.0

Сложность кода Web-сайтов и приложений постоянно возрастает.

Динамические Web-сайты и приложения могут содержать неидеальный код, приводящий к утечкам памяти или вызывающий ошибки нарушения доступа к памяти.

Таким образом, Web-сервер должен выполнять роль активного диспетчера среды выполнения приложения, автоматически определяя ошибки приложения и реагируя на них.

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

В IIS 6.0 реализован новый вид отказоустойчивой архитектуры обработки запросов, которая предоставляет собой стабильную исполняющую среду с активным управлением.

Также кардинально повышена надежность и масштабируемость благодаря применению модели изоляции процесса (называемую моделью изоляции рабочего процесса ).

В дополнение увеличена производительность за счет поддержки кэширования и очередей запросов в режиме ядра.

В IIS 6.0 заложены две новые концепции

1. пулы приложений (application pools)

2. рабочие процессы (worker processes).

Пулы приложений применяются для управления набором Web-сайтов и приложений. Каждый пул приложения соответствует одной очереди запросов в HTTP.sys и одному или более Windows-процессам, обрабатывающим эти запросы.

IIS 6.0 поддерживает до 2 000 пулов приложений.

Одновременно могут работать несколько таких пулов. Например, сервер может выполнять приложение для учета кадров в одном пуле и бухгалтерское приложение — в другом.

То есть Интернет-провайдер (Internet Service Provider, ISP) может запускать Web-сайты и приложения одного клиента в одном пуле приложений, а Web-сайты второго клиента — в другом.

Пулы приложений отделяются друг от друга границами процессов в Windows Server 2003. Таким образом, приложения в одном пуле не влияют на приложения в другом; кроме того, запросы к приложениям нельзя перенаправлять из одного пула в другой.

Рабочий процесс обслуживает запросы к Web-сайтам и приложениям в пуле. Вся обработка Web-приложений, аутентификация и авторизация, выполняется новой библиотекой DLL Web – сервиса, которая загружается в один или несколько рабочих хост-процессов. Исполняемый файл рабочего процесса называется W3wp.exe.

В предыдущей версии IIS (IIS 5.0) один процесс, Inetinfo.exe, выполнял функции главного процесса Web-сервера. Он перенаправлял запросы к «внепроцессным» приложениям, размещенным в процессах DLLHost.exe.

IIS 6.0, напротив, состоит из двух новых компонентов:

1. Компонент WWW Service Administration and MonitoringДиспетчер пользовательского режима, управляющий работой сервера и следящий за выполнением кода приложения. Этот компонент не загружает и не исполняет код приложения. Другими словами компонент пользовательского режима, предназначенного для администрирования и мониторинга.

2. Стек HTTP режима ядра (HTTP.sys), который помещает в очередь и разбирает входящие HTTP-запросы, а также кэширует и возвращает контент сайта и приложения. HTTP.sys не загружает код приложения — он просто анализирует и перенаправляет запросы.

Таким образом, HTTP.sys в IIS принимает запросы и помещает их в очереди.

Каждая очередь запросов соответствует одному пулу приложений.

Так как HTTP.sys не выполняет код приложений, на него не влияют ошибки в коде пользовательского режима, обычно нарушающие нормальную работу Web-сервера.

В случае ошибки в приложении HTTP.sys продолжает принимать и помещать в очередь новые запросы до одного из следующих событий:

1. перезапуска процесса, который начнет принимать запросы,

2. исчерпания очередей,

3. отсутствия места в очередях

4. остановки администратором самого Web-сервиса.

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

Такая архитектура позволяет IIS 6.0 отделять операции Web-сервера от выполнения кода Web-сайта и приложения без ухудшения производительности.

Настройка сервера и управление рабочим процессом

При инициализации часть сервиса WWW, отвечающая за конфигурирование, использует хранящуюся в памяти конфигурационную метабазу для инициализации таблицы маршрутизации (routing table) пространства имен HTTP.sys.

Каждая запись в этой таблице содержит информацию, необходимую для перенаправления входящих URL пулу приложений, где находится сопоставленное с данным адресом приложение.

Эти предварительные действия уведомляют HTTP.sys о наличии пула приложений, отвечающего на запросы к конкретной части пространства имен, и о том, что HTTP.sys может потребовать запуска рабочего процесса для пула приложений при поступлении запроса.

Все предварительные действия выполняются до того, как HTTP.sys приступает к перенаправлению запросов индивидуальным процессам.

По мере добавления новых приложений и их пулов Web-сервис настраивает HTTP.sys на прием новых адресов, создает новые очереди запросов для новых пулов приложений и указывает, куда перенаправлять новые URL. Для динамического изменения информации о маршрутизации перезапуск сервиса не требуется.

В роли управляющего рабочим процессом компонент WWW Service Administration и Monitoring отвечает за управление жизненным циклом рабочего процесса, обрабатывающего запросы.

Это подразумевает принятие решений о запуске, использовании и перезапуске рабочего процесса в случае, если он не может обслуживать дальнейшие запросы (заблокирован). Кроме того, он ведет мониторинг рабочего процесса и способен обнаружить его неожиданное завершение.

Режим изоляции рабочего процесса

IIS 6.0 предоставляет новый режим изоляции приложения для управления обработкой Web-сайтов и приложений — режим изоляции рабочего процесса.

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

Приложения можно полностью изолировать друг от друга, в этом случае ошибка в одном приложении не влияет на другое приложение в ином процессе.

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

Первым делом HTTP.sys отправляет запросы, адресованные к Web-сайтам и приложениям, соответствующим очередям пулов приложений.

Затем рабочий процесс, обслуживающий пул приложений, извлекает запросы напрямую из очереди приложений в HTTP.sys. Такая модель позволяет избавиться от лишних переключений процессов, возникающих при отправке запросов внепроцессному DLLHost.exe и обратно (как в IIS 4.0 и 5.0), что увеличивает производительность.

Важно отметить, что в IIS 6.0 нет понятия внутрипроцессного приложения. Все необходимые приложению сервисы периода выполнения в равной степени доступны в любом пуле приложений.

Подобная архитектура не дает сбойному Web-сайту или приложению нарушить работу другого Web-приложения или самого сервера. В IIS 6.0 теперь можно выгрузить внутрипроцессный компонент, не останавливая Web-сервис.

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

Дополнительное преимущество — возможность задействовать другие сервисы операционной системы, доступные на уровне процесса [например управление распределением процессорного времени (CPU throttling)] для пулов приложений. Кроме того, архитектура Windows Server 2003 поддерживает гораздо больше параллельных процессов, чем в предыдущих операционных системах.

Режим изоляции рабочего процесса не дает одному приложению или сайту остановить другие приложения.

Помимо этого, разделение приложений или сайтов на отдельные рабочие процессы упрощает многие задачи управления, например:

включение/выключение сайта или приложения (независимо от остальных работающих сайтов или приложений),

· изменение используемого приложением компонента,

· наблюдение за счетчиками производительности,

· регулирование ресурсов, выделяемых приложению.

Режим изоляции рабочего процесса в IIS 6.0 имеет следующие особенности.

1. Кэширование в режиме ядра.. В IIS 6.0 кэширование в режиме ядра осуществляется как в режиме изоляции рабочего процесса, так и в режиме изоляции IIS 5.0 (см. ниже). В качестве единой точки приема всех входящих (серверных) HTTP-запросов HTTP.sys создает высокопроизводительный канал связи для серверных HTTP-приложений и обеспечивает общее управление соединениями, регулирование полосы пропускания и протоколирование на стороне Web-сервера. IIS 6.0 основан на HTTP.sys и специально настроен на увеличение производительности Web-сервера. Кроме того, в некоторых случаях HTTP.sys напрямую обрабатывает запросы в ядре. Как статический, так и динамический контент Web-сайтов и приложений может помещаться в кэш HTTP.sys для уменьшения времени ответа.

2. Четкое разделение между пользовательским кодом и сервером.Весь пользовательский код обрабатывается рабочими процессами, полностью изолированными от ядра Web-сервера. Это важное усовершенствование по сравнению с IIS 5.0, так как ISAPI зачастую выполняются внутрипроцессно в ядре Web-сервера. Если ISAPI, загруженный в рабочий процесс, вызывает сбой или нарушение доступа к памяти, останавливается лишь рабочий процесс, выполняющий ISAPI. Тем временем сервис WWW создает новый рабочий процесс, заменяющий рухнувший. На остальные рабочие процессы это не оказывает никакого влияния.

3. Множественные пулы приложений.В IIS 5.0 приложения можно объединять во внепроцессный пул, но только в один, который выполняется в среде DLLHost.exe. Когда IIS 6.0 работает в режиме изоляции процессов, администраторы могут создать до 2 000 пулов приложений, причем каждый из них можно конфигурировать раздельно.

4. Улучшенная поддержка распределителей нагрузки. Благодаря пулам приложений IIS 6.0 поддерживает физическое разделение приложений. IIS 6.0 способен автоматически взаимодействовать с распределителями нагрузки (load balancers) или с коммутаторами для блокирования трафика к проблемному приложению, параллельно продолжая принимать запросы к другим приложениям. В IIS 6.0 также встроена модель расширения, позволяющая генерировать события и команды при обнаружении сбоя в конкретном приложении. Такая конфигурация позволят распределителям нагрузки и коммутаторам автоматически блокировать трафик к проблемным приложениям, не препятствуя запросам к работающим.

5. Web-сады (Web gardens).На обслуживание запросов, адресованных одному пулу приложений, можно настроить несколько рабочих процессов. По умолчанию каждому пулу соответствует один рабочий процесс. Однако пул можно настроить так, чтобы ему соответствовал набор из N эквивалентных рабочих процессов, разделяющих нагрузку. Такая конфигурация называется Web-садом. HTTP.sys распределяет запросы между рабочими процессами в группе. Распределение запросов основано на принципе карусели. Преимущества Web-садов в том, что, если один рабочий процесс замедляется, например, когда подсистема выполнения сценариев перестает отвечать, прием и обработка запросов продолжается остальными рабочими процессами.

6. Слежение за состоянием. Компонент WWW Service Administration and Monitoring следит за состоянием приложений, периодически проводя тестовый опрос рабочих процессов, чтобы выяснить, не заблокированы ли они. В случае блокировки рабочего процесса сервис WWW завершает рабочий процесс и создает вместо него новый. Сервис WWW поддерживает коммуникационный канал с каждым рабочим процессом и всегда в состоянии определить сбой в рабочем процессе по обрыву канала.

7. Привязка к процессорам (processor affinity). Рабочие процессы можно привязать к конкретным процессорам, чтобы увеличить частоту попаданий в кэш процессора (уровня L1 или L2). Реализация привязки к процессорам приводит к тому, что рабочие процессы IIS 6.0 выполняются на конкретных процессорах, и эта привязка распространяется на все рабочие процессы, обслуживающие Web-сайты и приложения в каком-либо пуле. Привязку к процессорам можно использовать в сочетании с Web-садами, выполняемым на многопроцессорных компьютерах, где под конкретные пулы приложений выделены кластеры процессоров.

8. Сопоставление сайтов и приложений с пулами приложений. В IIS 6.0, как и в IIS 5.0, приложения определяются как пространства. Сайты по умолчанию считаются простыми приложениями, в которых пространство имен сконфигурировано как приложение. Пул приложений можно настроить на обслуживание от одного Web-приложения до множества приложений и сайтов. Чтобы поместить приложение в пул, следует использовать IIS Manager или напрямую модифицировать метабазу.

9. Запуск по требованию. Пулы приложений позволяют запускать процессы, обслуживающие группу пространства имен по требованию, т. е. при первом запросе к URL, который является частью этого пространства имен. Компонент WWW Service Administration and Monitoring выполняет запуск процесса по требованию и в целом контролирует жизненный цикл рабочих процессов.

10. Время ожидания в простое. Пул приложений можно настроить на остановку собственных рабочих процессов, если они простаивают в течение определенного периода. Это нужно для освобождения неиспользуемых ресурсов. При необходимости для данного пула приложений запускаются дополнительные рабочие процессы (см. далее «Запуск по требованию»).

11. Быстрая защита от сбоев. При сбое рабочий процесс обрывает коммуникационный канал с компонентом WWW Service Administration and Monitoring. Последний обнаруживает это и принимает меры, обычно включающие запись события в журнал и перезапуск рабочего процесса. Кроме того, IIS 6.0 можно настроить на автоматическую блокировку рабочего процесса, если в пуле приложений возникает определенное число сбоев за заданный период. Такое поведение называется быстрой защитой от сбоев (rapid-fail protection). Быстрая защита от сбоев переводит пул приложений в состояние «не обслуживается», и HTTP.sys немедленно возвращает сообщение 503 (Service Unavailable) на любые запросы к частям этого пространства имен, в том числе на запросы, уже помещенные в очередь этого пула приложений.

12. Отбрасывание (orphaning) рабочих процессов.Режим изоляции рабочего процесса можно настроить на отбрасывание рабочих процессов, которые считаются зависшими. Например, если рабочий процесс не отвечает на тестовые опросы в течении определенного периода, сервис WWW обычно завершает его и запускает новый. А если включено отбрасывание, он оставляет зависший процесс в памяти и запускает новый. Кроме того, сервис WWW можно настроить на выполнение команды над рабочим процессом (например на подключение отладчика) при его отбрасывании.

13. Повторное использование рабочих процессов.Сейчас многие организации страдают от проблем, связанных с тем, что Web-приложения вызывают утечки памяти, плохо написаны или содержат непонятные ошибки. Это вынуждает администраторов периодически перезапускать Web-серверы. В предыдущих версиях IIS способа перезапустить Web-сайт, не прерывая работу всего сервера, не было. Режим изоляции рабочего процесса можно настроить на периодический перезапуск рабочих процессов в пуле приложения для борьбы со сбойными приложениями. Рабочие процессы можно настроить на перезапуск в соответствии со следующими критериями: истекшим временем, количеством обслуженных запросов, временем суток, использованием виртуальной и физической памяти, а также по требованию. Когда рабочий процесс считает необходимым выполнить перезапуск, он уведомляет WWW-сервис, который в свою очередь дает команду на завершение существующим рабочим процессам и выделяет заданное время на обработку оставшихся запросов. Одновременно сервис WWW создает замещающий рабочий процесс для той же группы пространства имен, и новый рабочий процесс запускается до завершения работы старого. Это предотвращает перебои в обслуживании. Старый рабочий процесс поддерживает связь с HTTP.sys для завершения обработки своих запросов, а затем либо нормально завершает работу, либо его работа завершается извне, если он не остановился по истечении заданного периода.

14. Режим изоляции IIS 5.0 Некоторые приложения не совместимы с режимом изоляции рабочего процесса IIS 6.0, например приложения-фильтры, читающие необработанные данные, или приложения, полагающиеся на выполнение в Inetinfo.exe или DLLHost.exe. Поэтому IIS 6.0 способен работать в другом режиме изоляции, который называется режимом изоляции IIS 5.0 и обеспечивает совместимость. Использование этого режима напоминает работу с самим IIS 5.0, так как в нем присутствуют те же основные процессы пользовательского режима. В частности, есть те же методы изоляции приложений (низкий, средний в пуле и высокий), а Inetinfo.exe — по-прежнему главный процесс, через который проходят все запросы.

Система безопасности IIS

Система безопасности IIS использует преимущества стандартов безопасности Интернет, поддерживаемых Windows.

Fortezza(американский правительственный стандарт безопасности). Он удовлетворяет архитектуре безопасности, поддерживая механизм шифрования, обеспечивающий конфиденциальность, целостность и подлинность сообщений, аутентификацию, контроль доступа к сообщениям, компонентам и системам. Эти функции реализуются как при помощи ПО сервера и браузера, так и при помощи аппаратных средств.

Secure Sockets Layer (SSL). Протоколы безопасности SSL широко используются Web-браузерами и серверами для аутентификации, конфиденциальности и целостности сообщений. При помощи функций безопасности SSL можно проверить целостность содержания Web-сервера, реквизиты пользователей и шифровать передаваемые по сети сообщения.

Transport Layer Security (TLS). TLS основан на SSL. Он помогает выполнять безопасную аутентификацию пользователей, а независимым программистам позволяет создавать поддерживающий TLS код, способный обмениваться зашифрованной информацией с другим процессом без ознакомления с кодом, созданным другим программистом. Кроме того, TLS является каркасом для построения новых методов шифрования с открытым ключом и шифрования больших объемов данных. TLS служит и для повышения производительности, уменьшая сетевой трафик и предлагая схему кэширования сессий, позволяющую сократить количество соединений, устанавливаемых «с нуля».

PKCS #7. Этот протокол описывает формат зашифрованных данных, например цифровых подписей или цифровых конвертов.

PKCS #10. Этот протокол описывает формат посылаемых сертификационным центрам (Certificate Authority, CA) запросов на получение сертификата.

Обычная проверка подлинности. Обычная аутентификация — стандартный метод сбора информации об именах пользователей и паролях. Она посылает пароли по сети в формате Base64 Encoded. К ее достоинствам можно отнести то, что она является частью спецификации HTTP 1.0 и поэтому поддерживается большинством браузеров. Однако обычная аутентификация имеет существенный минус — использующие ее Web-браузеры пересылают пароли в незашифрованном виде.

Краткая проверка подлинности. Она обладает теми же возможностями, что и обычная но передает аутентификационные сведения иначе.

Они проходят через одношаговый процесс — хеширование (hashing). Результат этого процесса называется хешем (hash), или выборкой сообщения (message digest). Исходный текст не может быть расшифрован из хеша. Перед хешированием к паролю добавляется дополнительная информация генерируемая сервером, поэтому никто не сможет перехватить хеш пароля и с его помощью выдавать себя за истинного клиента. Краткая аутентификация основана на методологии общего секретного пароля. Она структурирована для использования несколькими прокси-серверами. Краткая аутентификация поддерживается не всеми обозревателями. Если не поддерживающий краткую аутентификацию браузер пошлет запрос на сервер, требующий именно этот способ аутентификации, сервер не будет обрабатывать запрос и сообщит клиенту об ошибке.

Путем проверки подлинности можно удостовериться в личности каждого клиента, запрашивающего доступ к Web-узлам.

IIS поддерживает для служб HTTP и FTP:

1. анонимную проверку подлинности HTTP и FTP;

2. обычную проверку подлинностиHTTP и FTP;

3. краткую проверку подлинности для доменов Windows 2000 и браузеров, поддерживаю щих этот способ аутентификации, реализованныйв HTTP I.I;

4. интегрированную проверку подлинности Windows (толькоHTTP).

Отладка приложения ASP.NET, размещенного на IIS: прикрепление процесса и выяснение, какой процесс прикрепить

Written on 03 Июля 2013 . Posted in ASP.NET

ОГЛАВЛЕНИЕ

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

Оглавление

  • Обзор
  • Отладка ASP . NET по сравнению с отладкой IIS
  • Что такое рабочий процесс?
  • Пул приложений
    • Что такое пул приложений?
    • Стандартный пул приложений
    • Создание собственного пула приложений
    • Назначение сайта пулу приложений
  • Как начать?
  • Какой процесс прикрепить?
  • Как прикрепить конкретный рабочий процесс, когда выполняется несколько процессов.
    • Получение списка выполняющихся рабочих процессов
    • Прикрепление нужного процесса
  • Вывод

Обзор

Обычно веб-приложение Asp.Net отлаживается из Visual Studio. Visual Studio имеет собственный механизм ASP.Net, способный запускать и отлаживать веб-сайты внутри visual studio. Но если ваш сайт размещен на IIS, и вы хотите отладить этот сайт, как вы будете его отлаживать? При размещении сайтов на IIS worker process(w3wp.exe) используется для запуска веб-приложения. Надо прикрепить конкретный процесс в Visual Studio, чтобы отлаживать приложение. Данная статья описывает общую идею отладки приложения с помощью прикрепленного процесса. Она также рассматривает рабочий процесс, пул приложений и выбор конкретного процесса, если на IIS выполняется несколько рабочих процессов, с помощью iisapp.vbs. Надеемся, вам понравится эта статья, и вы дадите ценные советы и отзывы.

Отладка ASP.NET по сравнению с отладкой IIS

Visual studio имеет встроенный механизм отладки, отлаживающий код при запуске приложения из Visual Studio. Если при разработке сайтов надо отладить код, ставятся точки останова и производится отладка. [Примечание: В этой статье не описан способ установки режима отладки]. При запуске приложения выполнение кода останавливается, когда приходит определенная точка останова. Это очень просто, поскольку, когда приложение ASP.NET запускается из Visual studio, его контролирует механизм Asp.Net, встроенный в Visual Studio. Если вы хотите проверить, какой процесс запускается для отладки, запустите веб-приложение из Visual Studio и получите такое всплывающее уведомление, как ниже:

Рисунок. Отображение всплывающего уведомления при запуске отладки из Visual Studio

Уведомление показывает, что процесс запускается для выполнения приложения ASP.NET. Дважды щелкните по иконке. Появится всплывающее окно и покажет характеристики.

Рисунок. Характеристики процесса сервера разработки

За выполняющимся процессом находится «WebDev.WebServer.Exe». При нажатии F5 для запуска этот процесс начинает выполнять приложение Asp.Net. Если вы хотите запустить приложение из командной строки, выполните следующие шаги.

Шаги:
1. Открыть командную строку Visual Studio
2. Запустить Webdev.WebServer

Появится следующий экран. Смотрите раздел примеров.

Теперь вернемся к отладке в IIS. IIS появляется при развертывании или размещении сайта на сервере. После развертывания сайтов на IIS, если надо отлаживать сайт из него, нельзя делать это непосредственно в Visual studio. IIS имеет свой собственный рабочий процесс, следящий за выполнением и поддержкой развернутого веб-приложения. Характеристики рабочего процесса описаны в следующем разделе. Поэтому, если мы имеем выполняющийся процесс на IIS, и нам надо отладить приложение, прежде всего надо прикрепить правильный процесс в Visual Studio. Перед разбором способа прикрепления процесса рассмотрим рабочий процесс и пул приложений.

Что такое рабочий процесс?

Рабочий процесс (w3wp.exe) запускает приложение ASP.Net в IIS. Вся функциональность ASP.Net выполняется внутри рабочего процесса. Когда на сервер приходит запрос от клиента, рабочий процесс отвечает за генерацию запроса и ответа. Он также хранит данные сессии InProc. При перезапуске рабочего процесса теряется состояние рабочего процесса. Дополнительную информацию сморите в статье Низкоуровневое рассмотрение архитектуры ASP.NET

Пул приложений

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

Стандартный пул приложений

Имя стандартного приложения IIS 6.0 — «DefaultAppPool». После размещения сайта на IIS при проверке свойств Виртуальной директории вы сможете увидеть, что:
1. Start(пуск) – Run(выполнить) — Inetmgr
2. Развернуть «DefaultWebSites» или Другие веб-сайты, где вы создали Виртуальную директорию
3. Щелкнуть правой кнопкой мыши по Виртуальная директория
4. Щелкнуть по Свойства

Появится следующий экран. Сейчас свойства виртуальной директории показывают имя пула приложений, назначенного выбранному сайту.

Чтобы проверить список всех пулов приложений в IIS, разверните Узел пула приложений на сервере IIS.

Рисунок. Стандартный пул приложений

Теперь все до единого пулы приложений должны иметь минимум один рабочий процесс, следящий за работой сайта, связанного с пулом приложений. Щелкните правой кнопкой мыши по пулу приложений – перейдите во вкладку производительности, проверьте нижнюю часть вкладки, там есть раздел сетевого сада, и по умолчанию рабочий процесс равен 1. Пул приложений, содержащий более одного рабочего процесса, называется Web Garden(сетевой сад).

Создание и назначение пула приложений

Откройте консоль IIS, щелкните правой кнопкой мыши по папке пула приложений > Создать New(новый)

Введите Идентификатор пула приложений и нажмите Ok.

Теперь щелкните правой кнопкой мыши по Виртуальной директории и назначьте только что созданное приложение этой Виртуальной директории.

Итак, эти веб-сайты будут запускаться независимо в StateServerAppPool. Следовательно, любая проблема, связанная с другим приложением, не влияет на ваше приложение. Это основные преимущества создания пула приложений отдельно.

Как начать?

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

Был создан один веб-сайт под именем sampleWebSite и размещен на локальном IIS. Ниже показан вывод страницы по умолчанию.

Рисунок. Пример веб-сайта

Какой процесс прикрепить?

Как уже было сказано, имя процесса — w3wp.exe, следовательно, можно проверить его из менеджера задач, выполняется рабочий процесс или нет

Рисунок. Менеджер задач показывает выполняющийся процесс

Теперь прикрепим процесс. Перейдите в Отладка > Прикрепиться к процессу

Рисунок. Открыть окно прикрепления процесса

После нажатия на Прикрепиться к процессу появится следующий экран,

Рисунок. Выполняется один рабочий процесс

Теперь видно, что выполняется тот же самый рабочий процесс. Надо прикрепить этот процесс. Выберите «Процесс» и нажмите кнопку «Прикрепить». После проверки двух рисунков ниже

Рисунок: 1) Процесс успешно прикреплен 2) Процесс не прикреплен

Заметили ли вы знак точки останова? Если рабочий процесс прикрепился успешно, знак точки останова выполнения кода должен быть четким, в противном случае он должен иметь предупреждающую иконку. Для одного рабочего процесса сценарий не свойствен. Но если на IIS выполняется несколько рабочих процессов, возникает беспорядок. Это рассмотрено в следующем разделе.

Теперь при нажатии на кнопку отладки веб-страницы выполнение кода остановится в точке останова.

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

Как прикрепить конкретный рабочий процесс, когда выполняется несколько процессов?

Когда произойдет этот сценарий? Если несколько сайтов размещены на IIS, и эти сайты имеют там собственный пул приложений. Теперь несколько пулов приложений означают, что выполняется несколько рабочих процессов.

Мы имеем 3 пула приложений в IIS:
• Стандартный пул приложений
• Обобщенный пул приложений
• Пул приложений сервера состояний

Сейчас SampleWebSite связан с defaultAppPool, и мы хотим прикрепить процесс для отладки SampleWebSite. Выполните такой же шаг для открытия окон прикрепления процесса

Рисунок. Список рабочих процессов

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

Рисунок. Процесс не прикрепился правильно

Получение списка выполняющихся рабочих процессов

Ниже даны советы по решению указанной проблемы.
• Пуск > Выполнить > Cmd
• Перейти в Windows > System32
• Выполнить cscript iisapp.vbs и ждать вывода.

Вы получите список выполняющихся рабочих процессов, PID(идентификаторов процессов) и имя пула приложений.

Рисунок. Список выполняющихся рабочих процессов с PID и именем пула приложений

Прикрепление правильного процесса

Отсюда вы можете легко определить имя пула приложений и идентификатор процесса. Снова вернемся в VS > Прикрепить процесс. Теперь вы знаете, что идентификатор процесса для стандартного пула приложений равен 1772, следовательно, Прикрепить процесс.

Рисунок. Прикрепить процесс для отладки

Теперь наслаждайтесь отладкой.

Рисунок. Точка останова готова

Вывод

Иногда приходится отлаживать приложение, размещенное на IIS. Для этого надо прикрепить выполняющийся рабочий процесс к коду Visual Studio. Если на сервере IIS выполняется несколько рабочих процессов, мы можем определить правильный рабочий процесс с помощью команды cscript iisapp.vbs. Надеемся, статья поможет новичкам, испытывающим затруднения с отладкой приложения, размещенного на IIS.

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

Отдельные пулы приложений для приложений ASP.net в IIS

Я прочитал рекомендации о том, что мы должны создать отдельные пулы приложений для каждого приложения asp.net на нашем сервере Win2008.

У нас около 20 приложений, которые будут на одном сервере. Я знаю, что это создаст 20 отдельных рабочих процессов, которые кажутся очень расточительными.

Хорошо ли создавать отдельные пулы приложений для каждого приложения?

  • AppPools может работать как разные идентификаторы, поэтому вы можете ограничить права доступа таким образом.
  • Вы можете назначить различную идентификацию для каждого пула приложений, чтобы при запуске диспетчера задач вы знали, какой именно w3wp.exe является.
  • Вы можете повторно использовать/перезапустить один пул приложений, не затрагивая сайты, запущенные в разных пулах приложений.
  • Если у вас есть веб-сайт с утечкой памяти или, как правило, неправильная работа, вы можете поместить его в пул приложений, чтобы он не влиял на другие веб-сайты.
  • Если у вас есть сайт с очень интенсивным процессором (например, изменение размера фотографий), вы можете разместить его в своем собственном пуле приложений и отключить его использование ЦП.
  • Если у вас есть несколько веб-сайтов, каждая из которых имеет свою собственную базу данных SQL, вы можете использовать аутентификацию активного каталога вместо хранения имен пользователей/паролей в web.config.

Раньше у меня было 58 веб-сайтов и 17 старых классических веб-сайтов ASP на одном сервере IIS7.5 с использованием отдельных пулов приложений для каждого сайта. Я заметил, что сжатие IIS начало прерываться с перерывами, в результате чего таблицы стилей были повреждены примерно в 5% случаев. Глядя на задачу mamanger на сервере, я мог видеть, что сервер приближается к нему с ограничением по 4 ГБ. Каждый процесс w3wp.exe берет что-то до 100 МБ памяти в зависимости от того, сколько трафика он получает. Затем я переместил все веб-сайты в 2 пула приложений (один для веб-сайтов .net 4 и один для старых классических сайтов ASP), а общая память, используемая после этого, снизилась с 3,8 ГБ до чуть менее 2,8 ГБ — сэкономила мне более 1 ГБ памяти пространства на сервере. После изменения (и оставление сервера на пару часов, чтобы вернуться к нормальному уровню трафика), процессы w3wp использовали 300 МБ для всех веб-сайтов .net и 20 МБ для классических веб-сайтов ASP. Я могу снова включить сжатие IIS без проблем.

Использование отдельных пулов APP — отличная идея для многих причин, упомянутых другими сообщениями выше, но это также по моему опыту приводит к значительно более высоким издержкам памяти, если вы размещаете большое количество веб-сайтов на одном сервере.

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

Как установить Asp.Net и как зарегистрировать Asp.Net в IIS

Сегодня мы поговорим о том, как перенести Asp.Net-приложение из среды разработки Visual Studio на веб-сервер IIS.

При запуске в Visual Studio веб-приложение разворачивается на Visual Studio Development Server. Это внутренний веб-сервер, работающий локально в операционной системе. Он создан специально для запуска сайтов на локальной машине и не обслуживает запросы с других компьютеров. Иными словами, другой пользователь со своего компьютера не будет видеть наш сайт.

Чтобы сайт стал доступен другим пользователям, нужно разместить его на веб-сервере IIS. Это один из основных веб-серверов, использующихся на данный момент, и позволяющий запускать веб-сайты на платформе Asp.Net.

С другой стороны, чтобы наш сайт функционировал, необходимо установить .Net Framework и зарегистрировать Asp.Net в IIS. Об этом и пойдет речь.

Установка Asp.Net

На сервере, где будет располагаться сайт, необходимо установить .Net Framework. Это набор файлов и утилит, позволяющие выполнять и разрабатывать приложения, написанные в среде разработки Ms Visual Studio. Устанавливать нужно ту версию .Net Framework, с помощью которой разрабатывался наш сайт.

Как установить Asp.Net правильной версии? Проверить ее можно следующим образом: открыть проект в Visual Studio, зайти в свойства проекта (меню Проект->Свойства…). На вкладке «Построение» в поле «Требуемая версия .Net Framework» будет указана версия, под которую написано приложение.

Скачать .Net Framework можно с официального сайта Microsoft. Будем считать, что наш сайт написан на .Net 4.0. Скачать установщик можно здесь.

Качаем нужную версию .Net Framework, устанавливаем на сервере. Все, установка Asp.Net завершена!

Как зарегистрировать Asp.Net в IIS

В составе пакета .Net Framework есть утилита aspnet_regiis.exe, с помощью которой мы, собственно, и сможем зарегистрировать Asp.Net в IIS.

Отдельная статья посвящена тому, как установить и настроить IIS. Здесь будем считать, что IIS у нас уже установлен.

Asp безопасность приложений iis

Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.

В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:

1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS.

2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.

3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config).

4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.

5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS.

6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.

7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS.

8. HTTP.SYS отправляет ответ браузеру.

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

Теперь остановимся чуть поподробнее на каждом из упомянутых компонентов.

На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.

Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.

Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.

Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.

Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%system32drivershttp.sys.

Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.

2.2. World Wide Web Publishing Service (W3SVC)

Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:

  • Администрирование драйвера HTTP.sys.
  • Управление рабочими процессами.
  • Мониторинг показателей производительности веб-сайтов.

Эта служба функционирует в Windows Server 2003 в контексте процесса Svchost.exe (настройки можно посмотреть в реестре HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3Svc) в отличие от всех остальных служб IIS, которые исполняются в контексте процесса Inetinfo.exe, и реализована в Iisw3adm.dll.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с .NET Framework и интегрированные с IIS:

  • NetTcpActivator для протокола TCP;
  • NetPipeActivator для Named Pipes;
  • NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.

Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.

Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.

Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.

2.3. Windows Process Activation Service (WAS)

Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%System32inetsrvConfigApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

При активации нужного для обработки пользовательского запроса приложения задействуются следующие компоненты:

  • Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
  • Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
  • Исполняемый файл w3wp.exe – шаблон рабочего процесса.
  • Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
  • Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).

Ниже на рисунке представлен пример схемы компонентов внутри некоего экземпляра рабочего процесса приложения. Когда служба WAS запускает рабочий процесс, она загружает в него согласно конфигурации приложения требуемые обработчики протоколов процессов (PPH) и посредством менеджера приложений создаёт внутри рабочего процесса домен приложения, в котором будет хоститься приложение. Менеджер приложений загружает код приложения в домен приложения и требуемые обработчики протоколов уровня приложения (ADPH) для обработки сообщений по соответствующим сетевым протоколам.

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:

В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.

Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.

2.4. Пул приложений

При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.

Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.

Рис. 5 Дополнительные настройки пула приложений

Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).

Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.

Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.

Рис. 6. Идеология модулей в IIS.

Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).

Встраиваемая модель предполагает более тесное взаимодействие между IIS и ASP.NET. Запрос в такой архитектуре обработки пропускается через установленную последовательность событий, в каждом из которых запрос пропускается через нативный и управляемые модули. В таком режиме модели обработки запросов IIS и ASP.NET объединены в единую модель, что позволяет избежать дублирования функций и получить больший контроль над обработкой запроса.

На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.

2.5. Домен приложения, приложение

Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс My >

Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

Илон Маск рекомендует:  Что такое код fseek
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL