1

В настоящее время я разрабатываю систему с использованием ядра asp.net, и я бы хотел применить авторизацию на основе утверждений, но одна конкретная часть меня сбивает с толку.Как управлять требованиями пользователей?

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

Однако этот эмитент не хранится в идентификаторе db, поэтому как обработчик затем проверяет эмитент?

Я не понимаю, как все это работает? Мое понимание заключалось в том, что пользователь предъявляет претензии какого-либо типа, что их требование имеет определенное значение, а эмитент является валидатором типа претензии, фактически имеющим это значение для этого пользователя.

Обработчик проверит значение и может проверить эмитента, но не может, когда db его не сохраняет. Тогда я не понимаю смысла эмитента.

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

Пожалуйста, помогите мне разобраться.

Я испытал это как так:

  1. Использование ядра asp.net приложение с Identity.
  2. Зарегистрировать пользователя.
  3. Добавить требование к пользователю, который включает в себя тип, значение и эмитент. (Например, Employeenumber, 312, Microsoft.
  4. Добавить [Авторизовать (Политика = «MicrosoftEmployeesOnly»)] на контроллер/действие, чтобы ограничить доступ.
  5. Добавить политику в сферу услуг в StartUp.cs с требованием.
  6. Код требования, который имеет обработчик, который проверяет, что у пользователя есть требование типа EmployeeNumber, имеет значение и выдается Microsoft.
  7. Логин и заявки пользователей будут загружены из db в личность .
  8. Обработчик не сможет проверить пользователя, так как эмитент (Microsoft) был утерян и теперь просто говорит, что Local Authority.

Единственное, что я могу придумать здесь, - это то, что требование добавляется в db, оно считается подтвержденным Microsoft и теперь поддерживается приложением (Local Authority) от имени Microsoft.

Если это правда, то:

  1. Почему проверить эмитент вообще в любом обработчике?
  2. Как отменить иск?

Я бы предпочел, чтобы иметь возможность по желанию обратиться к этому эмитенту и проверить требование, когда захочу, то есть эмитент может аннулировать/аннулировать иск. Сотрудник утверждает, что у них есть номер сотрудника в Microsoft, и первоначально Microsoft подтвердила это. Спустя некоторое время Microsoft удалил сотрудника и удалил его. Приложение должно иметь возможность проверять с Microsoft каждый раз, когда пользователь входит в систему, чтобы узнать, действительно ли требование. В этом случае это уже недействительно.

Я немного смущен?

+0

Эй. Извините, мне пришлось удалить свой ответ, потому что у меня нет времени, чтобы исправить мой ответ, и в его текущем состоянии кажется, что это не то, что вы ищете ... Я надеюсь, что другой пользователь сможет помочь вам. –

+0

Matías - Спасибо за ваше время в любом случае –

ответ

1

проводки это здесь, как вы связаны с этим вопросом from my blog, и это может быть полезным для кого-то

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

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

Идентичность пользователя проверяется в процессе аутентификации, и в то момент вы задаете набор из Claims, что пользователь имеет в ClaimsIdentity объект. Это тот факт, что вы получаете заявки от базы данных и убедитесь, что они получают только те, которые у них должны быть. Если вам нужно, чтобы кто-то подтвердил претензии, тогда вам понадобится , чтобы весь этот процесс происходил за пределами этого. Только претензии , которые были подтверждены, должны быть добавлены к ClaimsIdentity.

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

И ваш последующий ответ:

Спасибо за ваш ответ. Теперь я понимаю, что эти претензии являются эффективно проверенными претензиями, когда они попадают в дБ. Я предполагаю, что можно удалить из db как способ аннулирования претензии.

Однако, я считаю, что, как вы полагаете, наилучшим способом является наличие этой системы снаружи, и она просто предоставляет претензии по мере необходимости. Дизайн заключается в том, что приложение будет иметь учетные записи для разных типов объектов , и учетные записи будут иметь возможность предъявлять претензии, например, что «I am родитель». Родитель хотел бы получить авторизационную учетную запись для подтверждения . Это может потребовать, чтобы владелец авторизационной учетной записи фактически видел фактическую документацию перед проверкой. Другие претензии, может изменение. Например, у родителя с родительской ответственностью потребуется еще бит, но он также может потерять эту родительскую ответственность в реальном мире, и поэтому средство для отзыва претензии должно быть .

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

+1

Спасибо. Я просто разместил здесь ответ, ссылаясь на ваш ответ в вашем блоге. Поэтому я просто добавлю: Отличный отклик от Andrew Lock по адресу: [Andrew Lock] (https://andrewlock.net). Я пытался подтолкнуть систему претензий к тому, что она не была предназначена для этого, поэтому решение состоит в том, чтобы написать проверку и аннулирование вне системы претензий и включить только те утверждения, которые проверены. См. Статью и комментарии здесь: [Введение в авторизацию в ядре ASP.NET] (https://andrewlock.net/introduction-to-authorisation-in-asp-net-core/) –