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

Каковы основные преимущества использования CBAC против RBAC? Когда лучше использовать CBAC и когда лучше использовать RBAC?

Я пытаюсь понять общие понятия модели CBAC, но общая идея до сих пор не ясна для меня.

Ответ 1

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

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

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

Позже вы поняли, что иногда люди из роли "Маркетинг" должны иметь возможность создавать Клиента. Затем вы обновляете свой метод действий таким образом

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

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

вы заметили еще одну проблему: в любое время, когда вы решаете, что рекламодателям должно быть разрешено создавать клиентов, вам необходимо обновить все ваши методы MVC Action. Определить атрибут, скомпилировать ваше приложение, протестировать и развернуть. Несколько дней спустя вы решили не продавать, а какую-то другую роль должны быть разрешены для выполнения этой задачи, поэтому вы выполняете поиск в своей кодовой базе и удаляете все атрибуты "Маркетинг" из авторизирования и добавляете свое новое имя роли в атрибуте Authorize... Не здоровое решение. В этот момент вы поймете необходимость в управлении доступом на основе разрешения.

Контроль доступа на основе разрешений - это способ назначения различных разрешений для разных пользователей и проверки того, имеет ли пользователь разрешение на выполнение действия из кода во время выполнения. После того, как вы назначаете различные разрешения для разных пользователей, вы понимаете, что вам нужно разрешить некоторым пользователям выполнять какой-либо код, если у пользователя есть какое-то свойство, например "Пользователь Facebook", "Долгое время" и т.д. Позвольте мне привести пример. Предположим, вы хотите разрешить доступ к определенной странице, если пользователь зарегистрировался с помощью Facebook. Теперь вы бы создали для этого пользователя разрешение "Facebook"? Нет, "Facebook" не звучит как разрешение. Имеет ли это? Скорее это звучит как требование. В то же время, разрешения могут звучать как претензия тоже!! Таким образом, лучше проверить требования и разрешить доступ.

Теперь вернемся к конкретному примеру контроля доступа на основе требований.

Вы можете определить некоторый набор требований, например:

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" и т.д.

Теперь вы можете украсить свой Action Method следующим образом:

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

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

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

Эта модель безопасности предлагает вам чистую практику использования кода. Более того, когда вы пишете свой Action Method, вам не нужно думать о том, кто может использовать этот метод, но вы всегда можете быть уверены, что тот, кто использует этот метод, получит правильное разрешение (требование), предоставленное администратором. Затем администратор может решить, кто сможет что-то сделать. Не вы, как разработчик. Вот как ваша бизнес-логика отделена от логики безопасности.

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

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

Ответ 2

Я не совсем согласен с ответом Эмран

[Authorize(Roles="Sale")]

Является наивным

Вопрос в том, как

  [Authorize(Roles="CustomerCreator")]

отличается от

 [ClaimAuthorize(Permission="CanCreateCustomer")]

Если оба одинаково хороши, зачем нам требовать?

Я думаю, потому что

Концепция претензий более общая по сравнению с ролью

В приведенном выше примере мы можем сказать, что "CustomerCreator" - это требование типа "роль", предоставляемое "Asp.NETroleProvider"

Дополнительные примеры заявлений.

"AAA" - это требование типа "MYExamSite.Score", предоставленное "MYExamSite.com"
"Золото" - это требование типа "MYGYM.Membershiptype", предоставленное "MYGYMApp"

Ответ 3

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

Роли существуют и имеют смысл только в неявном объеме. Обычно это прикладная или организационная сфера (т.е. Роль = администратор). Заявки, с другой стороны, могут быть "сделаны" кем угодно. Например, аутентификация Google может выдвигать претензии, включая "электронную почту" пользователя, таким образом прикрепляя это электронное письмо к личности. Google предъявляет претензии, приложение выбирает, следует ли понимать и принимать это требование. Само приложение может впоследствии присоединить утверждение под названием "метод аутентификации" (как это делает ASP.NET MVC Core Identity) со значением "Google". Каждая претензия включает в себя объем, чтобы можно было определить, имеет ли претензия значение внешне, локально или и то, и другое (или более детально по мере необходимости).

Ключевым моментом является то, что все утверждения явно привязаны к идентичности и включают в себя явный объем. Эти утверждения, конечно, могут быть использованы для авторизации, и ASP.NET MVC обеспечивает их поддержку с помощью атрибута Authorize, но это не единственная или не обязательно основная цель утверждений. Это, конечно, не отличает его от ролей, которые могут использоваться точно так же для локальной авторизации.

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

Ответ 4

Я уже много раз реализовывал модели безопасности, и мне тоже пришлось обдумать эти концепции. Сделав это много раз, вот мое понимание этих концепций.

Каковы роли

Роль = Союз пользователей и прав.

С одной стороны, роль - это набор разрешений. Мне нравится называть это разрешением. При определении роли вы в основном добавляете в эту группу набор разрешений, поэтому в этом смысле роль является профилем разрешений.

С другой стороны, Роль также является коллекцией пользователей. Если я добавлю Боба и Алису в роль "Менеджеры", то "Менеджеры" теперь содержат коллекцию из двух пользователей, вроде группы.

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

Что такое группа

Группа = Коллекция пользователей

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

Что такое разрешение

Разрешение = Что может сделать субъект

Что такое набор разрешений

Набор разрешений = набор разрешений

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

Как пользователи, группы, роли и разрешения объединяются

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

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

Вся цель ролей состоит в том, чтобы женить пользователей на разрешениях. Следовательно, роль - это СОЮЗ пользователей и разрешений.

Какие претензии

Претензия = Что такое "субъект"

Претензии не являются разрешениями. Как указывалось в предыдущих ответах, Претензия - это то, что субъект "является", а не то, что "может сделать" субъект.

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

Когда использовать претензии

Я считаю, что утверждения полезны, когда необходимо принять решение об авторизации, когда пользователь не может быть добавлен к роли или решение не основано на связи пользователя с разрешением. Пример пользователя Facebook вызывает это. Пользователь Facebook не может быть кем-то, кто добавлен в "Роль"... он просто является каким-то посетителем, прошедшим проверку подлинности через Facebook. Хотя это не вписывается в RBAC, это часть информации, по которой необходимо принять решение об авторизации.

@CodingSoft использовал метафору ночного клуба в предыдущем ответе, который я хотел бы расширить. В этом ответе водительское удостоверение использовалось в качестве примера, который содержал набор утверждений, в которых дата рождения представляет собой одно из утверждений, а значение требования DateOfBirth используется для проверки на соответствие правилу авторизации. Правительство, которое выдало водительские права, является органом, который придает претензии подлинность. Таким образом, в сценарии с ночным клубом вышибала у двери смотрит на человека, имеющего водительские права, гарантирует, что оно было выдано доверенным органом, проверяя, является ли это поддельным ID (т.е. Должен быть действительным выданным правительством ID), затем смотрит на дату рождения (одна из многих претензий на водительские права), а затем использует это значение, чтобы определить, достаточно ли взрослый человек, чтобы войти в клуб. Если это так, человек передает правило авторизации в силу наличия действительной претензии, а не в какой-либо роли.

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

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

Если по какой-либо причине определенная комната должна быть добавлена /удалена с помощью роли, это можно сделать с помощью RBAC, но это не подходит для заявки.

Разрешения в программном обеспечении

Кодирование ролей в приложении - плохая идея. Это жестко кодирует цель роли в приложении. Приложение должно иметь только разрешения, которые действуют как функциональные флаги. В тех случаях, когда флаги функций становятся доступными посредством конфигурации, разрешения становятся доступными благодаря контексту безопасности пользователя, который определяется коллекцией разрешений DISTINCT, собранных для всех ролей, в которые был помещен пользователь. Это то, что я называю "эффективными разрешениями". Приложение должно только представить меню возможных разрешений на функции/действия. Система RBAC должна выполнять работу по объединению этих разрешений с пользователями через роли. Таким образом, не существует жесткого кодирования ролей, и единственный раз, когда разрешение изменяется, когда оно удаляется или добавляется новое. После того, как разрешение добавлено в программное обеспечение, оно никогда не должно изменяться. Его следует удалять только при необходимости (т.е. Когда функция прекращается в новой версии), и можно добавлять только новые.

Последнее замечание

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

Надежная система RBAC и даже система CBAC должны различать гранты и отказы.

Добавление разрешения к роли должно сопровождаться либо GRANT, либо DENY. Когда разрешения проверены, все предоставленные разрешения должны быть добавлены в список пользователей действующих разрешений. Затем после того, как все это будет сделано, список ЗАКЛЮЧЕННЫХ разрешений должен заставить систему удалить эти разрешения из списка действующих разрешений.

Это позволяет администраторам "настраивать" окончательные разрешения субъекта. Лучше всего, если разрешения также могут быть добавлены непосредственно к пользователям. Таким образом, вы можете добавить пользователя к роли менеджера, и он получит доступ ко всему, но, возможно, вы захотите ДЕНЬ получить доступ к женской уборной, потому что пользователь - мужчина. Таким образом, вы добавляете мужчину-пользователя в роль менеджера и добавляете разрешение для объекта пользователя с помощью DENY, чтобы он лишал доступ только к этой комнате леди.

На самом деле, это был бы хороший кандидат на претензию. Если у пользователя есть претензия "пол = мужчина", то присутствие в роли менеджера дает доступ ко всем комнатам, но в туалете Леди также требуется претензия пол = женщина, а в мужской комнате требуется претензия пол = мужчина. Таким образом, не нужно было бы настраивать разрешение DENY для пользователей-мужчин, так как принудительное применение претензий заботится об этом для всех с одним правилом авторизации. Тем не менее, это может быть сделано в любом случае.

Дело в том, что с помощью DENIAL of Permissions упрощается управление ролями, поскольку могут быть реализованы исключения.

Ниже приведена схема, которую я сделал давным-давно, которая показывает модель RBAC. У меня нет графика для утверждений, но вы можете себе представить, что это просто атрибуты, прикрепленные к пользователям, где бы они ни находились. Кроме того, диаграмма не показывает группы (мне нужно обновить его в какой-то момент).

Надеюсь, это поможет.

Это схема описанного выше RBAC

Ответ 5

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

Узнайте больше здесь:

Страница NIST управления доступом на основе ролей
Страница NIST управления доступом на основе атрибутов

Ответ 6

Основой между RBAC и CBAC является то, что:

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

CBAC: у пользователя должна быть претензия с правильным значением, как ожидается, приложением, для авторизации. Контроль доступа на основе претензий является элегантным для написания и упрощения обслуживания.

Помимо того, что претензии выдаются приложению с помощью служб авторизации выдачи (STK службы безопасности), которым доверяет ваше приложение (Сторона-доверенность)

Ответ 7

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

Ответ 8

Важно сначала проанализировать, для чего требуется аутентификация, прежде чем принимать решение о том, какой метод лучше. Из приведенной ниже документации 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 10/14/2016 После создания удостоверения ему может быть назначено одно или несколько утверждений, выданных доверенной стороной, Претензия - это пара имя-значение, представляющая субъекта, а не то, что субъект может сделать. Например, у вас может быть водительское удостоверение, выданное местным органом по выдаче водительских прав. В вашем водительском удостоверении указана дата вашего рождения. В этом случае именем претензии будет DateOfBirth, значением претензии будет ваша дата рождения, например, 8 июня 1970 г., а эмитентом будет орган, имеющий водительские права. Авторизация на основе утверждений, в самом простом случае, проверяет значение утверждения и предоставляет доступ к ресурсу на основе этого значения. Например, если вы хотите получить доступ к ночному клубу, процесс авторизации может быть следующим:

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

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

Ответ 9

Также возможно управлять ролями в соответствии с требованиями.

Вместо создания ролей авторизации, которые отражают бизнес-роль, создавайте роли, которые отражают роли действий, например. CreateCustomer, EditCustomer, DeleteCustomer. При необходимости аннотируйте методы.

Совсем не просто сопоставить людей с набором ролей действий, особенно по мере увеличения списка ролей. Поэтому вам необходимо управлять бизнес-ролями на более низком уровне детализации (например, Sales, Marketing) и сопоставлять бизнес-роль с требуемыми ролями действий. I.e., добавьте пользователя в бизнес-роль и сопоставьте его с требуемыми (действительными) ролями в существующей таблице авторизации.

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

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

Ответ 10

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

AspNetUsers: у каждого пользователя есть одна строка со всеми атрибутами, необходимыми для всех пользователей, такими как электронная почта, адрес телефона, пароль.....
AspNetRoles; определяет различные роли в соответствии с требованиями приложения, такими как GM, CTO, HRM, ADMIN, EMP. что каждая роль определяет в соответствии с потребностями приложения.
AspNetUserRoles: каждая строка связывает AspNetUsers и AspNetRoles и эффективно связывает между одним пользователем и многими ролями.
AspNetUserClaims: каждая строка имеет ключ к AspNetUsers и один тип и значение. так эффективно добавьте один атрибут для каждого пользователя, который может быть добавлен/удален во время выполнения.

Использование этих таблиц может быть изменено в один момент времени жизни пользователя/приложения в соответствии с конкретными потребностями.

Рассмотрим раннюю стадию "Менеджер по закупкам" (PM), у нас может быть три подхода

Приложение заполняет AspNetUserRoles одной строкой, чтобы предоставить "PM" право на покупку. Чтобы оформить заказ на любую сумму, пользователю требуется только роль "ПМ".
Приложение заполняет AspNetUserRoles одной строкой, чтобы предоставить "PM" право на покупку, и заполняет AspNetUserClaims заявку типа TYPE "Закупочная сумма" и значением "<1000" для установки предела суммы. Чтобы оформить заказ на поставку, пользователь должен иметь "PM", а сумма заказа должна быть меньше суммы претензии ТИП претензии "Сумма закупки".
Приложение заполняет AspNetUserClaims заявкой типа TYPE "Закупочная сумма" и значением "<1000". Любой пользователь может оформить заказ на поставку, учитывая, что сумма будет меньше суммы претензии ТИП "Сумма закупки" для этого пользователя.

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