Для написания сервиса с пользователями у которых разные позиции и соответственно роли, понадобилось изучить систему распределения ролей по Casbin. В рамках изученной документации был выбран методика RBAC (более подробно можете читать в документации Casbin). Для этого в гитхабе есть пакет от Касбина, но он мне не понравился и сейчас я всё объясню. Пакет от касбина для языка Go использует мепки для временного харнения доступов, что дублирует код. Помимо этого реализация самого пакета немного делает систему статичной, что не очень хорошо в условиях сервисной архитектуры. По этим причинам мне пришлось отказаться от пакета. Возможно вам, читатель, понравится пакет, обязательно ознакомьтесь для полноты картины.
Вернёмся к нашему сервису. При регистрации пользователей, нужно присвоить им какую-нибудь роль, для разграничения доступа к сервису. В моём случае наилучшим вариантом стал метод RBAC - где доступ к системе ограничен на уровне роли, а не должности. Метод распределяет доступ к системе в рамках ролей. А роли в свою очередь состоять из сущностей. У нас есть три сущности:
Субъект (пользователь)
Объект (роут)
Действие
Для нас все эти сущности объединены одним понятием - "Роль". Субъект у нас есть - это наши конечные пользователи. Объекты у нас наши роуты, которых может быть очень много, но для того, чтобы удобно распределять доступ, их нужно сгруппировать, например:
Роуты для работы с платежами - "/payments"
и создал таблицу где фиксирую все группы роутов:
/payments Операции с плаетжами
/users
/operations
Теперь для каждой группы роутов соответствуют следующие действия:
Создать, добавить (POST)
Изменить, редактировать(PUT, PATCH)
Просмотр, читать (GET)
Удалить (DELETE)
Эти название действия у нас составляют третью сущность - Действие.
Теперь объединим всё и посмотрим как создаётся роль. Прежде чем регистрировать пользователя, мы должны создать роль для него. Создаем две таблицы:
1. Roles
2. Permissions
Каждая роль связана с доступом. Каждый доступ состоит из наборов «роут (объект) ‑ метод (действие)».
Например: Я создам роль пользователя, у которого есть доступ к платежам и только.
Теперь, когда регистрируем пользователя, ему сразу же присваиваем созданную роль - user. Каждый раз, когда он будет дергать какой-то роут, мы по его роли смотрим, есть ли у него данный роут с этим методом. Допустим пользователь хочет создать платёж, для этого он дергает роут - POST "/payments". Мы в свою очередь в рамках его роли проверяем, есть ли у него данный роут с данным методом. Если есть, то пропускаем и даём возможность создать платёж, если нет, то возвращаем ошибку. Всё это происходит на middleware. Таким образом, можно сколько угодно расширять диапазон, как действий, так и объектов и создать сколько угодно ролей с доступами. Очень простой но гибкий и надежный метод.