Как быть с разделением обязанностей пользователей?

Рейтинг: 0Ответов: 1Опубликовано: 21.02.2025

Используем C# Net Core 8, Web API. Пока думаем что брать: Keycloak или свое решение.
Сейчас встал вопрос о том, как быть с разделением пользователей. В наших бизнес правилах такой момент, что есть 2 отдела, пусть будут №1 и №2. И в каждом отделе есть, например, 1 человек, который отвечает только за свой район в городе, путь будут северный и южный (то есть в отделе №1 есть такой человек, который отвечает за северный и в отделе №2 есть человек, который отвечает за район северный, точно так же с южным).

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

Какие еще могут быть варианты построения такой системы? Еще стоит учесть, что администраторы будут иметь доступ сразу во все районы.

rest проектирование
Источник: Stack Overflow на русском

Ответы

▲ 1

Я это вижу так:

Есть Роль юзера, а есть ресурсы, которые доступны юзеру с этой ролью.

Например, у вас есть вебсайт, где юзерам - доступны только юзерские странички, модераторам - юзерские+часть админки, администраторам - доступно всё. При этом в системе только 3 роли, а каждый модуль/страничка уже решают своей логикой какой роли они доступны.

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

Отсюда напрашивается M-M связь между районами и юзерами. В JWT каждый район складывать не надо, только роли, а ваша система уже на основе ролей и доступа к районам может определить, что показывать и что не показывать. По мне так делать запрос в М-М связь чтобы проверять доступные районы - это нормально. Если у вас БД по какой то причине не будет справляться (что маловероятно), то подобные данные можно кешировать в памяти сервера ненадолго, не дольше чем время жизни JWT.

Другими словами, метод аутентификации и авторизации здесь не важен, хоть JWT, хоть LDAP, главное иметь список ролей юзера ("смотритель района", "админ").

Подход выше опирается на БД и будет работать как с одним app сервером, так и с кластером.