- ВКонтакте
- РћРТвЂВВВВВВВВнокласснРСвЂВВВВВВВВРєРСвЂВВВВВВВВ
- РњРѕР№ Р В Р’В Р РЋРЎв„ўР В Р’В Р РЋРІР‚ВВВВВВВВРЎР‚
- Viber
- Skype
- Telegram
Как быть с разделением обязанностей пользователей?
Используем C# Net Core 8, Web API. Пока думаем что брать: Keycloak или свое решение.
Сейчас встал вопрос о том, как быть с разделением пользователей. В наших бизнес правилах такой момент, что есть 2 отдела, пусть будут №1 и №2. И в каждом отделе есть, например, 1 человек, который отвечает только за свой район в городе, путь будут северный и южный (то есть в отделе №1 есть такой человек, который отвечает за северный и в отделе №2 есть человек, который отвечает за район северный, точно так же с южным).
При авторизации пользователю должны показываться только данные, которые относятся к его районам, за которые он отвечает, например только за северный.
Как это лучше сделать? Какие практики используются для такого? Использовать claim'ы в JWT и туда писать список всех разрешенных районов и, исходя из этих данных, делать селекты? Но, имхо, это немного не удобно будет везде в коде подвязываться на это.
Какие еще могут быть варианты построения такой системы? Еще стоит учесть, что администраторы будут иметь доступ сразу во все районы.
Ответы (1 шт):
Я это вижу так:
Есть Роль юзера, а есть ресурсы, которые доступны юзеру с этой ролью.
Например, у вас есть вебсайт, где юзерам - доступны только юзерские странички, модераторам - юзерские+часть админки, администраторам - доступно всё. При этом в системе только 3 роли, а каждый модуль/страничка уже решают своей логикой какой роли они доступны.
Также и в вашем случае. У вас есть, условно, роль "отвественный за район", но при этом каждый район у себя должен иметь конкретных отвественных, то есть юзер, который хочеть просмотреть данные района, должен иметь нужную роль + быть в списке ответвенных за район.
Отсюда напрашивается M-M связь между районами и юзерами. В JWT каждый район складывать не надо, только роли, а ваша система уже на основе ролей и доступа к районам может определить, что показывать и что не показывать. По мне так делать запрос в М-М связь чтобы проверять доступные районы - это нормально. Если у вас БД по какой то причине не будет справляться (что маловероятно), то подобные данные можно кешировать в памяти сервера ненадолго, не дольше чем время жизни JWT.
Другими словами, метод аутентификации и авторизации здесь не важен, хоть JWT, хоть LDAP, главное иметь список ролей юзера ("смотритель района", "админ").
Подход выше опирается на БД и будет работать как с одним app сервером, так и с кластером.