Общие сведения о безопасности и поддержка 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 показан рабочий процесс проверки подлинности на основе форм из высокоуровневой точки зрения. Обратите внимание, что элементы проверки подлинности и авторизации в ASP.NET действуют как две отдельные сущности. Система проверки подлинности с помощью форм идентифицирует пользователя (или сообщает, что он является анонимным). Система авторизации определяет, имеет ли пользователь доступ к запрашиваемому ресурсу. Если пользователь не авторизован (как показано на рисунке 2 при попытке анонимного посещения ProtectedPage.aspx), система авторизации сообщает, что пользователю отказано, что система проверки подлинности на основе форм автоматически перенаправляет пользователя на страницу входа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CreateUser
DeleteUser
GetAllUsers
Getuser
UpdateUser
Validateuser

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

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

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

Эта серия учебников посвящена исключительно SqlMembershipProvider.

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

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

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

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

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

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

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

Сводка

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

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

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

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

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

Об авторе

Скотт Митчелл( Scott Mitchell), автор семи книг ASP/ASP.NET и основатель 4GuysFromRolla.com, работает с веб-технологиями Майкрософт с 1998 года. Скотт работает независимым консультантом, тренером и писателем. Его последняя книга Sams Teach Yourself ASP.NET 2.0 в 24 часах. Он может быть доступен в mitchell@4GuysFromRolla.com. или через его блог, который можно найти по адресу http://ScottOnWriting.NET.

Особая благодарность

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

Вперед