Мегаобучалка Главная | О нас | Обратная связь


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



2019-12-29 246 Обсуждений (0)
Проверка подлинности с помощью форм 0.00 из 5.00 0 оценок




Курсовая работа

Построение веб-приложения на основе 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, облегчающие управление сервером и делающие возможной автоматизированную настройку и развертывание.

 



2019-12-29 246 Обсуждений (0)
Проверка подлинности с помощью форм 0.00 из 5.00 0 оценок









Обсуждение в статье: Проверка подлинности с помощью форм

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

Популярное:



©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (246)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.008 сек.)