Основная идентификация Asp.net Использовать AspNetUserClaims или AspNetRoleClaims? - PullRequest
0 голосов
/ 18 мая 2018

Я все еще смущен всеми этими вещами идентичности.

Во-первых, я все еще запутался в разнице между ролями, политиками / утверждениями.Из того, что я читал, роли - это старый способ делать вещи, и он был сохранен для обратной совместимости, так значит ли это, что AspNetRoleClaims является частью этой обратной совместимости?

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

Были заявления, по сути, доверенный источник ручается заэтот пользователь (т. е. это его возраст, который может быть получен из правительственного источника).

Теперь меня смущает то, что я все это собираю.

Я сгенерировал таблицы идентификаторов и вижу

AspNetUsers
AspNetUserRoles
AspNetRoles
AspNetRoleClaims
AspNetUserClaims
AspNetUserLogins

Я понимаю, что делает таблица AspNetUsers и AspNetUserLogins (кажется, если они используют как внешние поставщики входа в систему).

Я запутываюсь в том, в чем разница между AspNetRoleClaims и AspNetUserClaims.Я просто использую AspNetUserClaims или я использую все?

Скажем, у меня есть этот сценарий

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

Как это все выглядит?Я делаю 3 роли?

CompanyAdmin
BranchAdmin
AddUsersAtBranchLevel (or is this some sort of claim??)
What do the tables look like? Is there anything going to be in AspNetRoleClaims? AspNetUserClaims?

Теперь я могу создать политику, чтобы проверить, является ли пользователь администратором филиала и пытаются ли они редактировать свою ветку?

Или я просто забываю все ролевые вещи и имею в AspNetUserClaims

User1   CanAddUserToBranch true
User1 CanDeleteUserBranch true
User1 CanAddUserToCompany true

Затем в моем коде создайте все эти разные "ClaimTypes" и создайте опрос, который проверяет, говорят ли они«CanAddUserToBranch», а затем другая заявка или политика, чтобы проверить, в какой ветке они находятся, чтобы убедиться, что они пытаются добавить что-то в нужную ветку?

Edit

Как вы думаете, мне нужно использоватьРесурсная авторизация?

1 Ответ

0 голосов
/ 28 мая 2018
+------------------+------------------+
|      Table       |   Description    |
+------------------+------------------+
| AspNetUsers      | The users.       |
| AspNetRoles      | The roles.       |
| AspNetUserRoles  | Roles of users.  |
| AspNetUserClaims | Claims by users. |
| AspNetRoleClaims | Claims by roles. |
+------------------+------------------+
  • Роль - это то, что назначено пользователю.
    • Например.Джейн - администратор.
  • Претензия - это то, на что претендует пользователь.
    • Например.Дата рождения Джейн - 1990-10-1.
  • Заявка на роль - это заявка на роль.
    • Например.Администраторы имеют доступ к панели управления.

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

Роли против Политики

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

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

    • Например: только администраторы старше 40 лет могут получить доступ к финансовым данным.

Скажите, что у меня естьэтот сценарий

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

Вот один из способов сделать это:

2 роли: Admin,TheRoleThatCanAddUsers
Претензия с именем Branch, которая может принимать идентификатор ветви (или что-либо еще для идентификации ветви).Администраторы компании могут использовать такие значения, как "CompanyWide" или 0 или -1.

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

...