Здравствуй, Хабр!

В прошлой статье мы рассматривали «лоскутный» подход к внедрению low-code платформы. Напомню, одна из проблем, которые мы собирались решать, звучит следующим образом: «Информационные системы зачастую… имеют изолированные друг от друга системы доступа и авторизации - вследствие чего сотрудникам приходится помнить и пользоваться несколько учетными записями».

При поиске решения этой проблемы, мы отталкивались от выбранного подхода к внедрению, согласно которому каждый лоскуток является не только покрытием участков рабочих процессов, но и агентом в смежных информационных системах. Это позволит получить в едином окне доступ не только к тем процессам, которые покрыты лоскутками платформы, но и к смежным с ними, реализованным в других системах. Доступ может быть реализован следующими способами:

1.    Вызов методов апи смежных систем;

2.    Прямое чтение/запись из/в БД смежных систем;

3.    Доступ к функциональности смежных систем путем вынесения ссылок на их пользовательские интерфейсы на единый рабочий стол с сохранением внешних пользовательских сессий.

Также как вариант доступа возможна замена устаревающих участков процессов смежных систем лоскутками.

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

Мы посмотрели несколько достаточно разных реализаций (варианты ACL, доступ на основе шэринга), и в итоге пришли к следующей, достаточно абстрактной структуре:

1.    Иерархический справочник субъектов. Субъект может быть группой, либо отдельным пользователем.

2.    Иерархический справочник объектов. Объект может быть разделом, формой, компонентом формы, методом апи, записью, полем.

3.    Справочник возможных действий над объектами. Определяется для каждого типа объектов.

4.    Таблица правил доступа субъектов к действиям над объектами. Содержит также приоритет правила.

Изначально вся система закрыта, есть только разрешающие правила.

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

Также мы предусмотрели возможность разрыва наследования прав для объектов путем указания соответствующего признака - для изоляции правила от его родителей в рамках приоритета.

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

При попытке актора выполнить действие, производится поиск и вычисление прав на разных уровнях приоритета. На каждом приоритете находятся все правила по иерархии, от рассматриваемого объекта, вверх, до разрыва наследования. Из собранных по иерархии объектов правил выбираются подходящие по субъектности и типу действия. Далее происходит суммирование всех разрешений, которые актор может получить для рассматриваемого типа действия.

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

Для упрощения процесса внедрения этой системы в работу, необходимо разработать:

1.    механизм импорта данных о субъектах из ActiveDirectory и подобных ей систем аутентификации.

2.    интерфейс для быстрого наполнения справочника объектов как из самой платформы, так и из доступных смежных систем.

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

О способах обеспечения информационной безопасности этой структуры мы расскажем в одной из следующих статей.