Смарт ТВ 

Как сделать авторизацию asp net. Контроль доступа к определенным файлам. Конфигурирование доступа для определенных пользователей

Последнее обновление: 31.10.2015

Релиз ASP.NET MVC 5 ознаменовался выходом новой системой авторизации и аутентификации в.NET приложениях под названием ASP.NET Identity. Эта система пришла на смену провайдерам Simple Membership, которые были введены в ASP.NET MVC 4.

Нажав на кнопку Change Authentication , мы можем изменить тип аутентификации, выбрав одно из следующих:

    No Authentication : ASP.NET Identity и встроенная система аутентификации отсутствует

    Individual User Accounts : проект по умолчанию включает систему ASP.NET Identity, которая позволяет авторизовать как пользователей внутри приложения, так и с помощью внешних сервисов, как google, твиттер и т.д.

    Organizational Accounts : подходит для сайтов и веб-приложений отдельных компаний и организаций

    Windows Authentication : система аутентификации для сетей intranet с помощью учетных записей Windows

Оставим значение по умолчанию, то есть Individual User Accounts и создадим проект.

Созданный проект уже по умолчанию имеет всю необходимую для авторизации инфраструктуру: модели, контроллеры, представления. Если мы заглянем в узел References (Библиотеки), то увидим там ряд ключевых библиотек, которые и содержит необходимые для авторизации и аутентификации классы:

Это ряд библиотек OWIN, которые добавляют функциональность OWIN в проект, а также три библиотеки собственно ASP.NET Identity:

    Microsoft.AspNet.Identity.EntityFramework : содержит классы Entity Framework, применяющие ASP.NET Identity и осуществляющие связь с SQL Serveroм

    Microsoft.AspNet.Identity.Core : содержит ряд ключевых интерфейсов ASP.NET Identity. Реализация этих интерфейсов позволит выйти за рамки MS SQL Server и использовать в качестве хранилища учетных записей другие СУБД, в том числе системы NoSQL

    Microsoft.AspNet.Identity.OWIN : привносит в приложение ASP.NET MVC аутентификацию OWIN с помощью ASP.NET Identity

Поскольку вся инфраструктура уже имеется в проекте, запустим проект, на отобразившейся в браузере странице найдем ссылку Register и нажмем на нее. На открывшейся странице регистрации введем какие-нибудь данные:

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

Во-первых, где это все хранится? Куда попадают данные зарегистрированных пользователей?

В данном случае используется подход Code First. В файле web.config уже имеется строка подключения по умолчанию, которая задает каталог базы данных. Если мы раскроем папку App_Data, то сможем увидеть созданную базу данных:

Если вдруг в папке база данных не видна, нажмем вверху окна Solution Explorer на кнопку Show All Files (Показать все файлы).

Мы можем открыть эту базу данных в окне Server Explorer и увидеть ее содержимое:

По умолчанию при регистрации первого пользователя создается следующий набор таблиц:

    MigrationHistory : используется EntityFramework для миграций БД

    AspNetRoles : содержит определения ролей

    AspNetUserClaims : таблица, хранящая набор клеймов (claim). Claim представляет иную модель авторизации по сравнению с ролями. Грубо говоря, claim содержит некоторую информацию о пользователе, например, адрес электронной почты, логин, возраст и т.д. И эта информация позволяет идентифицировать пользователя и наделить его соответствующими правами доступа.

    AspNetUserLogins : таблица логинов пользователя

    AspNetUserRoles : таблица, устанавливающая для пользователей определенные роли

    AspNetUsers : собственно таблица пользователей. Если мы ее откроем, то увидим данные зарегистрированного пользователя

Ключевыми объектами в AspNet Identity являются пользователи и роли . Вся функциональность по созданию, удалению пользователей, взаимодействию с хранилищем пользователей хранится в классе UserManager . Для работы с ролями и их управлением в AspNet Identity определен класс RoleManager . Классы UserManager и RoleManager находятся в библиотеке Microsoft.AspNet.Identity.Core.

Каждый пользователь для UserManager представляет объект интерфейса IUser. А все операции по управлению пользователями производятся через хранилище, представленное объектом IUserStore.

Каждая роль представляет реализацию интерфейса IRole, а управление ролями классом RoleManager происходит через хранилище IRoleStore.

Непосредственную реализацию интерфейсов IUser, IRole, IUserStore и IRoleStore предоставляет пространство имен Microsoft.AspNet.Identity.EntityFramework:

Класс IdentityUser является реализацией интерфейса IUser. А класс хранилища пользователей - UserStore реализует интерфейс IUserStore.

Подобным образом класс IdentityRole реализует интерфейс IRole, а класс хранилища ролей - RoleStore реализует интерфейс IRoleStore.

А для взаимодействия с базой данных в пространстве имен Microsoft.AspNet.Identity.EntityFramework определен класс контекста IdentityDbContext

В приложении ASP.NET MVC мы не будем работать напрямую с классами IdentityUser и IdentityDbContext. По умолчанию в проект в папку Models добавляется файл IdentityModels.cs , который содержит определения классов пользователей и контекста данных:

Public class ApplicationUser: IdentityUser { public async Task GenerateUserIdentityAsync (UserManager manager) { var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); return userIdentity; } } public class ApplicationDbContext: IdentityDbContext { public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } }

В приложении мы не работаем напрямую с классами IdentityUser и IdentityDbContext, а имеем дело с классами-наследниками.

Класс ApplicationUser наследует от IdentityUser все свойства. И кроме того добавляет метод GenerateUserIdentityAsync() , в котором с помощью вызова UserManager.CreateIdentityAsync создается объект ClaimsIdentity . Данный объект содержит информацию о данном пользователе.

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

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

Во-первых, чтобы задействовать AspNet Identity, в проект в папку App_Start добавляются два файла. Файл Startup.Auth.cs содержит класс запуска приложения OWIN. Поскольку AspNet Identity использует инфраструктуру OWIN, то данный класс является одним из ключевых и необходимых для работы.

Файл IdentityConfig.cs содержит ряд дополнительных вспомогательных классов: сервисы для двухфакторной валидации с помощью email и телефона EmailService и SmsService , класс менеджера пользователей ApplicationUserManager , добавляющий к UserManager ряд дополнительных функций, и класс ApplicationSignInManager , используемый для входа и выхода с сайта.

Базовая функциональность системы аутентификации и управления учетными записями расположена в двух контроллерах: AccountController и ManageController

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

Несмотря на то, что по умолчанию нам уже предоставляется готовый функционал, однако в ряде случаев, например, для отправки смс или электронной почты необходима дополнительная настройка. Теперь рассмотрим основные моменты системы AspNet Identity.

Сергей Бакланов

Imports System.Data.SqlClient Imports System.Web.Security Public Class login Inherits System.Web.UI.Page Protected WithEvents txtName As System.Web.UI.WebControls.TextBox Protected WithEvents txtPassword As System.Web.UI.WebControls.TextBox Protected WithEvents lbl As System.Web.UI.WebControls.Label Protected WithEvents btnLogin As System.Web.UI.WebControls.Button #Region " Web Form Designer Generated Code " "This call is required by the Web Form Designer. Private Sub InitializeComponent() End Sub "NOTE: The following placeholder declaration is required by the Web Form Designer. "Do not delete or move it. Private designerPlaceholderDeclaration As System.Object Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init "CODEGEN: This method call is required by the Web Form Designer "Do not modify it using the code editor. InitializeComponent() End Sub #End Region Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load "Put user code to initialize the page here End Sub Private Sub btnLogin_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnLogin.Click Dim cn As New SqlConnection("server=localhost;database=FormAuthUsers;uid=sa;pwd=;") Dim cm As New SqlCommand("FindUser", cn) Dim dr As SqlDataReader Dim ticket As FormsAuthenticationTicket Dim n As Integer, strRoles As String, strEncrypted As String " Открываем соединение Try cn.Open() Catch ex As SqlException Response.Write(ex.Message) Exit Sub End Try " Задаём тип команды cm.CommandType = CommandType.StoredProcedure " Добавляем параметры имени Dim prmName = New SqlParameter("@Name", SqlDbType.NVarChar, 50) prmName.Value = txtName.Text cm.Parameters.Add(prmName) " Добавляем параметр пароля Dim prmPass = New SqlParameter("@Password", SqlDbType.NVarChar, 50) prmPass.Value = txtPassword.Text cm.Parameters.Add(prmPass) " Выполняем запрос n = cm.ExecuteScalar If n > 0 Then " Если пользователь с таким именем и паролем существует, то ищем его роли cm = Nothing cm = New SqlCommand("exec FindRoles "" & txtName.Text & """, cn) dr = cm.ExecuteReader() " Составляем список ролей While dr.Read If strRoles = "" Then strRoles &= dr(0) Else strRoles &= ", " & dr(0) End If End While " Создаём аутентификационный билет ticket = New FormsAuthenticationTicket(1, txtName.Text, DateTime.Now, _ DateTime.Now.AddMinutes(20), False, strRoles) " Шифруем билет strEncrypted = FormsAuthentication.Encrypt(ticket) " Сохраняем cookie-файл Response.Cookies.Add(New HttpCookie("UrlAuthz", strEncrypted)) " Возвращаемся на исходную страницу FormsAuthentication.RedirectFromLoginPage(txtName.Text, False) Else " Если пользователь не был найден, то выдаём сообщение об ошибке lbl.Visible = True End If End Sub End Class

В этом примере мы поместили в одну процедуру две операции проверки: одна - аутентификации, другая - авторизации. Сначала мы проходим аутентификацию, запрашивая данные на пользователя с таким-то именем и паролем из базы. Если пользователь не был найден, выводим соответствующее сообщение об ошибке (см. 4 строку снизу). Если же пользователь обнаружен, то мы определяем его роли, опять запрашивая информацию из базы данных. На основе полученных сведений о ролях формируется аутентификационный билет, который впоследствии шифруется и сохраняется в cookie-файле. И, наконец, пользователь благополучно возвращается на страницу default.aspx.

Поскольку в нашем файле конфигурации были прописаны ограничения доступа для нескольких файлов, то давайте разберём их содержимое (листинг 7).

Листинг 7. default.aspx

AuthzByUrl Sub Page_Load(sender As Object, e As EventArgs) Handles MyBase.Load If HttpContext.Current.User.Identity.Name = "" Then lblLogin.Text = "You"re not registered, please login" Else lblLogin.Text = "You"re registered as " & _ HttpContext.Current.User.Identity.Name End If End Sub Sub btnLogin_Click(sender As Object, e As EventArgs) Handles btnLogin.Click Response.Redirect("login.aspx") End Sub You"re not registered, please login
GoTo:
  • Admin zone
  • User zone

admin.aspx

admin

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

Заимствование полномочий

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

По умолчанию режим заимствования полномочий в среде ASP.NET отключён. Для его активизации нужно добавить в файл Web.config тэг и присвоить его атрибуту impersonate значение true. Следующий фрагмент файла конфигурации проекта демонстрирует, как это должно выглядеть:

Web.config

Для демонстрации работы этого режима, используйте следующий код (листинг 8) в странице default.aspx:

default.aspx

Impersonation User: IsAuthenticated Authentication type Name WindowsIdentity: IsAuthenticated Authentication type Name

default.aspx.vb

Imports System.Security.Principal Public Class WebForm1 Inherits System.Web.UI.Page #Region " Web Form Designer Generated Code " "This call is required by the Web Form Designer. Private Sub InitializeComponent() End Sub "NOTE: The following placeholder declaration is required by the Web Form Designer. "Do not delete or move it. Private designerPlaceholderDeclaration As System.Object Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init "CODEGEN: This method call is required by the Web Form Designer "Do not modify it using the code editor. InitializeComponent() End Sub #End Region Protected WithEvents clmIsAuthU As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmAuthTypeU As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmNameU As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmIsAuthW As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmAuthTypeW As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmNameW As System.Web.UI.HtmlControls.HtmlTableCell Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim wi As WindowsIdentity " User.Identity With context.User.Identity clmIsAuthU.InnerText = .IsAuthenticated.ToString clmAuthTypeU.InnerText = .AuthenticationType.ToString clmNameU.InnerText = .Name End With " System.Security.Principal.WindowsIdentity wi = WindowsIdentity.GetCurrent With wi clmIsAuthW.InnerText = .IsAuthenticated.ToString clmAuthTypeW.InnerText = .AuthenticationType.ToString clmNameW.InnerText = .Name End With End Sub End Class

В обработчике события загрузки формы для получения идентификатора пользователя объекта WindowsIdentity используется метод GetCurrent, возвращающий идентификатор учётной записи, от имени которой функционирует процесс ASP.NET.

При запуске этого приложения с отключенным заимствованием полномочий () перед вами появится экран, представленный на рисунке 3. Как можно наблюдать, при отключенном заимствовании полномочий в объекте WindowsIdentity содержится идентификатор системного пользователя ASPNET.

Теперь, если вы активизируете заимствование полномочий, то увидите результат, представленный в таблице 1.

Таблица 1. Включенное заимствование полномочий и отключенный анонимный доступ

WindowsIdentity:

IsAuthenticated True
Authentication type Negotiate
Name BIGDRAGON\B@k$
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\B@k$

Как видите, результаты одинаковые, поскольку оба объекта получают информацию о текущем пользователе. Но предыдущие два примера были ориентированы на условия с запрещённым анонимным доступом для аутентификации средствами Windows. Если разрешить анонимный доступ к приложению, то объект User.Identity не вернёт никакого имени пользователя, а его свойство IsAuthenticated будет иметь значение False. В этом нет ничего удивительного, т. к. если в системе аутентификации Windows разрешён анонимный доступ, то пользователь работает анонимно, то есть не проходит аутентификацию.

В это же время у объекта WindowsIdentity свойство IsAuthenticated будет иметь значение True, а в качестве имени пользователя будет стоять строка следующего формата: IUSR_ , как показано в таблице 2.

Таблица 2. Заимствование полномочий и анонимный доступ разрешены

WindowsIdentity:

IsAuthenticated False
Authentication type
Name
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\IUSR_BIGDRAGON

Свойство name объекта WindowsIdentity имеет такое значение потому, что оно возвращает идентификатор пользователя, под которым работает процесс ASP.NET, а не пользователь Web-узла. А поскольку процесс не может работать анонимно, то он получает имя от IIS, если его невозможно получить от текущего пользователя.

Если вы были внимательны при выполнении операций по разрешению/запрету анонимного доступа, то могли заметить, что в поле Имя пользователя была как раз подставлена строка вышеуказанного формата: IUSR_ (рис. 4).

Рисунок 4. В поле Имя пользователя содержится строка, определяющая имя процесса ASP.NET при анонимном доступе

Кроме того, в среде ASP.NET предусмотрена возможность указания, от кого именно заимствовать полномочия. С этой целью в тэге предусмотрен атрибут userName, в котором и указывается имя пользователя, у которого необходимо заимствовать полномочия.

В следующем фрагменте из файла Web.config, показано, как это должно выглядеть на практике:

Web.config :

После запуска тестового приложения с такой конфигурацией на выполнение, состояние объекта User.Identity останется неизменным, а вот в свойстве name объекта WindowsIdentity вместо строки формата IUSR_ появится имя, указанное в атрибуте userName тэга из файла конфигурации проекта, как показано в таблице 3.

Таблица 3. Процесс ASP.NET работает от имени конкретного пользователя

WindowsIdentity:

IsAuthenticated False
Authentication type
Name
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\AlBa

Если вы отмените анонимный доступ, то объект User.Identity будет содержать идентификатор зарегистрированного пользователя, а в объекте WindowsIdentity по-прежнему будет оставаться имя пользователя, переданное через атрибут userName.

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

Если эта тема вас действительно заинтересовала, то вы можете найти массу материала в библиотеке MSDN:

  • Темы безопасности в рамках ASP.NET доступны в следующей ветке библиотеки MSDN: .NET Development/.NET Security;
  • По вопросам безопасности всей системы в целом следует обращаться к разделу Security/Security (General)/SDK Documentation.

Если у вас нет MSDN-библиотеки, то к её самому свежему изданию можно обратиться через интернет по адресу: http://msdn.microsoft.com/library/ .

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

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

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

Корпоративные сайты, расположенные в защищённых внутренних сетях предприятий, могут содержать страницы с отчётами, предназначенными только для руководителей или сотрудников определённых отделов. Рядовые сотрудники не должны иметь доступа к этим ресурсам.

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

Например, в электронном магазине вы наверняка позволите каждому пользователю просматривать витрину и пользоваться корзиной заказов.

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

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

Что такое авторизация?

Как мы уже говорили, предоставление пользователям уникальных учётных записей позволяет идентифицировать их. Механизм «узнавания » сайтом зарегистрированных посетителей называется аутентификацией.

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

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

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

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

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

Управление доступом на основе групп и ролей

Хотя права можно назначать индивидуально каждому пользователю сайта, управление этим процессом существенно осложняется по мере роста числа пользователей. Любое изменение в системе безопасности сайта может потребовать перенастройки прав большого количества пользователей, что требует времени и чревато ошибками.

Для решения этой проблемы пользователи, имеющие одинаковые права или потребности, собираются в группы. Отдельные права также могут явно или неявно группироваться в так называемые роли. Роли, в свою очередь, могут назначаться отдельным пользователям или группам. В некоторых системах «роль » и «группа » являются синонимами.

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

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

Однако в случае принадлежности пользователя к нескольким группам или ролям в системе должен быть предусмотрен механизм решения конфликтов прав. Например, пользователь блога может быть включён в две группы, одной из которых разрешено создавать посты, а другой – только просматривать. Какое право присваивать пользователю в итоге?

Большая часть систем оставляет в действии минимальные права либо предусматривает приоритет запретов над разрешениями. В таком случае наш гипотетический пользователь не будет иметь права писать в блог, так как ограничение полномочий будет преобладать над разрешением.

Хорошей практикой является разделение пользователей на группы по виду деятельности на сайте. Например, наш блог может иметь следующие группы пользователей: «Авторы », «Редакторы », «Модераторы » и т.д.

Альтернативный подход будет состоять в том, чтобы выделить группы «Создание статей », «Правка статей », «Удаление комментариев » и т. д. Такой подход будет обладать значительной гибкостью, но при этом придётся поддерживать на сайте большее количество различных групп.

Защита страниц средствами ASP.NET

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

При защите сайта на ASP.NET используются три направления разделения доступа:

  • Система роутинга адресов;
  • Веб-формы (файлы и папки );
  • Структуры MVC .
Защита сайта на веб-формах

Как веб-формы, так и роутинг в ASP.NET использует для защиты доступа web.config . Основа конфигурации для защиты доступа к ресурсам сайта выглядит примерно так:

XML -элемент location определяет путь к защищаемому ресурсу: папке, странице или элементу роутинга. В данном примере он задаёт страницу adminhome.aspx . Можно защитить содержимое папки целиком, указав путь к ней. Если атрибут path отсутствует, настройки безопасности применяются к той папке, в которой находится файл web.config , со всеми её подпапками.

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

В нашем примере правило будет проверено первым. Если пользователь обладает ролью администратора, доступ ему будет предоставлен, и проверка условий на этом прекратится.

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

Существует несколько специальных символов, обозначающих часто используемые группы. Мы уже видели символ «* », обозначающий всех пользователей.

Символ «? » обозначает анонимного (не успевшего зарегистрироваться ) пользователя. Несколько групп или отдельных пользователей могут быть перечислены через запятую. Пользователи и роли могут смешиваться в одном правиле, например:

Защита MVC-сайта

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

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

Public class AdminController: Controller { ...

Для обозначения анонимов и всех пользователей доступны те же символы «? » и «* ». Вы можете применять установки ко всему контроллеру или к отдельным действиям. При этом настройки действий будут иметь более высокий приоритет, чем настройки всего контроллера:

Public ActionResult AdminView() { ...

Если вы не укажете пользователей или ролей в атрибуте , то доступ будет разрешён всем зарегистрированным пользователям.

В ASP.NET 4 был добавлен атрибут , который позволил разрешить анонимному пользователю доступ к отдельным действиям защищённого контроллера.

Управление контентом в зависимости от роли

Ограничив доступ к страницам и контроллерам, следующим шагом вы должны убедиться в том, что доступ к самому серверному коду осуществляется правильно. Некоторые объекты легко защитить, потому что к ним должны иметь доступ только пользователи с определённой ролью, и доступ этот – полный.

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

Например, не имеет смысла показывать ссылку на панель администрирования рядовым пользователям. Клиент, не имеющий отправленных заказов, не должен видеть кнопку трекинга. Даже если элемент не активен или ведёт на страницу авторизации, он может смутить простого пользователя и дать злоумышленнику пищу для размышления.

Код, исполняемый сервером на странице, доступной нескольким ролям, должен всегда проверять права пользователя и основывать свои действия на результате этой проверки.

Если на странице, просматриваемой как обычными посетителями, так и администраторами, должна быть ссылка на ресурс, доступный только администратору, то в варианте, предназначенном для обычного пользователя, её нужно скрыть.

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

Всегда проверяйте, насколько безопасен код, обрабатывающий GET -запросы. Например, ваш веб-магазин имеет запрос для удаления заказа:

UpdateOrder.aspx?order=33&action=delete

Теперь, представьте хакера, удаляющего все заказы перебором параметра order . Проверяется ли принадлежность заказа пользователю в соответствующем обработчике?

В другом случае отсутствие проверки в чём-то вроде:

UpdateOrder.aspx?order=33&action=refund

позволит злоумышленнику получить возмещение за чужой или не оплаченный заказ. Никогда не полагайтесь на скрытие ссылок как единственный механизм защиты от не авторизованного доступа.

Аспекты безопасности пользовательских сессий

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

В этом примере время жизни сессии составит 30 минут. Атрибут slidingExpiration определяет, сбрасывает ли счётчик истечения сессии поступление запроса от пользователя. Если установить данному атрибуту значение false , пользователю придётся осуществлять вход каждые 30 минут, даже во время активной работы с сайтом.

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

Если кука никак не защищена, её может использовать злоумышленник, перехватив трафик легитимного пользователя и представившись системе этим пользователем.

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

Аутентификация подтверждает, что пользователь предоставил корректные данные для доступа в систему. Когда пользователь входит в систему (как правило, с помощью имени пользователя (логина) и пароля, но возможны и некоторые другие маркеры, такие как ключ SSH или зашифрованный ключ), он аутентифицирован.

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

Ограничение доступа с AuthorizeAttribute

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

По умолчанию новые проекты ASP.NET MVC, созданные на основе шаблона проектов Internet Application , для включения аутентификации используют схему forms-аутентификации, которая определена в разделе system.web/authentication в файле web.config:

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

Windows-аутентификация

В качестве альтернативы forms-аутентификации ASP.NET также поддерживает Windows-аутентификацию, которую можно включить, изменив на в web.config .

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

Когда аутентификация включена, мы можем применить AuthorizeAttribute к действиям контроллера (или даже целым контроллерам), чтобы ограничить доступ к ним. Если пользователь не имеет доступа к действию, AuthorizeAttribute передаст в браузер код статуса HTTP 401 Unauthorized , который указывает, что запрос был отклонен. Приложения, в которых используется forms-аутентификация, будут перенаправлять браузер на страницу входа, и пользователи смогут продолжить, только если выполнят вход.

Простейшее применение AuthorizeAttribute требует только аутентификации текущего пользователя:

Public ActionResult About() { return View(); }

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

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

Public ActionResult Admins() { return View(); }

В этом случае только пользователь с именем "admin" будет иметь доступ к данному действию.

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

Public ActionResult Developers() { return View(); }

Доступ к действию Developers будет разрешен только для пользователей в роли администратора или разработчика - для всех других пользователей (аутентифицированных или нет) будет выдан код ответа 401 и, с помощью forms-аутентификации ASP.NET, они будут перенаправлены на страницу входа.

Аутентификация на основе ролей

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

Если вы используете Windows-аутентификацию, роли будут автоматически найдены в групповом членстве Active Directory. Однако если вы используете forms-аутентификацию, вам нужно будет использовать провайдер членства (который может быть настроен в web.config), чтобы определить, где нужно сохранять и находить информацию о пользователях (например, роли).

Шаблон проектов для ASP.NET MVC Intranet Application по умолчанию будет использовать базу данных SQL Express для хранения ролей.

Теперь, когда вы видели несколько примеров использования AuthorizeAttribute , давайте поговорим о том, как он работает.

AuthorizeAttribute - как он работает

Внутренне AuthorizeAttribute реализован в виде IAuthorizationFilter , который выполняет несколько проверок, чтобы решить, имеет ли пользователь право доступа к текущему действию контроллера. Процесс принятия решений данного атрибута показан на рисунке 8-1.

Рисунок 8-1: AuthorizeAttribute проверяет, аутентифицирован ли пользователь, есть ли имя пользователя в белом списке и какова его роль, прежде чем принять решение, имеет ли пользователь права для просмотра требуемого действия

Поскольку AuthorizeAttribute реализует интерфейс IAuthorizationFilter , он должен содержать метод под названием OnAuthorization , который получает ссылку на AuthorizationContext , представляющий текущий запрос.

Когда фреймворк вызывает этот метод, атрибут получает ссылку на текущий IPrincipal , который соответствует пользователю, выполняющему текущий запрос. Если пользователь еще не прошел аутентификацию, он отменяет запрос, установив значение свойства Result класса AuthorizationContext на HttpUnauthorizedResult . Это отменяет вызов действия контроллера и отправляет в браузер код HTTP 401 , который, в свою очередь, вызывает соответствующий запрос входа.

Если указаны пользователи или роли, AuthorizeAttribute проверяет, находится ли текущее имя пользователя в списке разрешенных имен, или приписана ли пользователю роль с правом доступа. Если же Users или Roles не указаны, пользователь получает права доступа.

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

AuthorizeAttribute можно использовать несколькими способами:

  • Если AuthorizeAttribute применяется к контроллеру, он применяется к каждому действию этого контроллера
  • Если несколько AuthorizeAttribute применяются к действию, пользователь должен пройти все проверки и быть авторизированным каждым из них

В ASP.NET MVC существует несколько других реализаций IAuthorizationFilter , и все они используются для защиты от нежелательных запросов.

В главе 16 фильтры будут описаны подробно, но давайте рассмотрим пять фильтров, которые связаны непосредственно с безопасностью:

  • AuthorizeAttribute: Об этом вы уже знаете
  • ChildActionOnlyAttribute: Гарантирует, что метод действия может быть вызван только из другого действия (обычно из представления с помощью Html.Action), но не может быть вызван напрямую
  • RequireHttpsAttribute: Гарантирует, что действие может быть доступно только через безопасное соединение
  • ValidateAntiForgeryTokenAttribute: Гарантирует, что был указан действительный маркер для борьбы с фальсификацией (вы узнаете об этом больше в следующем разделе)
  • ValidateInputAttribute: Указывает, должен ли ASP.NET проводить валидацию пользовательского ввода для обнаружения потенциально опасного содержимого

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

Скажем, что у вас есть.net web api с действием GetResource (int resourceId). Это действие (с указанным идентификатором) должно быть разрешено только для пользователя, связанного с этим идентификатором (например, ресурс может быть блогером, написанным пользователем).

Это можно решить разными способами, но ниже приведен пример.

Public Resource GetResource(int id) { string name = Thread.CurrentPrincipal.Identity.Name; var user = userRepository.SingleOrDefault(x => x.UserName == name); var resource = resourceRepository.Find(id); if (resource.UserId != user.UserId) { throw new HttpResponseException(HttpStatusCode.Unauthorized); } return resource; }

где пользователь был аутентифицирован каким-то механиком.

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

Есть ли способ централизовать это таким образом, чтобы мне не приходилось писать код авторизации в каждом действии?

Edit Основываясь на ответах, я думаю, что должен уточнить свой вопрос.

То, что я действительно делаю, - это механизм, который позволяет иметь авторизацию на основе ресурсов, но в то же время позволяет некоторым пользователям также использовать одну и ту же конечную точку и тот же ресурс. Ниже приведенное действие разрешит это для этой конкретной конечной точки и для этой конкретной роли (Admin).

Public Resource GetResource(int id) { string name = Thread.CurrentPrincipal.Identity.Name; var user = userRepository.SingleOrDefault(x => x.UserName == name); var resource = resourceRepository.Find(id); if (!user.Roles.Any(x => x.RoleName == "Admin" || resource.UserId != user.UserId) { throw new HttpResponseException(HttpStatusCode.Unauthorized); } return resource; }

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

4 ответов

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

Public Resource GetResource(int id) { var resource = resourceRepository.Find(id); if (resource.UserId != User.Identity.GetUserId()) { throw new HttpResponseException(HttpStatusCode.Unauthorized); } return resource; }

Если вы хотите еще больше упростить код, вы можете написать UserRepository, который знает данные пользователя и репозиторий ресурсов для централизации кода. Код будет выглядеть так:

Public Resource GetResource(int id) { return User.Identity.GetUserRepository().FindResource(id); }

Для авторизации на основе роли AuthorizeAttribute будет лучшим местом для ее обработки, и вам лучше использовать отдельное действие или контроллер для этого.

Public Resource GetResourceByAdmin(int id) { return resourceRepository.Find(id); }

[Изменить] Если OP хочет использовать одно действие для работы с разными типами пользователей, я лично предпочитаю использовать репозиторий пользователя factory. Код действия:

Public Resource GetResource(int id) { return User.GetUserRepository().FindResource(id); }

Метод расширения будет:

Public static IUserRepository GetUserRepository(this IPrincipal principal) { var resourceRepository = new ResourceRepository(); bool isAdmin = principal.IsInRole("Admin"); if (isAdmin) { return new AdminRespository(resourceRepository); } else { return new UserRepository(principal.Identity, resourceRepository); } }

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

Вам необходимо выполнить экстернализацию своей авторизации. Вы хотите переместить всю логику авторизации на отдельный уровень или службу.

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

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

Если мы перейдем к вашему примеру, у вас будет что-то по строкам:

Public Resource GetResource(int id) { var resource = resourceRepository.Find(id); if (isAuthorized(User.Identity,resource)) { throw new HttpResponseException(HttpStatusCode.Unauthorized); } return resource; } public bool isAuthorized(User u, Resource r){ // Create XACML request here // Call out to PDP // return boolean decision }

Ваш PDP будет содержать следующие правила:

  • пользователь может выполнить действие == представление на ресурсе тогда и только тогда, когда resource.owner == user.id
  • пользователь с ролью == administrator может выполнить действие == на ресурсе.

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

Я бы посмотрел на реализацию пользовательского System.Web.Http.AuthorizeAttribute , который вы могли бы применить к действиям, которые нуждаются в этом конкретном правиле авторизации. В пользовательской авторизации вы можете разрешить доступ, если пользователь является членом группы "Админы", или если он является автором ресурса.

ИЗМЕНИТЬ:

Основываясь на редактировании OP, позвольте мне расширить то, что я говорю. Если вы переопределите AuthorizeAttribute, вы можете добавить логику, например:

Public class AuthorizeAdminsAndAuthors: System.Web.Http.AuthorizeAttribute { protected override bool IsAuthorized(HttpActionContext actionContext) { return currentUser.IsInRole("Admins") || IsCurrentUserAuthorOfPost(actionContext); } private bool IsCurrentUserAuthorOfPost(HttpActionContext actionContext) { // Get id for resource from actionContext // look up if user is author of this post return true; }

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

Public Resource GetResource(int id) { var resource = resourceRepository.Find(id); return resource; }