AuthorizeAttribute - как он работает. Конфигурирование доступа для определенных ролей

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

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

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

В ASP.NET MVC 5 в очередной раз изменился механизм работы с авторизацией и аутентификацией. Теперь для этих задач используется OWIN (The Open Web Interface for .NET) - это спецификация определяющая интерфейс и описывающая взаимодействие между всеми компонентами. Короче говоря, это абстракция (middleware), которая отделяет от приложения обязанности аутентификации.

Благодаря OWIN, из коробки в ASP.NET MVC 5 появилось довольно большое количество крутых плюшек. Например, вы сразу же можете использовать аутентификацию через facebook или google. Кроме того, можно довольно просто сделать аутентификацию и через vkontakte.

Однако с OWIN есть и некоторые проблемы. Главная из них заключается в том, что этот механизм довольно новый, и в сети доступно мало примеров. Совсем не понятно, как расширить стандартного User-а, как изменить названия таблиц AspNetUsers, AspNetUserRoles, AspNetUserLogins, AspNetUserClaims, AspNetRoles, которые создаются по умолчанию, как расширить класс ролей (да и вообще, как работать с ролями — ведь изначально такого примера нет).

Я сам начал искать ответы на данные вопросы. Спустя некоторое время, нашёл цикл статей, описывающих ответы на вопросы, поставленные выше.

— базовая работа с аутентификацией.

— расширение Пользовательского класса, а также первичная работа с Ролями

— Расширение стандартного класса Ролей

• Tutorial

Цель урока : Изучить способ авторизации через Cookie, использование стандартных атрибутов доступа к контроллеру и методу контроллера. Использование IPrincipal. Создание собственного модуля (IHttpModule) и собственного фильтра IActionFilter.

Небольшое отступление: На самом деле в asp.net mvc все учебники рекомендуют пользоваться уже придуманной системой авторизации, которая называется AspNetMembershipProvider, она была описана в статье (сейчас доступ уже закрыт), но обьяснено это с точки зрения «нажимай и не понимай, что там внутри». При первом знакомстве с asp.net mvc меня это смутило. Далее, в этой статье - сказано, что пользоваться этим провайдером – нельзя. И я согласен с этим. Здесь же, мы достаточно глубоко изучаем всякие хитрые asp.net mvc стандартные приемы, так что это один из основных уроков.

Кукисы

Кукисы – это часть информации, отсылаемая сервером браузеру, которую браузер возвращает обратно серверу вместе с каждым (почти каждым) запросом.

Сервер в заголовок ответа пишет:
Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
Например:

HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value Set-Cookie: name2=value2; Expires=Wed, 09-Jun-2021 10:18:14 GMT
Браузер (если не истекло время действия кукиса) при каждом запросе:
GET /spec.html HTTP/1.1 Host: www.example.org Cookie: name=value; name2=value2 Accept: */*

Устанавливаем cookie (/Areas/Default/Controllers/HomeController.cs):
public ActionResult Index() { var cookie = new HttpCookie() { Name ="test_cookie", Value = DateTime.Now.ToString("dd.MM.yyyy"), Expires = DateTime.Now.AddMinutes(10), }; Response.SetCookie(cookie); return View(); }

В Chrome проверяем установку:

Для получения кукисов:
var cookie = Request.Cookies["test_cookie"];

Делаем точку остановки и проверяем:

Примечание: подробнее можно изучить кукисы по следующей ссылке:
http://www.nczonline.net/blog/2009/05/05/http-cookies-explained/

Авторизация

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

• FormsAuthenticationTicket – мы воспользуемся этим классом, чтобы хранить данные авторизации в зашифрованном виде
• Нужно реализовать интерфейс IPrincipal и установить в HttpContext.User для проверки ролей и IIdentity интерфейса.
• Для интерфейса IIdentity сделать реализацию
• Вывести в BaseController в свойство CurrentUser значение пользователя, который сейчас залогинен.

Приступим.
Создадим интерфейс IAuthentication и его реализацию CustomAuthentication (/Global/Auth/IAuthentication.cs):

Public interface IAuthentication { ///

/// Конекст (тут мы получаем доступ к запросу и кукисам) ///

HttpContext HttpContext { get; set; } User Login(string login, string password, bool isPersistent); User Login(string login); void LogOut(); IPrincipal CurrentUser { get; } }

Реализация (/Global/Auth/CustomAuthentication.cs):
public class CustomAuthentication: IAuthentication { private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger(); private const string cookieName = "__AUTH_COOKIE"; public HttpContext HttpContext { get; set; } public IRepository Repository { get; set; } #region IAuthentication Members public User Login(string userName, string Password, bool isPersistent) { User retUser = Repository.Login(userName, Password); if (retUser != null) { CreateCookie(userName, isPersistent); } return retUser; } public User Login(string userName) { User retUser = Repository.Users.FirstOrDefault(p => string.Compare(p.Email, userName, true) == 0); if (retUser != null) { CreateCookie(userName); } return retUser; } private void CreateCookie(string userName, bool isPersistent = false) { var ticket = new FormsAuthenticationTicket(1, userName, DateTime.Now, DateTime.Now.Add(FormsAuthentication.Timeout), isPersistent, string.Empty, FormsAuthentication.FormsCookiePath); // Encrypt the ticket. var encTicket = FormsAuthentication.Encrypt(ticket); // Create the cookie. var AuthCookie = new HttpCookie(cookieName) { Value = encTicket, Expires = DateTime.Now.Add(FormsAuthentication.Timeout) }; HttpContext.Response.Cookies.Set(AuthCookie); } public void LogOut() { var httpCookie = HttpContext.Response.Cookies; if (httpCookie != null) { httpCookie.Value = string.Empty; } } private IPrincipal _currentUser; public IPrincipal CurrentUser { get { if (_currentUser == null) { try { HttpCookie authCookie = HttpContext.Request.Cookies.Get(cookieName); if (authCookie != null && !string.IsNullOrEmpty(authCookie.Value)) { var ticket = FormsAuthentication.Decrypt(authCookie.Value); _currentUser = new UserProvider(ticket.Name, Repository); } else { _currentUser = new UserProvider(null, null); } } catch (Exception ex) { logger.Error("Failed authentication: " + ex.Message); _currentUser = new UserProvider(null, null); } } return _currentUser; } } #endregion }

Суть сводится к следующему, мы, при инициализации запроса, получаем доступ к HttpContext.Request.Cookies и инициализируем UserProvider:

Var ticket = FormsAuthentication.Decrypt(authCookie.Value); _currentUser = new UserProvider(ticket.Name, Repository);

Для авторизации в IRepository добавлен новый метод IRepository.Login. Реализация в SqlRepository:
public User Login(string email, string password) { return Db.Users.FirstOrDefault(p => string.Compare(p.Email, email, true) == 0 && p.Password == password); }

UserProvider, собственно, реализует интерфейс IPrincipal (в котором есть проверка ролей и доступ к IIdentity).
Рассмотрим класс UserProvider (/Global/Auth/UserProvider.cs):

Public class UserProvider: IPrincipal { private UserIndentity userIdentity { get; set; } #region IPrincipal Members public IIdentity Identity { get { return userIdentity; } } public bool IsInRole(string role) { if (userIdentity.User == null) { return false; } return userIdentity.User.InRoles(role); } #endregion public UserProvider(string name, IRepository repository) { userIdentity = new UserIndentity(); userIdentity.Init(name, repository); } public override string ToString() { return userIdentity.Name; }

Наш UserProvider знает про то, что его IIdentity классом есть UserIdentity , а поэтому знает про класс User , внутри которого мы реализуем метод InRoles(role) :

Public bool InRoles(string roles) { if (string.IsNullOrWhiteSpace(roles)) { return false; } var rolesArray = roles.Split(new { "," }, StringSplitOptions.RemoveEmptyEntries); foreach (var role in rolesArray) { var hasRole = UserRoles.Any(p => string.Compare(p.Role.Code, role, true) == 0); if (hasRole) { return true; } } return false; }

В метод InRoles мы ожидаем, что придет запрос о ролях, которые допущены к ресурсу, разделенные запятой. Т.е., например, “admin,moderator,editor”, если хотя бы одна из ролей есть у нашего User – то возвращаем зачение «истина» (доступ есть). Сравниваем по полю Role.Code, а не Role.Name.
Рассмотрим класс UserIdentity (/Global/Auth/UserIdentity.cs):
public class UserIndentity: IIdentity { public User User { get; set; } public string AuthenticationType { get { return typeof(User).ToString(); } } public bool IsAuthenticated { get { return User != null; } } public string Name { get { if (User != null) { return User.Email; } //иначе аноним return "anonym"; } } public void Init(string email, IRepository repository) { if (!string.IsNullOrEmpty(email)) { User = repository.GetUser(email); } } }
В IRepository добавляем новый метод GetUser(email) . Реализация для SqlRepository.GetUser() (LessonProject.Model:/SqlRepository/User.cs):

Public User GetUser(string email) { return Db.Users.FirstOrDefault(p => string.Compare(p.Email, email, true) == 0); }

Почти все готово. Выведем CurrentUser в BaseController:
public IAuthentication Auth { get; set; } public User CurrentUser { get { return ((UserIndentity)Auth.CurrentUser.Identity).User; } }

Да, это не очень правильно, так как здесь присутствует сильное связывание. Поэтому сделаем так, введем еще один интерфейс IUserProvider , из которого мы будем требовать вернуть нам авторизованного User:
public interface IUserProvider { User User { get; set; } } … public class UserIndentity: IIdentity, IUserProvider { ///

/// Текщий пользователь ///

public User User { get; set; } … public IAuthentication Auth { get; set; } public User CurrentUser { get { return ((IUserProvider)Auth.CurrentUser.Identity).User; } }
А теперь попробуем инициализировать это всё.
Вначале добавим наш IAuthentication + CustomAuthentication в регистрацию к Ninject (/App_Start/NinjectWebCommon.cs):

Kernel.Bind().To().InRequestScope();

Потом создадим модуль, который будет на событие AuthenticateRequest совершать действие авторизации:
public class AuthHttpModule: IHttpModule { public void Init(HttpApplication context) { context.AuthenticateRequest += new EventHandler(this.Authenticate); } private void Authenticate(Object source, EventArgs e) { HttpApplication app = (HttpApplication)source; HttpContext context = app.Context; var auth = DependencyResolver.Current.GetService(); auth.HttpContext = context; context.User = auth.CurrentUser; } public void Dispose() { } }

Вся соль в строках: auth.HttpContext = context и context.User = auth.CurrentUser . Как только наш модуль авторизации узнает о контексте и содержащихся в нем кукисах, ту же моментально получает доступ к имени, по нему он в репозитории получает данныепользователя и возвращает в BaseController. Но не сразу всё, а по требованию.
Подключаем модуль в Web.config:
…

План таков:

• Наверху показываем, авторизован пользователь или нет. Если авторизован, то его email и ссылка на выход, если нет, то ссылки на вход и регистрацию
• Создаем форму для входа
• Если пользователь правильно ввел данные – то авторизуем его и отправляем на главную страницу
• Если пользователь выходит – то убиваем его авторизацию

Поехали. Добавляем Html.Action(“UserLogin”, “Home”) – это partial view (т.е. кусок кода, который не имеет Layout) – т.е. выводится где прописан, а не в RenderBody().
_Layout.cshtml (/Areas/Default/Views/Shared/_Layout.cshtml):

@RenderBody() HomeController.cs: public ActionResult UserLogin() { return View(CurrentUser); }

UserLogin.cshtml (/Areas/Default/Views/Home/UserLogin.cshtml):

@model LessonProject.Model.User @if (Model != null) {

@Model.Email

@Html.ActionLink("Выход", "Logout", "Login")

} else {

@Html.ActionLink("Вход", "Index", "Login")

@Html.ActionLink("Регистрация", "Register", "User")

}

Контроллер входа выхода LoginController (/Areas/Default/Controllers/LoginController.cs):

Public class LoginController: DefaultController { public ActionResult Index() { return View(new LoginView()); } public ActionResult Index(LoginView loginView) { if (ModelState.IsValid) { var user = Auth.Login(loginView.Email, loginView.Password, loginView.IsPersistent); if (user != null) { return RedirectToAction("Index", "Home"); } ModelState["Password"].Errors.Add("Пароли не совпадают"); } return View(loginView); } public ActionResult Logout() { Auth.LogOut(); return RedirectToAction("Index", "Home"); } }

LoginView.cs (/Models/ViewModels/LoginView.cs):
public class LoginView { public string Email { get; set; } public string Password { get; set; } public bool IsPersistent { get; set; } }

Страница для входа Index.cshtml (/Areas/Default/Views/Index.cshtml):

@model LessonProject.Models.ViewModels.LoginView @{ ViewBag.Title = "Вход"; Layout = "~/Areas/Default/Views/Shared/_Layout.cshtml"; }

Вход

@using (Html.BeginForm("Index", "Login", FormMethod.Post, new { @class = "form-horizontal" })) {

Вход

Email

@Html.TextBox("Email", Model.Email, new { @class = "input-xlarge" })

Введите Email

@Html.ValidationMessage("Email")

Пароль

@Html.Password("Password", Model.Password, new { @class = "input-xlarge" }) @Html.ValidationMessage("Password")

Войти

}

Запускаем и проверяем:

Все исходники находятся по адресу

Скажем, что у вас есть.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; }

Authorization determines whether an identity should be granted access to a specific resource. In ASP.NET, there are two ways to authorize access to a given resource:

File authorization File authorization is performed by the . It checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file. ACL permissions are verified for the user"s Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET process. For more information, see ASP.NET Impersonation .

URL authorization URL authorization is performed by the , which maps users and roles to URLs in ASP.NET applications. This module can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles.

Using URL Authorization

With URL authorization, you explicitly allow or deny access to a particular directory by user name or role. To do so, you create an authorization section in the configuration file for that directory. To enable URL authorization, you specify a list of users or roles in the or elements of the section of a configuration file. The permissions established for a directory also apply to its subdirectories, unless configuration files in a subdirectory override them.

The following shows the syntax for the authorization section:

< users roles verbs />

The allow or deny element is required. You must specify either the users or the roles attribute. Both can be included, but both are not required. The verbs attribute is optional.

The allow and deny elements grant and revoke access, respectively. Each element supports the attributes shown in the following table:

	Identifies the targeted identities (user accounts) for this element. Anonymous users are identified using a question mark (?). You can specify all authenticated users using an asterisk (*).
	Defines the HTTP verbs to which the action applies, such as GET, HEAD, and POST. The default is "*", which specifies all verbs.

The following example grants access to the Kim identity and members of the Admins role, and denies access to the John identity (unless the John identity is included in the Admins role) and to all anonymous users:

The following authorization section shows how to allow access to the John identity and deny access to all other users:

You can specify multiple entities for both the users and roles attributes by using a comma-separated list, as shown in the following example:

Note that if you specify a domain account name, the name must include both the domain and user name (contoso\Jane).

The following example allows all users to perform an HTTP GET for a resource, but allows only the Kim identity to perform a POST operation:

Rules are applied as follows:

Rules contained in application-level configuration files take precedence over inherited rules. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent rules (those nearest in the hierarchy) at the head of the list.

Given a set of merged rules for an application, ASP.NET starts at the head of the list and checks rules until the first match is found. The default configuration for ASP.NET contains an element, which authorizes all users. (By default, this rule is applied last.) If no other authorization rules match, the request is allowed. If a match is found and the match is a deny element, the request is returned with the 401 HTTP status code. If an allow element matches, the module allows the request to be processed further.

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

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

Некоторые из этих проверок Windows осуществляет автоматически, а другие можно кодировать декларативно, используя файл web.config. Но некоторые проверки придется выполнять непосредственно в коде с использованием объекта IPrincipal.

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

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

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

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

Правила авторизации

Другими словами, существуют два типа правил: разрешить (allow) и запретить (deny). Тех и других можно добавлять столько угодно. Каждое правило идентифицирует одного или более пользователей либо ролей (групп пользователей). Вдобавок можно использовать атрибут verbs, чтобы создавать правила, применимые только к специфичным типам HTTP-запросов (GET, POST, HEAD ИЛИ DEBUG).

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

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

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

Такое правило требуется редко, потому что оно уже присутствует в файле machine.config. После того как среда ASP.NET применит все правила из файла web.config, она применяет правила из machine.config. В результате любому пользователю, кому явно закрыт доступ, автоматически его получает.

Теперь посмотрим, что произойдет, если в раздел добавить более одного правила:

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

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

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

Конфигурирование доступа для определенных пользователей

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

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

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

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

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

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

Контроль доступа к определенным каталогам

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

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

Настройки дескриптора в файле web.config подкаталога приложения изменять нельзя. Вместо этого все каталоги в приложении должны использовать одну и ту же систему аутентификации. Однако каждый каталог может иметь собственный набор правил авторизации.

При использовании правил авторизации в подкаталоге среда ASP.NET все равно читает правила авторизации из родительского каталога. Отличие в том, что правила из подкаталога применяются первыми. Это важно, потому что ASP.NET останавливается, как только находит соответствие правила авторизации. Рассмотрим пример, в котором корневой виртуальный каталог содержит одно правило:

а подкаталог - другое правило:

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

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

Контроль доступа к определенным файлам

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

Дескрипторы location размещаются вне главного дескриптора и вложены непосредственно в базовый дескриптор , как показано ниже:

В этом примере открывается доступ ко всем файлам приложения за исключением SecuredPage.aspx и AnotherSecuredPage.aspx, которые имеют правило авторизации, запрещающее анонимный доступ к ним.

Конфигурирование доступа для определенных ролей

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

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

После определения для ролей можно создавать правила авторизации. Фактически эти правила выглядят точно так же, как показанные ранее правила, специфичные для пользователей. Например, следующие правила авторизации запрещают доступ анонимным пользователям, разрешая его двум конкретным пользователям (dan и alex) и двум группам (Manager и Supervisor). Доступ всем прочим пользователям запрещен:

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

Рассмотрим пример:

Ниже описано, как ASP.NET разбирает эти правила:

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

Всем пользователям из роли Guest доступ будет закрыт. Если alex входит в Guest, доступ ему остается открытым, потому что специфичное для пользователя правило найдено первым.

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

Затем доступ закрывается пользователю dan. Но если dan входит в группу Manager, доступ для него остается открытым.

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

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

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

Файловая авторизация

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

Чтобы понять суть файловой авторизации, необходимо разобраться, как операционная система Windows обеспечивает безопасность файловой системы. В случае файловой системы NTFS можно установить списки ACL (access control list - список контроля доступа) , указывающие идентичность пользователей и ролей, которым открыт или запрещен доступ к индивидуальным файлам. Модуль FileAuthorizationModule просто проверяет права доступа к запрошенному файлу, определенные Windows.

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

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

Чтобы понять необходимость в модуле FileAuthorizationModule, необходимо вспомнить, как ASP.NET выполняет код. Если не включено заимствование прав, ASP.NET выполняется от имени фиксированного пользовательской учетной записи, такой как ASPNET. Операционная система Windows будет проверять, имеет ли учетная запись ASPNET права, необходимые для доступа к файлу.aspx, но она не выполнит ту же проверку для пользователя, аутентифицированного IIS. Модуль FileAuthorizationModule заполняет этот пробел. Он осуществляет проверку авторизации с учетом контекста безопасности текущего пользователя. В результате системный администратор может устанавливать права доступа к файлам или папкам и контролировать доступ к частям приложения ASPNET. Обычно проще и удобнее использовать правила авторизации в файле web.config. Однако если необходимо воспользоваться преимуществами существующих привилегий Windows в локальной или корпоративной сети, то это можно сделать.