Рекомендации по сопоставлению ролей и утверждений в ASP.NET идентичность

Как прекрасно объяснил @Claies, претензии могут быть более описательными и являются глубокой ролью. Я думаю о них как о ваших ролевых идентификаторах. У меня есть идентификатор спортзала, поэтому я принадлежу к роли членов. Я также нахожусь на уроках кикбоксинга, поэтому у меня есть претензии к ним; идентификатор кикбоксинга. Для того чтобы мое заявление соответствовало моим правам на членство, необходимо было бы провозгласить новую роль. Вместо этого у меня есть идентификаторы для каждой специальной вещи, которую я могу сделать в тренажерном зале; вместо множества новых типов членства. Вот почему претензии подходят лучше для мне.

есть отличное объяснение видео Барри Дорранса, говорящее о преимуществе использования утверждений над ролями. Он также заявляет, что роли по-прежнему находятся в .NET для обратной совместимости. Видео очень информативно о том, как работают утверждения, роли, политики, авторизация и аутентификация.

вы можете найти его здесь:ASP.NET авторизация ядра с помощью Barr Dorrans

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

претензии используются для авторизации. Пользователям назначается одна роль (возможно несколько ролей, но мне это не нужно) - подробнее ниже.

, что является общепринятой практикой, использовать класс атрибута ClaimsAuthorize это. Поскольку большинство действий контроллера являются CRUD, у меня есть процедура в первом поколении базы данных кода, которая повторяет все действия контроллера и создает типы утверждений для каждого атрибута действия контроллера Read/Edit/Create/Delete. Например, от,

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

для использования в представлении MVC базовый класс контроллера представляет элементы мешка представления

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

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

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

Так где же роли вписываются?

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