Как спроектировать отношения между сущностями в многопользовательской системе?

Question

[Aleksey]

Привет, тостер!
1. В системе есть администраторы, которые имеют доступ к админ.панели через браузер. Возможно, в будущем будет и мобильное приложение. Имеют несколько уровней доступа (роли, права).
2. Есть пользователи-клиенты. Могут заказывать услуги и следить за выполнением.
3. Есть пользователи-исполнители. Могут брать оставленные пользователем-клиентом заказы и выполнять.
4. Сейчас каждый из этих трех пользователь лежит в отдельной таблице. Это прям ужасно.
5. Администраторы авторизуются с помощью пары логин-пароль, остальные - номер телефона + смс-код.

Как правильно спроектировать такую систему? Есть идея с вынесением общих полей в UserInfo, а дополнительной информации о клиенте или исполнителе - в CustomerInfo и EmployeeInfo. При этом, UserInfo имеет внутри себя ссылку на и на CustomerInfo, и на EmployeeInfo. Это связано с тем, что Customer может быть и Employee тоже.
Как авторизовывать таких пользователей? По одной ссылке или по разным?

Answer 1

[index0h]

RBAC

Comments

[Aleksey]

www.baeldung.com/role-and-privilege-for-spring-sec...

То есть, я правильно понял, что это то, что подразумевает под собой Role Based Access?

Если да, то вопрос: как определять при авторизации, откуда этот запрос и, соответственно, есть ли доступ у пользователя? API key с такими же ролями?

Тогда получается, что есть одна таблица User в которой смешаны поля всех ролей?

[index0h]

Как вариант для авторизации предлагаю несколько таблиц:
account_credenital_login(id, accountId, login, pass)
account_credenital_phone(id, accountId, phone, code)
account(id, role)

[Aleksey]

index0h, а дальше появляется куча других осложнений:
1. У Employee и Customer есть история заказов. И у каждого она своя.
2. Вход админа происходит через веб, Employee через одно приложение, Customer - через другое.

[index0h]

Aleksey
Собсно и в чем сложности? Не путайте вместе аутинтефикацию и контроль доступа.

[Aleksey]

index0h, сложность в том, как это все вместе соединить. Возможно, надуманная. Не могу в голове уложить, как соединить все это.
Admin - авторизация через username + password
Employee, Customer - авторизация через phone + sms-code
Как определить, когда логиниться Employee, а когда Customer, если они имеют общую модель User(id, phone. name)?
Если все три авторизации происходят через один метод, то админа можно определить по параметрам username + password, а вот с Employee и Customer - хз, как быть. На ум приходят варианты:
1. Разные методы
2. Прикладывать API key с определенными правами - один для Employee, другой для Customer, третий для Admin.

[index0h]

account

| id | role     |
|  1 | admin    |
|  2 | employee |
|  3 | customer |

account_credenital_login

| id | accountId | login  | pass  |
|  1 |         1 | admin1 | pass1 |

account_credenital_phone

| id | accountId | phone  | code      |
|  1 |         2 | +12345 | employee1 |
|  2 |         3 | +23456 | customer1 |

[index0h]

Допустим к вам по телефону ломится кто-то с телефоном +12345 и вводит правильный смс код. Вы лезете в таблицу account_credenital_phone и там узнаете, что это за аккаунт и какая у него роль

[Aleksey]

index0h, итак. ко мне ломится Customer через приложение для Employee. Да, я знаю, его номер, но не знаю откуда он и думаю, что он ломится через приложение для Customer. Тут как поступить?

[index0h]

Aleksey
А) Средиректить на кабинет customer, как только вы узнали, что роль у него customer
Б) Запрещать аутинтефикацию, если роль не соответствует кабинету

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

[Aleksey]

index0h, больше вопросов, чем ответов.
В какую тему углубиться, чтобы узнать способы решения каких-то сложных проблем?

[index0h]

OAuth2, LDAP, HashiCorp Vault

[Aleksey]

index0h, спасибо)
Пока пришел к использованию STI AbstractUser <= {Admin, Customer, Employee}. Правда, уникальность, скажем, username'ов и email'ов у Admin приходится обрабатывать на уровне кода, а не БД.
Авторизация через разные endpoint'ы, Уровни доступа через роли + привилегии.