К сожалению... Можно призвать @yurigeronimus , @romanvt , @GKruglov , @easlamov .

У них больше такого опыта.

Все равно большое спасибо за советы

Кстати а в чём тут конфликт? У вас получится, что есть транзакции на изменение схемы прав доступа от разных пользователей. Транзакция выполняются последовательно для одних и тех же данных.

Если вопрос в том как решать конфликты вносимых изменений (Вася сказал что можно, а Боря, что нельзя, и надо внести оба изменения одновременно) - только административно. На уровне программного обеспечения это не решается.

Ну в смысле на уровне софта возможно решение либо приоритетом пользователя, либо очередностью поступления/исполнения.

Тут конфликт скорее на уровне проектирования структуры хранения. Пока выделенные пользователю права рассчитываются как пересечения множества прав, выделенных админом субподрядчика пользователю и множества прав выделенных субподрядчику генадмином (чтобы не вмешиваться в выделенные субподрядчиком права и не стирать их, мы их фактически просто "отключаем" таким образом), и на полученное множество накладывается ограничение по доступу к системам, в результате от него остается только множество прав на действия в разрешенных системах.
Возник конфликт на тему "ой, это слишком сложно, почему нельзя решить все на уровне только прав пользователя, зачем еще дополнительные уровни выделять". Имхо решить на уровне прав пользователя тоже можно, но тогда просто надо делетить эти права, а если решение генадмина было ошибочным то обратно уже не особо откатишь.

Имхо тут надо пояснить, что если у каждого пользователя будет своя схема доступа - это приведет к росту сложности управления и внесения изменений. Причём нелинейно от количества пользователей.

Не погружаясь, первое что нашел для справки: https://dinolai.com/notes/others/authorization-models-acl-dac-mac-rbac-abac.html

Нужно сначала чётко выбрать модели авторизации

Для каждой модели есть подходы к реализации

Ну вот я как раз пытаюсь разработать решение на типовых схемах. Типовая схема прав на приложение и типовая схема ролей назначается субподрядчику. Он может оперировать ролями и назначать их на своих сотрудников. Если роли кажутся ему слишком большими, может назначить сочетание роль+право на отдельную функцию (тут усложнение да, и возможно мы эту ветку делать не будем если явной необходимости в ней не будет). В остальном если генадмину нужно отключить\подключить всех пользователей субподрядчика или нескольких субподрядчиков от какой-то\каких-то систем или сузить\расширить доступную им функциональность он меняет схему прав или схему ролей субподрялчика, а не лезет в каждого пользователя субподрядчика.
Но это первый опыт проектирования системы такой сложности и поэтому наверное делаю ее избыточно сложной и гибкой

Мне кажется, что вам проще взять готовую платформу или базовые принципы, нежели строить свой велосипед.

В смысле приложение разработать с применением какого-то шаблона. Например Геннадий выше показал ссылку на библиотеку таких шаблонов.

классно, спасибо! Проблема у меня и в том что не зная общепринятой терминологии сложно отыскать что-то валидное, в основном куча ссылок на AWS

Я так и понял

Надо понимать, что голый RBAC мало где прокатывает (счастье, если у вас прокатывает), а полный ABAC имеет кучу осложнений. Поэтому в большом % случаев делается промежуточная модель - "ограниченный ABAC" или "расширенный RBAC". Например, "RBAC + иерархия по оргструктуре" Естественно, от потребностей надо плясать.

Часто используют ACL + RBAC.

ACL нужен когда требуется определить права доступа к конкретным "объектам", например документам. А RBAC очень удобен для дефолтов.

Maintainability немного отличается от Modifiability. Len Bass связывает с mantainability следующий ASR:

"A maintainer encounters search- and response-time deficiencies, fixes the bug, and distributes the bug fix with no more than 3 person-days of effort. (H,M) A reporting requirement requires a change to the reportgenerating metadata. Change is made in 4 person-hours of effort. (M,L)"

Это требование хорошо ложится на экономический язык.

Modifiability связано с Flexibility, Maintainability не уверен

Сколько школ, столько и определений. CMU ориентируется на оборонку. Squale - на опен сорс и B2G.

Суть примерно одна.

Коллеги, добрый день.
Пытаюсь разобраться со сферами применения SOAP. Понимаю, что он отмирает, но насколько понимаю, имеется узкий набор задач, когда он может быть необходим. Среди которых системы с повышенными требованиями к безопасности (WS-Security) и возможность хранения состояния на сервере.
Вопросы:
1) Имеются сферы, где SOAP еще необходим - так ли это?
2) Если да, то ограничиваются ли эти сферы перечисленными мною двумя кейсами или есть еще какие-то?
3) Хотел бы попросить жизненных примеров, когда могут возникнуть упомянутые задачи (когда может потребоваться хранение состояния на сервере, что за сложная транзакция такая, когда для обеспечения безопасности HTTPS может не хватить)

@GKruglov, @IgorBespalchuk спасибо за ответы, буду разбираться подробнее в типовых шаблонах, но видится так что действительно чистый какой-то шаблон не подходит и надо комбинировать

На соап построено огромное количество интеграций, вы можете и не хотеть его применять, да придётся в некоторых системах.

Банки часто предоставляют свое апи для интеграции в виде соап, клиент может передавать сотни платежных документов за раз, подписанных клиентом.