Введение
Тема аутентификации и авторизации всегда будет актуальна для большинства web-приложений. Многие .NET разработчики уже успели познакомиться с Windows Identity Foundation (WIF), его подходами и возможностями для реализации так называемых «identity-aware» приложений. Для тех, кто не успел поработать с WIF, первое знакомство можно начать с изучения следующего раздела MSDN. В данной же статье я предлагаю более детально взглянуть на так называемый «claims-based» подход к авторизации пользователей путем изучения того, как это может выглядеть на примере.
Claims-Based Authorization
«Claims-Based» авторизация это подход, при котором решение авторизации о предоставлении или запрете доступа определенному пользователю базируется на произвольной логике, которая в качестве входных данных использует некий набор «claims» относящихся к этому пользователю. Проводя аналогию с «Role-Based» подходом, у некого администратора в его наборе «claims» будет только один элемент с типом «Role» и значением «Administrator», например. Более детально, о преимуществах и проблемах, которые решает этот подход можно прочесть на том же MSDN, также советую посмотреть лекцию Доминика Байера.
В целом, вышеупомянутый подход поощряет разработчиков к разделению бизнес логики приложения от логики авторизации и это действительно удобно. Так как же это выглядит на практике? К ней собственно и приступим.
Постановка задачи
Предположим, что нужно создать некий API сервис, который будет доступен нескольким клиентским приложениям. Функционал у клиентских приложений разный, пользователи также. Возможно, появятся еще и другие клиентские приложения, со своими пользователями и схемой взаимодействия с API, поэтому нам необходимо иметь гибкую систему авторизации для того, чтобы иметь возможность на любом этапе сконфигурировать политику доступа к API для того или иного приложения/пользователя. API в нашем случае будет построено с использованием ASP.NET Web API 2.0, клиентскими приложениями будут, например, Windows Phone приложение и Web-сайт.
Рассмотрим приложения их пользователей и функционал более детально:
Windows Phone клиент
- Сам по себе может только регистрировать новых пользователей.
- Зарегистрированные пользователи могут:
- просматривать свой профиль;
- обновлять свой профиль;
- производить смену своего пароля;
Web клиент
- Сам по себе не имеет доступа к API.
- Зарегистрированные мобильным клиентом пользователи могут:
- просматривать свой профиль;
- обновлять свой профиль;
- производить смену своего пароля;
- Администраторы системы могут:
- всё то же, что и пользователи для своего аккаунта;
- всё то же, что и пользователи для аккаунта любого пользователя;
- просматривать список всех зарегистрированный пользователей;
- создавать/удалять пользователей;
Итак, мы имеем представление о том, какой функционал должен предоставляться через API, каким клиентам и с какими правилами. Что ж, приступим к реализации!
Реализация
Начнем с определения интерфейса будущего API сервиса:
public interface IUsersApiController
{
// List all users.
IEnumerable<User> GetAllUsers();
// Lookup single user.
User GetUserById(int id);
// Create user.
HttpResponseMessage Post(RegisterModel user);
// Restore user's password.
HttpResponseMessage RestorePassword(string email);
// Update user.
HttpResponseMessage Put(int id, UpdateUserModel value);
// Delete user.
HttpResponseMessage Delete(string email);
}
Непосредственную реализацию API оставим за скобками данной статьи, по крайней мере, для примера сойдет и вариант вроде этого:
public class UsersController : ApiController
{
//...
public HttpResponseMessage Post([FromBody]RegisterModel user)
{
if (ModelState.IsValid)
{
return Request.CreateResponse(HttpStatusCode.OK, "Created!");
}
else
{
return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
}
}
//...
}
Следующим шагом создадим наследника класса ClaimsAuthorizationManager и переопределим некоторые его методы. ClaimsAuthorizationManager — это именно тот компонент WIF, который позволяет в одном месте перехватывать входящие запросы и выполнять произвольную логику, которая исходя из набора «claims» текущего пользователя* решает о предоставлении или запрете доступа.
* — о том, где этот набор формируется поговорим чуть позже.
Не уходя далеко, мы можем позаимствовать его реализацию из MSDN по этой ссылке. Как видим из секции «Examples» переопределены следующие методы:
/// <summary>
/// Overloads the base class method to load the custom policies from the config file
/// </summary>
/// <param name="nodelist">XmlNodeList containing the policy information read from the config file</param>
public override void LoadCustomConfiguration(XmlNodeList nodelist)
{...}
/// <summary>
/// Checks if the principal specified in the authorization context is authorized
/// to perform action specified in the authorization context on the specified resource
/// </summary>
/// <param name="pec">Authorization context</param>
/// <returns>true if authorized, false otherwise</returns>
public override bool CheckAccess(AuthorizationContext pec)
{...}
Глядя на реализацию и комментарии к ней, можно разобраться что происходит и я не буду останавливаться на этом. Отмечу только формат политики доступа из этого примера:
...
<policy resource="http://localhost:28491/Developers.aspx" action="GET">
<or>
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="developer" />
<claim claimType="http://schemas.xmlsoap.org/claims/Group" claimValue="Administrator" />
</or>
</policy>
<policy resource="http://localhost:28491/Administrators.aspx" action="GET">
<and>
<claim claimType="http://schemas.xmlsoap.org/claims/Group" claimValue="Administrator" />
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country" claimValue="USA" />
</and>
</policy>
<policy resource="http://localhost:28491/Default.aspx" action="GET">
</policy>
...
Политика доступа здесь — это набор секций «policy», каждая из которых идентифицируется такими атрибутами как «resource» и «action». Внутри каждой такой секции перечислены «claims» которые необходимы для доступа к ресурсу. В случае WebApi «resource» — это имя контроллера, «action» — имя action-метода. Более того, есть возможность строить правила доступа с использованием логических условий*.
* — и всё бы замечательно если бы в текущей реализации была возможность конфигурировать больше 2-x элементов «claim» внутри блоков «and» или «or».
Пока используем всё «as-is», за исключением названия наследника, его изменим на XmlBasedAuthorizationManager. Если попробовать сбилдить проект, то окажется что нам не хватает класса PolicyReader, его можно взять из полных исходных кодов MSDN-примера.
После того, как новая реализация готова, сконфигурируем WebAPI приложение для использования ее в качестве менеджера авторизации. Для этого:
1. Зарегистрируем конфигурационные секции обязательные для работы WIF:
<configSections>
<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<!-- Others sections-->
</configSections>
2. Укажем какую реализацию следует использовать в качестве менеджера авторизации:
<system.identityModel>
<identityConfiguration>
<claimsAuthorizationManager type="YourProject.WebApi.Security.XmlBasedAuthorizationManager, YourProject.WebApi, Version=1.0.0.0, Culture=neutral">
<!-- Policies -->
</claimsAuthorizationManager>
<claimsAuthenticationManager type="YourProject.WebApi.Security.AuthenticationManager, YourProject.WebApi, Version=1.0.0.0, Culture=neutral" />
</identityConfiguration>
</system.identityModel>
Отлично, мы указали WIF какую реализацию использовать, но как вы заметили, в конфигурации выше остались две детали:
- вместо набора xml-секций «policy» у нас пусто;
- присутствует xml-элемент "
claimsAuthenticationManager", о котором я не упоминал ранее.
Рассмотрим эти пункты по порядку.
1. Конфигурация политики доступа
Возвращаясь к постановке задачи, а также учитывая уже рассмотренный формат политики доступа, попробуем составить конфигурацию для нашего API. Получится следующий набор правил:
<policy resource="Users" action="GetAllUsers">
<and>
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" />
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" />
</and>
</policy>
<policy resource="Users" action="Post">
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WPhoneApplication" />
</policy>
<policy resource="Users" action="RestorePassword">
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WPhoneApplication" />
</policy>
<policy resource="Users" action="GetUserById">
<or>
<and>
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" />
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" />
</and>
<and>
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="User" />
<!-- Как указать вместо {0} идентификатор пользователя который отправил "request" ? -->
<!-- <claim claimType="UserId" claimValue="{0}" /> -->
</and>
</or>
</policy>
<policy resource="Users" action="Put">
<or>
<and>
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" />
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" />
</and>
<and>
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="User" />
<!-- Как указать вместо {0} идентификатор пользователя который отправил "request" ? -->
<!-- <claim claimType="UserId" claimValue="{0}" /> -->
</and>
</or>
</policy>
Видим, что некоторые policy-секции проще, некоторые сложнее, некоторые повторяются. Рассмотрим по частям, начиная с простого варианта — политика доступа для получения списка пользователей:
<policy resource="Users" action="GetAllUsers">
<and>
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" />
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" />
</and>
</policy>
Все предельно очевидно: доступ к данному ресурсу есть у тех пользователей, набор «claims» которых содержит оба «сlaim» — элемента.
Теперь более сложный вариант — получение информации о пользователе по идентификатору:
<policy resource="Users" action="GetUserById">
<or>
<and>
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/system" claimValue="WebApplication" />
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="Admin" />
</and>
<and>
<claim claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claimValue="User" />
<!-- Как указать вместо {0} идентификатор пользователя который отправил "request" ? -->
<!-- <claim claimType="UserId" claimValue="{0}" /> -->
</and>
</or>
</policy>
Возвращаясь к требованиям, к данному ресурсу могут иметь доступ только администраторы веб приложения, а также пользователи при условии, что каждый пользователь может получать данные только по своему аккаунту. Как видим, первое требование мы без труда устанавливаем в первом <and>..</and> блоке. Но как же быть с пользователями?
К сожалению, текущая реализация, которую Мы доблестно скопировали, не позволяет сейчас конфигурировать это условие. К тому же, как я уже упоминал выше, она также не позволяет использовать внутри логических "and/or" блоков вложенные элементы. Если уж быть предельно честным, то эта реализация жестко устанавливает количество «claim» элементов равное двум внутри "and/or" блоков.
Что касается условия «каждый отдельный пользователь может получать данные только по своему аккаунту», то я планирую предложить свой вариант решения в следующей статье. Предлагаю пока смириться с тем, что все пользователи могут просматривать информацию друг о друге, как выходит из составленной конфигурации. Особенно пока реализация метода GetUserById выглядит как throw new NotImplementedException().
А вот чтобы текущая конфигурация работала исправно мы немного изменим реализацию класса PolicyReader:
/// <summary>
/// Read the Or Node
/// </summary>
/// <param name="rdr">XmlDictionaryReader of the policy Xml</param>
/// <param name="subject">ClaimsPrincipal subject</param>
/// <returns>A LINQ expression created from the Or node</returns>
private Expression<Func<ClaimsPrincipal, bool>> ReadOr(XmlDictionaryReader rdr, ParameterExpression subject)
{
Expression defaultExpr = Expression.Invoke((Expression<Func<bool>>)(() => false));
while (rdr.Read())
{
if (rdr.NodeType != XmlNodeType.EndElement && rdr.Name != "or")
{
defaultExpr = Expression.OrElse(defaultExpr, Expression.Invoke(ReadNode(rdr, subject), subject));
}
else
break;
}
rdr.ReadEndElement();
Expression<Func<ClaimsPrincipal, bool>> resultExpr
= Expression.Lambda<Func<ClaimsPrincipal, bool>>(defaultExpr, subject);
return resultExpr;
}
/// <summary>
/// Read the And Node
/// </summary>
/// <param name="rdr">XmlDictionaryReader of the policy Xml</param>
/// <param name="subject">ClaimsPrincipal subject</param>
/// <returns>A LINQ expression created from the And node</returns>
private Expression<Func<ClaimsPrincipal, bool>> ReadAnd(XmlDictionaryReader rdr, ParameterExpression subject)
{
Expression defaultExpr = Expression.Invoke((Expression<Func<bool>>)(() => true));
while (rdr.Read())
{
if (rdr.NodeType != XmlNodeType.EndElement && rdr.Name != "and")
{
defaultExpr = Expression.AndAlso(defaultExpr, Expression.Invoke(ReadNode(rdr, subject), subject));
}
else
break;
}
rdr.ReadEndElement();
Expression<Func<ClaimsPrincipal, bool>> resultExpr
= Expression.Lambda<Func<ClaimsPrincipal, bool>>(defaultExpr, subject);
return resultExpr;
}
Что ж, мы сконфигурировали политику доступа к ресурсам нашего API, создали реализацию менеджера авторизации, который умеет работать с нашей конфигурацией. Теперь можно перейти к аутентификации — этапу, который предшествует авторизации.
2. Аутентификация и ClaimsAuthenticationManager
Еще до того как принимать решение имеет ли пользователь доступ к ресурсу, сперва нужно произвести аутентификацию, и если она успешна — наполнить набор «claims» пользователя.
Для аутентификации будем использовать Basic Authentication и, например, ее реализацию в Thinktecture.IdentityModel.45. Для этого в NuGet-консоли выполним команду:
Install-Package Thinktecture.IdentityModel
Код класса WebApiConfig изменим, чтобы он был приблизительно следующим:
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
var authentication = CreateAuthenticationConfiguration();
config.MessageHandlers.Add(new AuthenticationHandler(authentication));
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
config.EnableSystemDiagnosticsTracing();
config.Filters.Add(new ClaimsAuthorizeAttribute());
}
private static AuthenticationConfiguration CreateAuthenticationConfiguration()
{
var authentication = new AuthenticationConfiguration
{
ClaimsAuthenticationManager = new AuthenticationManager(),
RequireSsl = false //only for testing
};
#region Basic Authentication
authentication.AddBasicAuthentication((username, password) =>
{
var webSecurityService = ServiceLocator.Current.GetInstance<IWebSecurityService>();
return webSecurityService.Login(username, password);
});
#endregion
return authentication;
}
}
Здесь отмечу только то, что для проверки credentials пришедших из запроса у меня используется некий IWebSecurityService. Вы можете использовать здесь свою логику, например: return username == password;
Теперь при каждом запросе к любому ресурсу будет производиться проверка аутентификации, но еще нам нужно трансформировать базовый набор «claims» текущего пользователя. Этим занимается ClaimsAuthenticationManager, а точнее наш наследник этого класса, который мы уже зарегистрировали:
public class AuthenticationManager : ClaimsAuthenticationManager
{
public override ClaimsPrincipal Authenticate(string resourceName, ClaimsPrincipal incomingPrincipal)
{
if (!incomingPrincipal.Identity.IsAuthenticated)
{
return base.Authenticate(resourceName, incomingPrincipal);
}
var claimsService = ServiceLocator.Current.GetInstance<IUsersClaimsService>();
var claims = claimsService.GetUserClaims(incomingPrincipal.Identity.Name);
foreach (var userClaim in claims)
{
incomingPrincipal.Identities.First().AddClaim(new Claim(userClaim.Type, userClaim.Value));
}
return incomingPrincipal;
}
}
Как видим, если пользователь прошел аутентификацию — происходит получение его набора «claims», скажем из БД, посредством использования вновь созданного экземпляра IUsersClaimsService. После «трансформации» экземпляр ClaimsPrincipal возвращается дальше в конвеер для последующего использования, например, авторизацией.
Проверка результата
Пришло время проверить работоспособность нашего решения. Для этого нам естественно понадобятся пользователи с теми или иными «claims». Не будем долго фантазировать над тем откуда их взять и немного видоизменим AuthenticationManager в целях тестирования. Вместо использования IUsersClaimsService вставим следующий код:
public class AuthenticationManager : ClaimsAuthenticationManager
{
public override ClaimsPrincipal Authenticate(string resourceName, ClaimsPrincipal incomingPrincipal)
{
...
if (incomingPrincipal.Identity.Name.ToLower().Contains("user"))
{
incomingPrincipal.Identities.First().AddClaim(new Claim(ClaimTypes.Role, "User"));
}
return incomingPrincipal;
}
}
Отлично, теперь все пользователи, логин которых содержит слово «user» будут содержать нужный «claim».
Запустим проект и перейдем по ссылке localhost:[port]/api/users
Вводим заветные логин и пароль, наша незамысловатая авторизация проверить их на равенство, а менеджер авторизации трансформирует набор «claims»:
Продолжим выполнение и убедимся, что простой смертный не может просматривать список всех пользователей:
Теперь давайте вспомним о том, что на этапе конфигурирования политики доступа нам пришлось на некоторое время разрешить всем пользователям просматривать информацию друг о друге, этим и воспользуемся. Попробуем узнать о пользователе с Id=100, зайдя по ссылке ~/api/users/100:
И вот мы наблюдаем, что некая реализация, появившаяся в кулуарах, возвращает информацию о любом пользователе :)
Заключение
Итак мы познакомились с некоторыми возможностями WIF, разобрали пример того, с чего можно начать при построении гибкой системы авторизации, а также немного «покодировали».
Спасибо за внимание.
Автор: sqrter
