Почему RBAC недостаточно: опыт построения тарифно-зависимой системы доступа в SaaS или о чём молчат в статьях компаний
Тема разграничения доступности действий в рамках конкретного тенанта выходит далеко за рамки ERP домена и требует особо пристальной реализации. Это особенно применимо для коммерческих систем (коей и является Kroncl - название системы), в которых классический RBAC требует определённых доработок, включающих адаптацию к упрощённой features-based access control (в народе - FBAC, является своего рода реализацией ABAC). Кроме того, технологические компании крайне редко (уникальные случаи всё же есть) посвящают публичные статьи внутреннему устройству своих систем тарификации, что крайне печально, ведь это буквально могли быть рассказы о том, как архитектурные решения напрямую влияют на маркетинг и как следствие доходность компании. Как же строить системы определения доступа не вокруг конкретных действий, а экономической модели платформы? Как легко переусложнить то, что переусложнять априори не стоит? Где заканчивается гибкость и начинается ад поддержки?
https://habr.com/ru/articles/1028298/
#go #архитектура #rbac #abac #тарификация #php #доступы #saas #erp #crm

Почему RBAC недостаточно: опыт построения тарифно-зависимой системы доступа в SaaS или о чём молчат в статьях компаний
Не так давно в отдельной статье я описывал опыт построения примитивной ERP-lite системы, ориентированной на малый бизнес РФ. В общем виде были проговорены основные архитектурные и доменные проблемы, с...




