Для IdentityServer существует только один тип пользователя, который должен быть аутентифицирован.Таким образом, все пользователи должны быть перемещены в одну и ту же таблицу (вопрос миграции - другой вопрос).Если перемещение пользователей за одну таблицу является проблемой, то IdentityServer может не подходить для обеспечения безопасности.Хотя можно поддерживать отдельные таблицы, создавая пользовательское хранилище.Для каждого пользователя может быть включена двухфакторная аутентификация.Вы можете использовать дополнительные гранты для реализации пользовательских грантов.
Вся цель безопасности - защитить ваши ресурсы: API.В IdentityServer имя ресурса - это логическое имя для функциональности, которая может быть разделена на несколько областей, где область действия является определенной функциональностью.
Api1 может быть ресурсом с несколькими областями (например, Api1.Read иApi1.Write) или просто Api1.Но Api1, Api2 и Api3 также могут быть частью ресурса Api, где Api1, Api2 и Api3 фактически являются областями действия .В вашем случае Api1 может быть ресурсом с Api1 в качестве scope .
Чтобы пользователь мог получить доступ к ресурсу, который вам понадобитсяклиентское приложение, хотя у вас может быть много клиентов, которые могут получить доступ к одному и тому же ресурсу.Для поддержки различных типов клиентов можно выбрать несколько типов грантов.
IdentityServer позволяет настроить полную картину.
Предположим, что есть одинклиент, имеющий доступ к различным API, где каждый Api является ресурсом / областью действия.
Клиенту необходимо разрешить доступ к Api от имени пользователя , поскольку клиент можетДоступ к ресурсу без пользователя.
Таким образом, клиенту должно быть разрешено использовать определенные области, где клиент должен запрашивать область действия.Без этого клиент не может получить доступ к ресурсу.Предположим, что клиент настроен на Api1 и Api2, но клиент запрашивает только Api1.Тогда Api2 и Api3 недоступны.
Это все часть авторизации на верхнем уровне.Теперь пришло время привлечь пользователя.Когда клиент обращается к API, API знает, какой пользователь сделал запрос (так как sub является частью токена доступа).Но этого недостаточно для предоставления или отказа в доступе.
Так что вам нужно что-то для авторизации пользователя.Есть много вариантов, как это реализовать.Взгляните на документацию .
Рассмотрим простую реализацию, в которой есть три политики.И каждая политика гарантирует, что доступ имеет только пользователь соответствующего типа.
Тогда возникает вопрос: как определить тип пользователя?
Вы можете добавить заявку втаблица UserClaims .Давайте предположим, что ClaimType равно UserType, а значение равно 1.В ресурсе добавьте политику, которая проверяет заявку UserType и требуемое значение.
Чтобы IdentityServer мог добавить заявку в маркер доступа, убедитесь, что требуемый тип является частью области действия (или ApiResource).когда несколько областей настроены и нуждаются в requestType).
При добавлении requestType UserType в область действия Api_ это означает, что при доступе к области необходимо включить утверждение.IdentityServer пытается ограничить количество утверждений в токене доступа путем фильтрации только по запрошенным утверждениям.
Когда пользователь обращается к Api_, утверждение должно быть частью токена доступа (при условии, что утверждение установлено для каждогопользователь, в противном случае пользователь не имеет доступа вообще).Вы можете повторить эту настройку для других API (областей).
В этом случае я думаю, что это приемлемое решение.Другие варианты - авторизация на более низком уровне (на основе ресурсов) или аутсорсинг, например PolicyServer .
Обратите внимание, что из-за единого входа может случиться так, что пользователь будет аутентифицирован и другими клиентами.Но так как доступ предоставляется только определенным типам пользователей (как часть политик), вы можете запретить другим типам пользователей доступ к ресурсам, которые им не предназначены.Вы можете предотвратить это, отключив автоматический вход в систему.