Контроль доступу на основі ролі (RBAC) проти контролю доступу на основі претензій (CBAC) в ASP.NET MVC

Які основні переваги використання CBAC проти RBAC ? Коли краще використовувати CBAC і коли краще використовувати RBAC?

Я намагаюся зрозуміти загальні поняття моделі CBAC, але загальна ідея для мене все ще не зрозуміла.

Я спробую показати, як ви можете скористатися контролем доступу на основі претензій у контексті ASP.NET MVC.

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

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Пізніше ви зрозуміли, що іноді люди з ролі "Маркетинг" повинні мати можливість створити Замовника. Потім ви оновлюєте такий спосіб своєї дії

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

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

ви помітили ще одну проблему, і коли ви вирішите, що маркетинговим людям слід дозволити створювати клієнтів, вам потрібно оновити всі свої методи MVC Дія авторизації, скласти заявку, протестувати та розгорнути. Через кілька днів ви вирішили, що не потрібно робити маркетинг, а якусь іншу роль, щоб виконати завдання, тому ви шукаєте у своїй кодовій базі та видаляєте все "Маркетинг" з атрибута "Авторизувати" та додаєте нове ім'я ролі в атрибут "Авторизувати" ... Не здорове рішення. У цей момент ви зрозуміли б потребу в доступі до контролю доступу.

Контроль доступу на основі дозволів - це спосіб присвоєння різних дозволів різним користувачам і перевірка наявності у користувача дозволу на виконання дії з коду під час виконання. Після призначення різних дозволів різним користувачам, ви розумієте, що потрібно дозволити деяким користувачам виконувати якийсь код, якщо у користувача є якесь властивість, наприклад "Користувач Facebook", "Користувач тривалого часу" тощо. Дозвольте навести приклад. Скажіть, що ви хочете дозволити доступ до певної сторінки, якщо користувач увійшов у систему за допомогою Facebook. Тепер ви створили дозвіл "Facebook" для цього користувача? Ні, "Facebook" не звучить як дозвіл. Робить це ? Швидше це звучить як претензія. У той же час, дозволи можуть також виглядати як вимоги !! Отже, краще перевірити претензії та дозволити доступ.

Тепер повернемося до конкретного прикладу контролю доступу на основі претензій.

Ви можете визначити такий набір претензій, як цей:

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" тощо.

Тепер ви можете прикрасити свій метод дії так:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(зверніть увагу, [ClaimAuthorize (Permission = "CanCreateCustomer")] не може бути вбудований у бібліотеку класів MVC, я лише показую як приклад, ви можете використовувати бібліотеку класів, яка має таке визначення класу Attribute)

Тепер ви бачите, що методу дій CreateCustomer завжди буде потрібен дозвіл "CanCreateCustomer", і він ніколи не зміниться або майже не зміниться. Отже, у своїй базі даних ви створюєте таблицю дозволів (претензій) та відношення дозволу користувача. На панелі адміністратора ви можете встановити дозвіл (претензію) для кожного користувача, який може це зробити. Ви можете призначити дозвіл (вимогу) "CanCreateCustomer" будь-кому, хто вам подобається, і лише дозволений користувач зможе створити клієнта, а дозволений користувач зможе створити лише клієнта і нічого іншого (якщо ви не призначите інші дозволи для того ж користувача).

Ця модель безпеки пропонує вам чисту практику кодування. Більше того, коли ви пишете свій метод дії, вам не потрібно думати про те, хто може використовувати цей метод, скоріше ви можете бути впевнені, що той, хто використовує цей метод, матиме належний дозвіл (претензію), наданий адміністратором. Тоді адміністратор може вирішити, хто зможе робити що. Не ти як розробник. Ось як ваша бізнес-логіка відокремлена від логіки безпеки.

Кожен раз, коли хтось увійде, ваша програма перевірятиме доступні дозволи для цього користувача, і набір дозволів (претензій) буде доступний як додаткові властивості користувача, який наразі увійшов (зазвичай набір заявок зберігається як файл cookie для зареєстрованого користувача), тож вам не доведеться весь час перевіряти набір дозволів із бази даних. Суть полягає в тому, що ви отримуєте більше контролю над логікою безпеки у своїй програмі, якщо застосовуєте доступ на основі претензій, а не рольовий доступ. Насправді, Роль також може розглядатися як претензія.

Якщо у вашій заявці дуже мало програми, де було б лише дві ролі: Клієнт та Адміністратор, і немає шансів, що Клієнт зможе зробити що-небудь інше, крім того, що призначено робити у вашій заявці, то, можливо, на основі ролі контроль доступу буде служити цілі, але в міру того, як ваша програма зростатиме, ви в якийсь момент почнете відчувати потребу контролю доступу на основі претензій.

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

Які ролі

Роль = Об'єднання користувачів та дозволів.

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

З іншого боку, роль - це також сукупність користувачів. Якщо я додаю Боба та Алісу до ролі "Менеджери", то "Менеджери" тепер містять колекцію з двох користувачів на зразок групи.

Правда полягає в тому, що роль - це КОЛИЧНА колекція користувачів та колекція дозволів, зібраних разом. Візуально це можна розглядати як діаграму Венна.

Що таке група

Група = Колекція користувачів

"Група" - це суто колекція Користувачів. Різниця між групою та роллю полягає в тому, що роль має також колекцію дозволів, але група має лише колекцію користувачів.

Що таке дозвіл

Дозвіл = Що може зробити суб'єкт

Що таке набір дозволів

Набір дозволів = Колекція дозволів

У надійній системі RBAC Дозволи можуть також бути згруповані як користувачі. У той час як Групи - це набір лише користувачів, набір дозволів - це сукупність дозволів. Це дозволяє адміністратору одночасно додавати цілі колекції дозволів до ролей.

Як поєднуються користувачі, групи, ролі та дозволи

У надійній системі RBAC користувачі можуть бути додані до ролі окремо, щоб створити колекцію користувачів у ролі, або групи можуть бути додані до ролі, щоб додати колекцію користувачів до ролі за один раз. Так чи інакше, Роль отримує свою колекцію Користувачів за допомогою індивідуального додавання або додавання Групи до Ролі або додаванням до Ролі поєднання користувачів та груп. Дозволу можна продумувати так само.

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

Вся мета Ролей - одружитись на Користувачах з Дозволами. Таким чином, роль - це Спілка користувачів та дозволів.

Що таке претензії

Претензія = Що таке предмет "є"

Претензії НЕ Дозволи. Як зазначалося в попередніх відповідях, претензія - це те, що суб'єктом "є", а не тим, що може зробити суб'єкт ".

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

Коли використовувати претензії

Я вважав, що Претензії є корисними, коли потрібно прийняти рішення про авторизацію, коли Користувача не можна додати до ролі або рішення не ґрунтується на асоціації користувача з дозволом. Приклад користувача Facebook викликає це. Користувачем Facebook може бути не той, хто додається до "Ролі" ... вони просто деякі відвідувачі, засвідчені автентифікацією через Facebook. Хоча це не вписується в RBAC, це інформація, яку слід прийняти.

@CodingSoft використовував метафору нічного клубу у попередній відповіді, яку я хотів би продовжити. У цій відповіді водійське посвідчення було використано як приклад, який містив набір претензій, коли дата народження являє собою один із претензій, а значення претензії DateOfBirth використовується для перевірки на правило авторизації. Держава, яка видала водійські права, є органом, який надає претензії справжність. Тому, у сценарії нічного клубу, вистриб при дверях розглядає посвідчення особи водія людини, забезпечує, що його видав довірений орган, перевіряючи, чи це підроблений ідентифікатор (тобто повинен бути дійсний ідентифікаційний номер, виданий урядом), потім переглядає дату народження (одна з багатьох претензій на посвідчення водія), а потім використовує це значення, щоб визначити, чи є людина достатньо старшою для вступу до клубу. Якщо так,

Тепер, маючи на увазі цю базу, я хотів би продовжити це далі. Припустимо, що будівля, де знаходиться нічний клуб, містить офіси, кімнати, кухню, інші поверхи, ліфти, підвал тощо, куди можуть зайти лише працівники клубу. Крім того, певні працівники можуть мати доступ до певних місць, до яких інші працівники можуть не мати. Наприклад, менеджер може мати доступ до офісного поверху вище, ніж інші працівники не можуть отримати доступ. У цьому випадку є дві Ролі. Менеджер та працівник.

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

Якщо з будь-якої причини Ролі потрібно додати / видалити певні кімнати, це можна зробити за допомогою RBAC, але це не дуже підходить для претензії.

Дозволи на програмне забезпечення

Кодування ролей у програмі - погана ідея. Це важко кодує ціль ролі в додатку. Програма повинна мати лише дозволи, які діють як прапори Feature. Якщо прапорці функцій доступні за допомогою конфігурації, дозволу роблять доступними контекст безпеки користувача, який отриманий колекцією дозволів DISTINCT, зібраними з усіх ролей, в які розміщено користувача. Це те, що я називаю "ефективні дозволи". У додатку має бути лише менюможливих дозволів на функції / дії. Система RBAC повинна виконувати роботу над тим, щоб одружувати ці дозволи до користувачів через ролі. Таким чином, немає жорсткого кодування ролей, і єдиний раз, коли дозвіл змінюється, коли він видалений або доданий новий. Після додавання до програмного забезпечення дозволу його ніколи не слід змінювати. Її слід видаляти лише за необхідності (тобто, коли функція припинена в новій версії), і можна додавати лише нові.

Одне заключне зауваження.

Грант проти Дені

Надійна система RBAC і навіть система CBAC повинні розрізняти дотації та відмови.

Додавання дозволу до ролі повинно мати ВИБІР або ДЕНЬ. Якщо прапорці встановлені, усі GRANTed дозволи повинні бути додані до списку користувачів "Ефективні дозволи". Потім, після всього, що зробиться, список ЗАБОРОНЕНИХ Дозволів повинен змусити систему видалити ці дозволи зі списку ефективних дозволів.

Це дозволяє адміністраторам "налаштувати" кінцеві дозволи на тему. Найкраще, якщо дозволи можна також додавати безпосередньо користувачам. Таким чином, ви можете додати користувача до ролі менеджера, і вони отримають доступ до всього, але, можливо, ви хочете ЗАБЕЗПЕЧИТИ доступ до туалету леді, оскільки Користувач є чоловіком. Таким чином, ви додаєте чоловічого користувача до ролі менеджера, і додаєте Дозвіл на об'єкт "Користувач" за допомогою DENY, щоб він забирав лише доступ до кімнати леді.

Власне, це було б гарним кандидатом на претензію. Якщо у користувача є претензія "стать = чоловік", то перебування в ролі менеджера надає доступ до всіх приміщень, але туалет дами також вимагає претендувати на стать = жінка, а для чоловічих туалетів потрібна претензія на стать = чоловік. Таким чином, не потрібно було б налаштовувати дозвіл DENY для користувачів-чоловіків, оскільки правозастосування вимагає цього для всіх із єдиним правилом авторизації. Однак це можна зробити будь-яким способом.

Річ у тім, що за допомогою DENIAL of Permissions це полегшує управління ролями, оскільки можливі виключення.

Нижче наведена схема, яку я склав давно, яка показує модель RBAC. У мене немає графіки для претензій, але ви можете уявити, що вони є лише атрибутами, приєднаними до користувачів, де б вони не були. Також на діаграмі не відображаються групи (мені потрібно оновити її в якийсь момент).

Я сподіваюся, що це допомагає.

Це діаграма описаних вище RBAC

Оновлення 7 квітня 2019 р. На основі відгуків від @Brent (спасибі) ... видалено непотрібні посилання на попередні відповіді та пояснено початкову основу метафори "нічного клубу", надану @CodingSoft, щоб зробити цю відповідь зрозумілою, не маючи читати інші відповіді.

Я не повністю згоден з відповіддю Емрана

[Authorize(Roles="Sale")]

Наївно

Питання - як

  [Authorize(Roles="CustomerCreator")]

відрізняється від

 [ClaimAuthorize(Permission="CanCreateCustomer")]

Якщо обидва однаково хороші, навіщо нам потрібно претендувати?

Я думаю, що тому

Концепція претензій є більш загальною порівняно з Роллю

У контексті наведеного вище прикладу можна сказати, що "CustomerCreator" - це претензія типу "роль", надана "Asp.NETroleProvider"

Додаткові приклади формули винаходу.

1. "AAA" - претензія типу "MYExamSite.Score", надана "MYExamSite.com"

2. "Золото" - претензія типу "MYGYM.Membershiptype", надана "MYGYMApp"

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

Ролі існують і мають сенс лише в непрямому обсязі. Як правило, це програма або організаційна сфера (тобто Роль = Адміністратор). З іншого боку, претензії може "пред'явити" будь-хто. Наприклад, аутентифікація Google може створювати претензії, включаючи "електронну пошту" користувача, таким чином приєднуючи цей електронний лист до ідентичності. Google заявляє претензію, програма вибирає, чи зрозуміти та прийняти її. Сам додаток може згодом додавати претензію, яка називається "метод автентифікації" (як це робить основний ідентифікатор ASP.NET MVC) зі значенням "Google". Кожна претензія включає сферу, щоб можна було визначити, чи має претензія значення зовні, локально чи обидва (або більш дрібнозернисті, якщо потрібно).

Ключові моменти полягають у тому, що всі претензії явно прикріплені до ідентичності та містять явну область застосування. Ці претензії, звичайно, можуть бути використані для авторизації - і ASP.NET MVC надає підтримку для цього за допомогою атрибута "Авторизувати", але це не єдина або обов'язково навіть основна мета для претензій. Це, звичайно, не відрізняє його від ролей, які можна використовувати абсолютно однаковими способами для локальної авторизації.

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

Загалом, слід розглянути питання управління доступом на основі атрибутів (ABAC). RBAC і ABAC - це обидва поняття, визначені NIST, Національним інститутом стандартів і технологій. CBAC, з іншого боку, - це модель, яку підштовхує Microsoft, яка дуже схожа на ABAC.

Детальніше читайте тут:

• Сторінка NIST для контролю доступу на основі ролей
• Сторінка NIST управління доступом на основі атрибутів

Основне між RBAC та CBAC полягає в тому, що:

RBAC : користувач повинен бути призначений для ролі, яка має право на виконання дії.

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

Крім того, заявки на заявку подаються службами, що видають авторизацію (Служба безпеки Token STS), яким довіряє ваша заява (Довірена сторона)

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

Важливо спочатку проаналізувати, для чого потрібна автентифікація, перш ніж вирішити, який метод найкращий. З поданої нижче документації Microsoft йдеться про те, що "претензія - це не те, що може зробити суб'єкт. Наприклад, у вас може бути посвідчення водія, видане місцевим органом посвідчення водія. У вашому посвідченні водія вказана дата народження. У цьому випадку Найменування претензії буде DateOfBirth, значенням претензії буде ваша дата народження, наприклад, 8 червня 1970 року, а емітентом буде орган посвідчення водія. Авторизація, що базується на вимогах, найпростіше перевіряє вартість претензії та дозволяє отримати доступ ресурс, заснований на цьому значенні. Наприклад, якщо ви хочете отримати доступ до нічного клубу, процес авторизації може бути: 6 "

З цього прикладу ми бачимо, що доступ до найближчого клубу з дозволом на основі претензій зовсім не відрізняється від типу Авторизації, який вимагатиме персонал, який працює в нічному клубі; в цьому випадку персонал нічного клубу вимагатиме Рольова авторизація, яка не потрібна відвідувачам нічного клубу, оскільки всі відвідувачі нічного клубу мають загальну мету в нічному клубі, отже, у цій ситуації для відвідувачів нічного клубу підходить авторизація на основі претензій.

Авторизація на основі ролі https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 14.10.2016 При створенні ідентичності він може належати до однієї або декількох ролей. Наприклад, Трейсі може належати ролям адміністратора та користувача, тоді як Скотт може належати лише ролі Користувача. Те, як ці ролі створюються та керуються, залежить від резервного сховища процесу авторизації. Ролі піддаються розробнику методом IsInRole класу ClaimsPrincipal.

Авторизація на основі претензій https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 14.10.2016 При створенні посвідчення особи може бути призначена одна чи більше претензій, висунутих довіреною стороною. Претензія - пара значень імен, що представляє те, що є суб'єктом, а не те, що може зробити суб'єкт. Наприклад, у вас може бути посвідчення водія, видане місцевим органом посвідчення водія. У вашому водійському посвідченні вказана дата народження. У цьому випадку ім'ям претензії буде DateOfBirth, значенням претензії буде ваша дата народження, наприклад, 8 червня 1970 року, а емітентом буде орган посвідчення водія. Авторизація на основі претензій, найпростіше, перевіряє вартість претензії та дозволяє отримати доступ до ресурсу, що базується на цьому значенні. Наприклад, якщо ви хочете отримати доступ до нічного клубу, процес авторизації може бути таким:

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

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

Також можливо керувати ролями в порядку претензій.

Замість створення авторизаційних ролей, що відображають ділову роль, створіть ролі, які відображають ролі дій, наприклад, CreateCustomer, EditCustomer, DeleteCustomer. Методи коментування за потребою.

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

Можна навіть змінити ділову роль і безпосередньо додати людину до ролі дії.

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

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

1. AspNetUsers: кожен користувач має один рядок з усіма атрибутами, необхідними всім користувачам, як-от електронна пошта, адресний телефон, пароль ...
2. AspNetRoles; визначає різні ролі відповідно до вимог програми, такі як GM, CTO, HRM, ADMIN, EMP. що кожна роль визначає, відповідно до потреб програми.
3. AspNetUserRoles: кожен рядок посилає AspNetUsers і AspNetRoles і ефективно посилається між одним користувачем і багатьма ролями.
4. AspNetUserClaims: у кожному рядку є ключ до AspNetUsers та один тип та значення. тому ефективно додайте один атрибут для кожного користувача, який можна було б додати / видалити під час виконання.

Використання цих таблиць може бути налаштовано в один момент життя користувача / додатка, щоб відповідати конкретним потребам.

Розглянемо ранній етап "Менеджера з закупівель" (PM), ми могли б мати три підходи

1. Програма заповнює AspNetUserRoles одним рядком, щоб надати "PM" право на покупку. Для оформлення замовлення на будь-яку суму користувачеві потрібна лише роль "PM".

2. Додаток заповнює AspNetUserRoles одним рядком, щоб надати "PM" право на покупку, і заповнює AspNetUserClaims вимогу типу "Сума придбання" типу та значення "<1000", щоб встановити ліміт суми. Щоб оформити замовлення на покупку, користувачеві необхідно мати "PM", а сума замовлення буде меншою від вартості вимоги ТИП "Сума покупки".

3. Додаток заповнює AspNetUserClaims із претензією типу "Тип покупки" та значення "<1000". Будь-який користувач може оформити замовлення на купівлю, враховуючи, що сума повинна бути меншою, ніж вартість претензії.

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

Рольовий контроль доступу (RBAC)

У вашій організації можуть бути наступні ролі

Співробітник

Менеджер

HR

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

У ASP.NET Core для впровадження авторизації на основі ролей ми використовуємо атрибут Authorize з параметром Roles.

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

Контроль доступу на основі претензій (CBAC)

ЩО таке претензія? Претензія - пара імен-значення. Це дійсно інформація про користувача, а не те, що користувач може робити і чого не може. Наприклад, ім’я користувача, електронна пошта, вік, стать тощо - всі претензії. Як ви використовуєте ці претензії для перевірки авторизації у вашій заявці, залежить від вашого додатка та вимог авторизації.

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

Претензії засновані на політиці. Ми створюємо політику і включаємо в неї одну чи більше претензій. Потім політика використовується разом із параметром політики атрибута "Авторизувати" для реалізації авторизації на основі претензій.

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}