Реализация авторизационного механизма корпоративной системы с помощью иерархической модели сущностей
В последнее время наблюдается тенденция к интеграции различных независимых информационных систем автоматизации деятельности предприятия в единые информационные системы. Интегрированные системы управления предприятием (ИСУП) могут охватывать как несколько отделов внутри одного предприятия, так и несколько предприятий. Количество пользователей такой интегрированной системы может достигать нескольких сотен. При этом система должна иметь возможности для решения проблемы делегирования полномочий между участниками системы. В данной статье предложен принципиально новый подход к организации авторизационного механизма корпоративной системы.
Каждая ИСУП представлена широким рядом различных сущностей. Сущность - это класс однотипных объектов. С увеличением количества как самих сущностей, так и объектов этих сущностей, неизбежно возникает вопрос об организации эффективного управления этими объектами. Самое основное, что необходимо для эффективного управления - распределение ответственности и обязанностей между участниками системы. Распределение ответственности не только на уровне сущностей, но и на уровне объектов. Такое распределение позволяет эффективно использовать систему с учетом возможности неограниченного расширения. При этом осуществляется строгий иерархический контроль, в том числе, что самое главное - контроль над контролем. Количество уровней иерархии ничем не ограниченно, и определяется текущими требованиями и спецификой деятельности в рамках отдела, или даже в рамках каждого отдельно взятого объекта сущности, который может рассматриваться в данном контексте как субъект бизнес-процессов предприятия или отдельно взятый функциональный блок. Следует заметить, что именно такой подход к распределению полномочий используется в управляющих системах, построенных по принципу иерархии (например, в вооруженных силах, государственных структурах).
Для построения авторизационной подсистемы по предложенному механизму потребуется произвести ряд действий:
- Определить набор сущностей системы, действия над объектами которых предполагается делегировать.
- Построить дерево связей между сущностями, определенными на шаге 1.
При этом корневым элементом будет являться виртуальная сущность Root, соответствующая единственному объекту Root. Эту схему будем условно называть "дерево связей". Сущность Root определяет систему как единое целое, поэтому она содержит единственный объект. - Привести модель "Сущность-Связь" к такому виду, чтобы сущность являющаяся родительской в "дереве связей" была связана с дочерней отношением "один-ко-многим".
- Определить множество делегируемых действий над каждой сущностью.
Одним из ключевых понятий в предложенном механизме является авторизационная роль, или просто роль.
Роль - это настраиваемая совокупность доступных действий. Роли создаются и настраиваются в процессе эксплуатации системы. Если нет необходимости в настраиваемых ролях, тогда они могут быть жестко определены на стадии разработки системы.
Доступ - это назначение определенной роли участнику системы для взаимодействия с объектом, или с его дочерними объектами.
Таким образом, чтобы определить доступ, необходимо определить три вещи:
- роль;
- пользователь;
- объект, на который распространяется эта роль.
Доступ, определенный на объект родительской сущности распространяется на все присоединенные объекты дочерних сущностей.
Программный код системы, при попытке пользователя совершить то или иное действие над заданным объектом системы, должен предусматривать проверку возможности совершения этого действия. Фрагмент алгоритма кода системы:
...
Если Разрешено_Действие(номер_пользователя, номер_сущности, номер_объекта, номер_действия)
То Произвести_Действие(объект, номер_действия);
...
Функция проверки доступности действия имеет вид:
Функция Разрешено_Действие(номер_пользователя, номер_сущности, номер_объекта, номер_действия)
Если Cуществует_Доступ(номер_пользователя, номер_сущности, номер_объекта,номер_действия)
То вернуть "Истина"
Иначе
Если номер_сущности не равен Root
То
Получить_Родительский_Объект(номер_сущности, номер_объекта, номер_родительской_сущности, номер_родительского_объекта);
вернуть Разрешено_Действие(номер_пользователя, номер_родительской_сущности, номер_родительского_объекта, номер_действия);
Иначе
вернуть "Ложь"
Функция "Существует_Доступ" проверяет наличие доступа пользователя к данному объекту путем проверки всех назначенных ролей, в список доступных действий которых входит заданное действие. Функция "Получить_Родительский_Объект" использует информацию о виде "дерева связей", поэтому авторизационная подсистема должна предусмотреть хранение этой информации.
Рассмотрим небольшой пример. Существует дерево связей (рисунок).
Допустим, существует роль "Полный доступ", в список доступных действий которой входят все возможные действия над всеми сущностями системы. Если назначить эту роль пользователю Петрову на объект Root, то он получит полный доступ над всеми объектами всех сущностей. Если эту роль назначить пользователю Иванову на объект "Филиал № 5" сущности "Филиал", то Иванов обретет полный доступ над филиалом № 5, всеми отделами и складами этого филиала.
Допустим, существует роль "Управление складом", в список доступных действий которой входят действия по манипулированию приходом и расходом товаров на склад. Если назначить эту роль пользователю Петрову на объект Root, то он сможет управлять всеми складами системы. Если назначить эту роль пользователю Петрову на объект "Филиал № 5", то Петров сможет управлять всеми складами филиала № 5. Если назначить эту роль пользователю Сидорову на объект "Склад № 1" филиала № 5, то Сидоров сможет управлять только одним этим складом.
Предложенный механизм авторизации используется в корпоративной системе, функционирующей в НПП "СпецТек" (Санкт-Петербург). Эта корпоративная система предназначена для автоматизации деятельности софтверных и консалтинговых предприятий. Возможность делегирования полномочий позволила использовать систему для одновременного ведения нескольких проектов ПО, на каждый из которых назначается руководитель, разработчики, тестировщики.В отделе консалтинга осуществляется разделение ответственности по договорам с назначением руководителя, технической поддержки. Настраиваемые роли позволяют гибко регулировать полномочия сотрудников в соответствии с организационной структурой предприятия.
