Авторизация Ассистента Core/IdentityServer

Question

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

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

Я вижу два подхода, которые могли бы решить эту проблему;

1. Создание сложных претензий для каждой компании/проекта, который будет содержать CompanyID и роль пользователя в этой компании. Что может быть в форме JSON или пользовательской строке, например, companyGUID_roleClaim Однако, когда я сделал небольшое исследование об этом, я понял, что есть много людей, которые не считают, что это правильный подход, поскольку они считают, что претензии должны быть простыми ключевыми словами, пары значений.

2. Позволяет приложениям связывать/запрашивать базу данных Identity для извлечения компаний/проектов и ролей, связанных с активным пользователем, и защиты ресурсов с использованием политик на основе этих данных.

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

Answer 1

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

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

Вы можете написать службу авторизации, которая предоставит необходимые данные авторизации из базы данных. Затем вы можете авторизовать в двух приложениях, написав политику авторизации. Вы можете защитить свои ресурсы, отменив их с помощью [Authorize(Policy="MyPolicy"].

leastprivilege написал хороший блог о нем и почему вы не должны использовать требования разрешений: https://leastprivilege.com/2016/12/16/identity-vs-permissions/