Модель безопасности 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) объектами. Более важно то, что вы получите общее представление о том, как можно встроить средства безопасности в вашу программную архитектуру и дизайн и увидите, какие факторы наиболее важны при создании безопасного программного обеспечения.

{PAGEBREAK}

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

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

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

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

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

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

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

Моделирование угроз – обширная тема, которая выходит далеко за пределы нашей книги. Если интересуетесь, - обратитесь к источникам: Майкл Говард (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.
  • {PAGEBREAK} Никогда не сохраняйте важные или критичные для бизнеса данные в виде состояния: Вид состояния (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) применяет модель конвейера к организации инфраструктуры безопасности. Эта модель помогает укрепить безопасность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В каждом случае пользователь предъявляет некоторое удостоверение при регистрации в системе. Идентичность пользователя отслеживается разными способами, в зависимости от типа аутентификации. Например, операционная система 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-сайтов ).

{PAGEBREAK}

Есть несколько причин для использования фиксированного бюджет для запуска кода 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 или нет.
  • {PAGEBREAK} Для защиты постоянной информации (в базе данных или в файле): Например, вы можете пожелать сохранить номер кредитной карточки пользователя в базе данных для будущего использования. Хотя вы можете сохранять эти данные в простом тексте и надеяться, что Web-сервер не будет взломан, но это плохая идея. Вместо этого вам следует использовать шифрующие классы, которые предлагает .NET, чтобы вручную шифровать данные перед их сохранением.

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

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

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

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

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

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

 

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

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

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

{PAGEBREAK}

Рис. 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.

{PAGEBREAK}

Например, если ваше приложение 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.

{PAGEBREAK}

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

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

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

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

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

{PAGEBREAK}

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

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

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

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

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

{PAGEBREAK}

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. В следующих разделах мы подробно раскроем все эти шаги.

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

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

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

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

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

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

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

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

Понятие SSL

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

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

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

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

  1. Клиент посылает запрос на соединение с сервером.
  2. Сервер подписывает свой сертификат и отправляет его клиенту. Это завершает фазу “рукопожатия”.
  3. Клиент проверяет, издан ли сертификат CA, которому он доверяет. Если это так, он переходит к следующему шагу. В сценарии с Web-броузером клиент может предупредить пользователя угрожающим сообщением о том, что он распознал CA и разрешает пользователю решать – продолжать ли дальше.
  4. Клиент сравнивает информацию в сертификате с информацией, присланной сайтом (включая доменное имя и его открытый ключ). Клиент также проверяет правильность сертификата стороны {PAGEBREAK} сервера, - что он не был отменен и издан заслуживающим доверия 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).

{PAGEBREAK}

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

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

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

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

Webmaster: administrator@certificatecompany.com
Phone: (555) 555-5555
Server: Microsoft Key Manager for IIS Version 4.0
{PAGEBREAK}
Common-name: www.yourcompany.com
Organization: YourOrganization
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIB1DCCAT0CAQAwgZMxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcgWW9yazEQ
MA4GA1UEBxMHQnVmZmFsbzEeMBwGA1UEChMVVW5pdmVyc2l0eSBhdCBCdWZmYWxv
MRwwGgYDVQQLExNSZXNlYXJjaCBGb3VuZGF0aW9uMSEwHwYDVQQDExh3d3cucmVz
ZWFyY2guYnVmZmFsby5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALJO
hbsCagHN4KMbl7uz0GwvcjJeWH8JqIUFVFi352tnoA15PZfCxW18KNtFeBtrb0pf
-----END NEW CERTIFICATE REQUEST-----

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).

{PAGEBREAK}

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

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

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

if (Request.IsSecureConnection)
{
// (Здесь – код приложения.)
}
else
{
// Перенаправить https, чтобы гарантировать доступ к странице через SSL.
Response.Redirect("https://www.mySite.com/account.asmx");
}

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

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

{PAGEBREAK}

Примечание Помните, что 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, потому что это очень легко.

{PAGEBREAK}

Рис. 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 Становится доступно состояние сессии
{PAGEBREAK}

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

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

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

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

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

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

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

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

  • FormsAuthenticationModule
  • WindowsAuthenticationModule
  • PassportAuthenticationModule

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

FormsAuthenticationModule

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

{PAGEBREAK}

Глава 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....

{PAGEBREAK}

Авторизация

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

  • UrlAuthorization: Модуль UrlAuthorization работает на основе содержимого конфигурации в файлах web.config разных директориев вашего Web-приложения. Он может ограничить доступ как к директориям, так и к файлам, на основе имени пользователя или назначенных им ролей.
  • FileAuthorization: При использовании аутентификации Windows ASP.NET автоматически использует модуль FileAuthorization для авторизации пользователей Windows в соответствии с доступом к файлам ASP.NET на базе Windows ACL. Таким образом, каждый пользователь Windows должен иметь, по крайней мере, права на чтение файлов Web-приложения. Этот модуль работает только с аутентификацией Windows, но без имерсонализации.

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

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

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

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

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

Интерфейс IPrincipal

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

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

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

if (HttpContext.Current.User.IsInRole("Admin"))
{
// (Делать что-то.)
}

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

Интерфейс IIdentity

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

{PAGEBREAK}

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

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

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

if (HttpContext.Current.User.Identity.IsAuthenticated)
{
lblUserName.Text = HttpContext.Current.User.Identity.Name +
" зарегистрирован";
}

Тип объекта идентичности зависит от типа используемой аутентификации. Всего четыре класса идентичности включены в .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 вам нужно было самостоятельно создавать такие инструменты {PAGEBREAK} управления и программные компоненты. 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 включает готовую к использованию инфраструктуру управления профилями в ваших приложениях.

{PAGEBREAK}

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

Расширенные Membership, Roles и Profiles

ASP.NET нужно где-то хранить информацию о пользователях, ролях и профилях. По умолчанию он сохраняет ее в базе данных SQL Server. Но вся эта инфраструктура полностью расширяема через так называемых настраиваемых поставщиков (custom providers). Поставщики членства (membership), ролей и профилей – это компоненты, отвечающие за сохранение информации о пользователях, ролях и профилях в хранилищах данных. В то время, как ASP.NET 2.0 поставляется с профилем для SQL Server, вы можете создать и конфигурировать собственных поставщиков через четко определенные интерфейсы, а это означает, что ваше приложение может быть написано полностью независимо от конкретного поставщика. То есть замена поставщика вообще никак не затронет ваше приложение!

В главе 26. Пользовательские поставщики Membership вы узнаете больше о настраиваемых поставщиках.

Итоги

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

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

Данная статья взята из главы 19. Модель безопасности ASP.NET, книги "Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов" {PAGEBREAK}



Опубликовал admin
23 Июл, Понедельник 2007г.



Программирование для чайников.