Найкращі практики щодо ролей проти претензій в ідентифікації ASP.NET


94

Я абсолютно новачок у використанні claimsin ASP.NETIdentityі хочу отримати уявлення про найкращі практики використання Roles and/or Claims.

Після всього цього читання, у мене досі є запитання на зразок ...

З: Ми більше не використовуємо ролі?
З: Якщо так, чому ролі все ще пропонуються?
З: Чи слід використовувати лише претензії?
З: Чи варто нам використовувати Ролі та Претензії разом?

Моя початкова думка полягає в тому, що ми "повинні" використовувати їх разом. Я бачу Claimsпідкатегорії тих, кого Rolesвони підтримують.

НАПРИКЛАД :
Роль: Бухгалтерські
вимоги : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

З: Чи призначені вони для взаємовиключення?
З: Або краще подати ТІЛЬКИ претензії та "повністю кваліфікувати" ваші претензії?
З: То які найкращі практики тут?

ПРИКЛАД: Спільне використання ролей та вимог
Звичайно, вам доведеться написати власну логіку атрибутів для цього ...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

ПРИКЛАД: Повна кваліфікація Ваших вимог

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

1
Отже, зараз я стикаюся з такою ж проблемою, як ви її вирішуєте і як можна перепрограмувати дозвіл у додатку?
Loai

Відповіді:


77

Роль - це символічна категорія, яка збирає разом користувачів, які мають однакові рівні привілеїв безпеки. Рольова авторизація вимагає спочатку ідентифікації користувача, потім визначення ролей, яким призначений користувач, і, нарешті, порівняння цих ролей з ролями, які мають дозвіл на доступ до ресурсу.

На відміну від цього, позов не ґрунтується на групі, а на основі ідентичності.

з документації Microsoft :

Коли особу створюється, їй може бути призначена одна або кілька претензій, висунутих довіреною стороною. Претензія - це пара значень імен, яка представляє те, що є предметом, а не те, що суб'єкт може зробити.

Пізніше перевірка безпеки може визначити право на доступ до ресурсу на основі вартості однієї або кількох претензій.

Ви можете використовувати як узгоджено, так і використовувати один тип в одних ситуаціях, а інший - в інших ситуаціях. Це здебільшого залежить від взаємодії з іншими системами та вашої стратегії управління. Наприклад, менеджеру може бути простіше керувати списком користувачів, призначених для ролі, ніж керувати тим, кому призначено конкретну претензію. Претензії можуть бути дуже корисними в сценарії RESTful, коли ви можете призначити претензію клієнту, і тоді клієнт може пред'явити претензію для авторизації, а не передавати ім'я користувача та пароль для кожного запиту.


6
Я не вважаю, що це цілком точно. Я вважаю, що Претензії вказують особу, а не авторизацію. Те, що вони уповноважені робити, управляється окремо. Тобто вони можуть мати претензію, дата народження якої вказує на те, що їм більше 18 років. Ця претензія буде передана менеджеру авторизації, який може містити правило, яке говорить: "якщо їм більше 18 років, вони можуть редагувати ресурс X", але в самій претензії не вказано, що вони можуть / не можуть робити чи мати доступ. Те саме стосується ролей та інших претензій. Претензії вказують, хто ти, і використовуються для визначення того, що ти можеш зробити, але вони не говорять тобі безпосередньо
ChrisC

Супровідна документація для @ChrisC - це авторизація Microsoft на основі претензій в ASP.NET Core : "Претензія - це пара значень імені, яка представляє тему, а не те, що суб'єкт може зробити".
DrGriff

@DrGriff Дякуємо за надання цього посилання; Я деякий час розпитував про точність опису, який я дав; Думаю, я пояснив відповідь на основі цього посилання.
Клейс

29

Як докладно пояснив @Claies, твердження можуть бути більш описовими та мають глибоку роль. Я думаю про них як про ідентифікатори ваших ролей. У мене є ідентифікатор тренажерного залу, тому я належу до ролі членів. Я також відвідую уроки кікбоксингу, тому маю на них претензію на посвідчення особи. Для моєї заяви потрібно буде заявити про нову роль відповідно до моїх прав членства. Натомість у мене є ідентифікатори кожного класу групи, до якого я належу, замість безлічі нових типів членства. Ось чому претензії мені більше підходять.

Існує чудове відео з поясненнями Баррі Дорранса, який розповідає про перевагу використання претензій перед ролями. Він також заявляє, що ролі все ще існують у .NET для зворотної сумісності. Відео дуже інформативно про те, як працюють претензії, ролі, політики, авторизація та автентифікація.

Ви можете знайти його тут: ASP.NET Core Authorization with Barr Dorrans


8

Використовуючи різні методи автентифікації та авторизації протягом десятиліть, моя поточна програма MVC використовує наступну методологію.

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

Як звичайна практика, використовується клас атрибутів A ClaimsAuthorize. Оскільки більшість дій контролера є CRUD, у мене є генерація бази даних першого коду, яка переглядає всі дії контролера і створює типи претензій для кожного атрибута дії контролера Read / Edit / Create / Delete. Наприклад, від,

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

Для використання в режимі MVC View базовий клас контролера представляє елементи мішка подання

        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 для вибору набору дій для мінімізації "клацання", необхідного для вибору претензій. У режимі "Зберегти" претензії користувачів видаляються, а всі вибрані претензії додаються. Веб-програма завантажує претензії лише один раз, тому будь-які зміни повинні викликати перезавантаження в межах цих статичних даних.

Тому менеджери можуть вибрати, які претензії є в кожній ролі, а які претензії у користувача після встановлення їм ролі та тих претензій за замовчуванням. Система має лише невелику кількість користувачів, тому управління цими даними є простим


3

Щоб зрозуміти різницю між Ролями та Претензіями, ви стикаєтесь з обмеженням ролей та відчуваєте, як претензії надходять на цю проблему, тому, давайте, я дам вам два сценарії, щоб визнати силу претензій, коли роль не може вирішити ці проблеми:

1- Ваш веб-сайт повинен мати два модулі (сторінки, сервіс .. тощо), перший модуль для дитини (до 18 років), другий для дорослого (старше 18 років) ваша особа має претензію на день народження

вам потрібно створити політику щодо цієї претензії, тому авторизація для кожного модуля буде надана за цим значенням, і якщо вік користувача перевищує 18 років, він може перейти до модуля для дорослих, але не раніше цього віку

Роль - це логічний тип даних, який ви можете мати або не мати в ролі ролі не було значень солодощів

2 - на вашому сайті є рольовий користувач, і ви не хочете забороняти доступ користувачів для проведення технічного обслуговування без зміни коду

у претензіях ви можете створити політику UnderConstrain, яка, якщо справжній користувач не може переглядати сторінку, надає авторизацію властивості для користувача ролі.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.