МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК
КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
Курсовая работа
Построение веб-приложения на основе ASP.NET и архитектуры сервера IIS 7.0
Выполнил: студент 367 гр.
Кузнецов А.А.
Научный руководитель:
Широких А.В.
Тюмень 2009.
Оглавление
Введение. 3
Теоретическая часть. 4
Практическая часть. 17
Заключение. 24
Список использованной литературы.. 25
Введение
В настоящее время сложно переоценить роль интернета. Это одна из наиболее динамично развивающихся отраслей, даже в условиях кризиса.
А что такое интернет без веб страниц и, соответственно, веб серверов?
Сейчас на рынке можно достаточно большое количество самых разных веб серверов. Один из наиболее распространенных – это 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. Вот один пример:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<customErrors mode="Off" />
</system.web>
<system.webServer>
<directoryBrowse enabled="true" />
</system.webServer>
</configuration>
В прошлом для того, чтобы приложение IIS работало надлежащим образом, требовалось точно настроить параметры приложения в хранилище метабазы на уровне компьютера. В случае распределенных файлов web.config приложения инкапсулируют требуемую настройку сервера в структуру своих каталогов. Это существенно упрощает развертывание, позволяя независимые приложения просто копировать в каталог приложения на целевом сервере и незамедлительно запускать подготовленные приложения с требуемыми параметрами.
Кроме того, новая система настройки предоставляет администраторам серверов всесторонний контроль, позволяя им делегировать определенные возможности настройки приложению, занимаясь при этом управлением другими параметрами с целью обеспечения безопасности или по производственной необходимости. При таком подходе приложения на основных серверах могут выполнять существенную часть настройки в своих приложениях без необходимости обращения за помощью к администратору или использования внешней панели настройки.
В полном соответствии основной идее IIS 7.0 система настройки является полностью расширяемой. Новые модули могут добавлять собственные схемы настройки, позволяя приложениям настраивать свои компоненты наряду с настройкой IIS и ASP.NET:
<configuration>
<system.webServer>
<directoryBrowse enabled="true" />
</system.webServer>
<myBandwidthThrottler enabled="true" />
</configuration>
Разделы пользовательской настройки используют такую же схему настройки, как и настройки компонентов 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 предоставляет множество возможностей прогр
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;
HttpContext context = application.Context;
try
{
string page = context.Request.CurrentExecutionFilePath if ((!Regex.IsMatch(page, "Default.aspx", RegexOptions.IgnoreCase)) && (!Regex.IsMatch(page, "ProductList.aspx", RegexOptions.IgnoreCase)) && (!Regex.IsMatch(page, "SearchResult.aspx", RegexOptions.IgnoreCase)) && (!Regex.IsMatch(page, "Register.aspx", RegexOptions.IgnoreCase)) && (!Regex.IsMatch(page, "Login.aspx", RegexOptions.IgnoreCase)) && (!Regex.IsMatch(page, "ErrorPage.aspx", RegexOptions.IgnoreCase)) && (!Regex.IsMatch(page, "ProductDetails.aspx", RegexOptions.IgnoreCase)))
{
if (context.Request.IsAuthenticated)&&(!Regex.IsMatch(page, "Management.aspx", RegexOptions.IgnoreCase)))
{
return;
}
else
if ((context.Request.IsAuthenticated)&&(Regex.IsMatch(page, "Management.aspx", RegexOptions.IgnoreCase)))
{
if (context.Request.Cookies.Get("auth").Value != null)
{
FormsAuthenticationTicket tick = FormsAuthentication.Decrypt(context.Request.Cookies.Get("auth").Value); string s = tick.UserData.ToString();
if (!Regex.IsMatch(s, "admin", RegexOptions.IgnoreCase))
{
context.Application["error"] = "Not enough rights";
context.Response.Redirect("~/ErrorPage.aspx");
}
}
else
{
context.Application["error"] = "Not enough rights";
context.Response.Redirect("~/ErrorPage.aspx");
}
}
}
else
return;
}
catch (Exception ex)
{
}
}
Если у пользователя, запрашивающего старницу нет аутонтификационного cookies он переадресовывается на страницу авторизации Login.aspx, на которой главный метод контрола Login1 проверяет наличие пользователя в базе и создает аутентификационный билет, записываемый в cookies.
protected void Login1_Authenticate(object sender, AuthenticateEventArgs e)
{
UserConnect accountSystem = new UserConnect();
string IDuser = accountSystem.UserLogin(Login1.UserName, Security.Encrypt(Login1.Password));
string userrole = accountSystem.UserRole(Login1.UserName);
if (IDuser != null)
{
HttpCookie authCookie = FormsAuthentication.GetAuthCookie(IDuser, Login1.DisplayRememberMe);
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(authCookie.Value);
FormsAuthenticationTicket newTicket = new FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, userrole);
authCookie.Value = FormsAuthentication.Encrypt(newTicket);
authCookie.Name = "auth";
Response.Cookies.Add(authCookie);
Response.Redirect("Defalt.aspx");
}
else
Response.Write("Can't authentificate <br/>");
}
Класс UserConnect содержит методы для вытягивания из базы информации о пользователях и записи ее туда.
Используемый нами метод UserLogin
public string UserLogin(string email, string password)
{
//CustomerDetails
int Iduser;
using( SqlConnection myConnection = new SqlConnection(ConnectionString))
using (SqlCommand myCommand = new SqlCommand("[dbo].[UserLogin]", myConnection))
{
myCommand.CommandType = CommandType.StoredProcedure;
// Add Parameters to SPROC
SqlParameter parameterEmail = new SqlParameter("@email", SqlDbType.NVarChar, 20, "email");
parameterEmail.Value = email;
myCommand.Parameters.Add(parameterEmail);
SqlParameter parameterPassword = new SqlParameter("@password", SqlDbType.NVarChar, 20, "password");
parameterPassword.Value = password;
myCommand.Parameters.Add(parameterPassword);
SqlParameter RetVal = new SqlParameter("@IDuser", SqlDbType.Int, 30);
RetVal.Direction = ParameterDirection.Output;
myCommand.Parameters.Add(RetVal);
// Open the connection and execute the Command myConnection.Open();
myCommand.ExecuteNonQuery();
Iduser = Convert.ToInt32(RetVal.Value);
myConnection.Close();
}
if (Iduser == 0)
{
return null;
}
else
{
return Iduser.ToString();
}
}
В итоге при введение в строку поиска адреса страницы, на которую нельзя попасть, не пройдя авторизацию, запрос будет переадресова на страницу входа. (См. рис. 5,6)
Рис 5. Попытка неавторизованного входа
Рис 6. Результат попытки неавторизованного входа
Если пользователь входит в группу администраторы, то при входе ему будут видны и доступны страницы управления, а обычным пользователям нет.
Рис. 7 главное меню Администратора
Рис 8. Возможности администратора
Рис 9. Главная страница обычного пользователя
Заключение
В своей работе я добился поставленных целей. Изучив работу ASP.NET и IIS 7.0 я научился создавать безопасные веб-приложения. Благодаря модульной архитектуре IIS 7.0 запросы буду проверяться самим сервером до передачи управления приложению. Разработанный мною механизм авторизации и проверки подлинности можно усовершенствовать, добавив проверку подлинности на основе ролей. Гибкость в настройке сервера позволяет переносить приложения простым копированием, поэтому написанное мною приложение легко распостранимо.
Подводя итоги, можно сказать, ASP.NET 2.0 и IIS 7.0 – мощный инструмент для разработки управления и поддержки веб-приложений, который можно и нужно использовать.
Список использованной литературы
1. Троелсен Э. «C# и платформа .NET. Библиотека программиста» - СПб.: Питер 2007 796л.
2. Глинн, Джей, Ивьен, Билл, Нейгел, Кристиан, Скиннер, Морган, Уотсон, Карли. C# и платформа .NET 3.0 для профессионалов. : Издательский дом «Вильямс», 2008. – 1376+416 с.
3. Общие сведения о жизненном цикле приложения ASP.NET для служб IIS 7.0 статья с http://msdn.microsoft.com/ru-ru/library/bb470252.aspx 10.05.09
4. Архитектура безопасности ASP.NET http://msdn.microsoft.com/ru-ru/library/yedba920.aspx 6.05.09