Как управлять несколькими типами пользователей в IdentityServer4, используя AspNet Identity? - PullRequest
0 голосов
/ 19 июня 2019

Каков наилучший способ хранения вашей пользовательской информации для каждого клиента? У меня есть несколько приложений, которые все используют один и тот же экземпляр IdentityServer для проверки подлинности. ASP.NET Identity показывает, как расширить пользователя путем наследования от IdentityUser.

public class CustomUser : IdentityUser
{
   public Int32 CompanyId { get; set; }
}

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

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

Если кто-нибудь знает лучший способ, дайте мне знать.

Если было бы идеально, если бы UserManager разрешал регистрацию с несколькими пользовательскими типами пользователей, и вы могли получать разные подмножества данных на основе вашего выбора, в то время как каждый запрос был оптимизирован только для тех данных, которые ему необходимы. Затем вы можете поместить индекс SQL для каждого типа и, возможно, даже пользовательский TPH в структуру сущностей для организации информации.

1 Ответ

0 голосов
/ 21 июня 2019

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

Что касается более конкретных приложений ... почему бы не хранить такие вещи ближе к приложениям и ссылкам по идентификатору пользователя ...

...