Общие сведения о безопасности и поддержка ASP.NET (C#)

Статья
06/29/2023

Примечание.

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

Повышенная производительность
Улучшенная расширяемость и возможность тестирования
Поддержка OAuth, OpenID Connect и двухфакторной проверки подлинности
Поддержка удостоверений на основе утверждений
Улучшение взаимодействия с ASP.Net Core

Скачать в формате PDF

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

Введение

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

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

Определение и вход пользователей на веб-сайт
Используйте ASP. Платформа членства NET для управления учетными записями пользователей
Создание, обновление и удаление учетных записей пользователей
Ограничение доступа к веб-странице, каталогу или определенным функциям на основе пользователя, вошедшего в систему.
Используйте ASP. Платформа ролей NET для связывания учетных записей пользователей с ролями
Управление ролями пользователей
Ограничение доступа к веб-странице, каталогу или определенным функциям на основе роли пользователя, вошедшего в систему.
Настройка и расширение ASP. Веб-элементы управления безопасностью NET

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

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

Примечание.

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

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

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

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

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

Учетная запись пользователя — это хранилище для сохранения сведений о конкретном пользователе. Учетные записи пользователей должны содержать сведения, которые однозначно идентифицируют пользователя, например имя входа пользователя и пароль. Наряду с этой важной информацией учетные записи пользователей могут включать такие вещи, как адрес электронной почты пользователя; дата и время создания учетной записи; дата и время последнего входа; имя и фамилия; номер телефона; и почтовый адрес. При использовании проверки подлинности форм сведения об учетной записи пользователя обычно хранятся в реляционной базе данных, такой как Microsoft SQL Server.

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

Проверка подлинности пользователей в приложении ASP.NET

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

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

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

Рабочий процесс проверка подлинности Windows использует один из следующих методов проверки подлинности:

Обычная проверка подлинности
Дайджест-аутентификация
Встроенная проверка подлинности Windows

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

Модальное диалоговое окно запрашивает пользователя для его учетных данных

Рис. 1. Модальное диалоговое окно запрашивает у пользователя свои учетные данные

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

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

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

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

На рисунке 2 показан рабочий процесс проверки подлинности форм из высокоуровневой точки vantage. Обратите внимание, что элементы проверки подлинности и авторизации в ASP.NET выполняют роль двух отдельных сущностей. Система проверки подлинности форм определяет пользователя (или сообщает, что они анонимны). Система авторизации определяет, имеет ли пользователь доступ к запрашиваемому ресурсу. Если пользователь не авторизован (так как он находится на рис. 2 при попытке анонимного посещения ProtectedPage.aspx), система авторизации сообщает, что пользователь отказано, что система проверки подлинности форм автоматически перенаправляет пользователя на страницу входа.

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

Рабочий процесс проверки подлинности форм

Рис. 2. Рабочий процесс проверки подлинности форм

Мы рассмотрим проверку подлинности форм гораздо более подробно в следующем руководстве. Обзор проверки подлинности форм. Дополнительные сведения о ASP. Параметры проверки подлинности NET см . ASP.NET аутентификации.

Ограничение доступа к веб-страницам, каталогам и функциям страниц

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

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

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

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

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

Учетные записи пользователей и роли

ГАДЮКА. Проверка подлинности форм NET предоставляет инфраструктуру для входа пользователей на сайт и их состояние проверки подлинности, запоминаемое на разных страницах. И авторизация URL-адресов предоставляет платформу для ограничения доступа к определенным файлам или папкам в приложении ASP.NET. Однако ни функция не предоставляет средства для хранения сведений учетной записи пользователя или управления ролями.

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

Сегодня реализация учетных записей пользователей в приложении ASP.NET гораздо проще благодаря платформе членства и встроенным веб-элементам управления login. Платформа членства — это несколько классов в пространстве имен System.Web.Security, которые предоставляют функциональные возможности для выполнения важных задач, связанных с учетной записью пользователя. Ключевой класс в платформе Членства — это класс Членства, который имеет такие методы:

CreateUser
DeleteUser
GetAllUsers
GetUser
UpdateUser
ValidateUser

Платформа членства использует модель поставщика, которая четко отделяет API платформы членства от своей реализации. Это позволяет разработчикам использовать общий API, но позволяет им использовать реализацию, которая соответствует пользовательским потребностям приложения. Короче говоря, класс членства определяет основные функциональные возможности платформы (методы, свойства и события), но на самом деле не предоставляет никаких сведений о реализации. Вместо этого методы класса Членства вызывают настроенного поставщика, который выполняет фактическую работу. Например, когда вызывается метод CreateUser класса Членства, класс Членства не знает подробностей пользовательского хранилища. Он не знает, поддерживаются ли пользователи в базе данных или в XML-файле или в другом хранилище. Класс членства проверяет конфигурацию веб-приложения, чтобы определить, к какому поставщику делегировать вызов, и этот класс поставщика отвечает за фактические создание новой учетной записи пользователя в соответствующем хранилище пользователей. Это взаимодействие показано на рис. 3.

Корпорация Майкрософт поставляет два класса поставщика членства в платформа .NET Framework:

ActiveDirectoryMembershipProvider — реализует API членства на серверах Active Directory и в режиме приложений Active Directory (ADAM).
SqlMembershipProvider — реализует API членства в базе данных SQL Server.

В этой серии учебников основное внимание уделяется исключительно SqlMembershipProvider.

Рис. 03. Модель поставщика позволяет легко подключать различные реализации к платформе (щелкните, чтобы просмотреть изображение полного размера)

Преимущество модели поставщика заключается в том, что альтернативные реализации могут быть разработаны корпорацией Майкрософт, сторонними поставщиками или отдельными разработчиками и легко подключаются к платформе членства. Например, корпорация Майкрософт выпустила поставщик членства для баз данных Microsoft Access. Дополнительные сведения о поставщиках членства см . в наборе средств поставщика, включающем пошаговое руководство поставщиков членства, пример пользовательских поставщиков, более 100 страниц документации по модели поставщика и полный исходный код для встроенных поставщиков членства (например, ActiveDirectoryMembershipProviderer и SqlMembershipProviderer).

ASP.NET 2.0 также представила платформу ролей. Как и платформа членства, платформа ролей создается на вершине модели поставщика. Его API предоставляется через класс Role и платформа .NET Framework поставляется с тремя классами поставщиков:

AuthorizationStoreRoleProvider — управляет сведениями о роли в хранилище политик диспетчера авторизации, например Active Directory или ADAM.
SqlRoleProvider — реализует роли в базе данных SQL Server.
WindowsTokenRoleProvider — связывает сведения о ролях на основе группы Windows посетителя. Этот метод обычно используется с проверка подлинности Windows.

В этой серии учебников основное внимание уделяется исключительно sqlRoleProvider.

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

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

Итоги

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

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

Счастливое программирование!

Дополнительные материалы

Дополнительные сведения о разделах, описанных в этом руководстве, см. в следующих ресурсах:

Об авторе

Скотт Митчелл, автор семи книг ASP/ASP.NET и основатель 4GuysFromRolla.com, работает с технологиями Microsoft Web с 1998 года. Скотт работает независимым консультантом, тренером и писателем. Его последняя книга Сэмс Учит себя ASP.NET 2.0 в 24 часах. Он может быть достигнут в mitchell@4GuysFromRolla.com. или через его блог, который можно найти на http://ScottOnWriting.NET.

Особое спасибо

Эта серия учебников была проверена многими полезными рецензентами. Ведущий рецензент для этого руководства был рассмотрен многими полезными рецензентами. Ведущие рецензенты этого руководства включают Alicja Maziarz, Джон Suru и Тереза Мерфи. Хотите просмотреть мои предстоящие статьи MSDN? Если да, упадите меня линию в mitchell@4GuysFromRolla.com.

Поделиться через