Сервис авторизации

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

OpenBPM Engine позволяет пользователям авторизовать доступ к данным, которыми она управляет. Это дает возможность конфигурировать, какие пользователи могут получать доступ к каким процессам, задачам и т.д.

Авторизация отражается на производительности, а также вносит дополнительную сложность. Она должна использоваться только тогда, когда это абсолютно необходимо.

Когда необходима авторизация?

Не каждая коняигурация OpenBPM Engine требует подключения авторизации. Существует множество сценариев, когда OpenBPM Engine встраивается в приложение, и само приложение следит за тем, чтобы пользователи имели доступ только к тем данным, к которым они должны иметь доступ. Говоря обобщенно, авторизация требуется только тогда, когда не наделенные доверием третьи стороны напрямую взаимодействуют с API движка управления процессами. Если вы встраиваете движок управления процессами в Java приложение, вам обычно не требуется включать авторизацию. Приложение в состоянии проследить за тем, как осуществляется доступ к API.

Ситуации, в которых требуется авторизация:

  • OpenBPM Engine Rest API доступна для пользователей, которые не должны иметь полный доступ, даже после аутентификации.

  • OpenBPM Engine веб приложение является доступным для пользователей, которые не должны иметь полный доступ, даже поуле аутентификации.

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

Ситуации, в которых авторизация не требуется

  • Приложение полностью контролирует методы API, вызываемые на движке управления процессами.

  • OpenBPM Engine веб приложение является доступным для пользователей, которые имеют полный доступ после аутентификации.

Пример

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

Если движок встроен в Java приложение, это приложение может легко выполнить это требование, ограничив зарпос на задачи свойством assignee. Приложение может это гарантировать, поскольку OpenBPM Engine API недоступен пользователю напрямую.

По контрасту, когда OpenBPM Engine Rest API напрямую доступна по сети для Javascript приложения, злонамеренный пользхователь после аутентификации может послать запрос на сервер, опрашивая все задачи, включая те, которые не назначены на этого пользователя. В этом случае авторизацию необходимо включить, чтобы гарантировать, что пользователь увидит только те задачи, которые он имеет право видеть, независимо от параметров запроса.

Базовые принципы

Авторизации

Авторизация назначает набор разрешений на некую идентичность для взаимодействия с заданным ресурсом.

Примеры

  • Пользователь 'jonny' имеет авторизацию на создание новых пользователей

  • Группа 'marketing' не имеет авторизации на удаление группы 'sales'

  • Группа 'marketing' не имеет авторизации на использование приложения tasklist.

Идентичности

OpenBPM Engine проводит различие между двумя типами идентичностей: пользователями и группами. Авторизации могут либо покрывать весь диапазон пользователей (userId = ANY), либо относиться к индивидуальному пользователю или группе.

Разрешения

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

Базовые разрешения, доступные в движке, следующие:

  • None (ничего)

  • All (все)

  • Read (чтение)

  • Update (обновление)

  • Create (создание)

  • Delete (удаление)

  • Access (доступ)

Обраттите внимание, что разрешение None не означает, что не предоставлено никаких разрешений. Вместо этого, оно представляет собой "отсутствие действия". Более того, разрешение All у пользователя исчезнет, как только какое-либо одно единственное разрешение будет отобрано.

Чтобы получить детальный список всех доступных разрешений, см. раздел "Разрешения по ресурсам" link:{{< relref "#permissions-by-resource" >}}[].

Объект одной авторизации может назначать многочисленные разрешения одному пользователю или ресурсу:

authorization.addPermission(Permissions.READ);
authorization.addPermission(Permissions.UPDATE);
authorization.addPermission(Permissions.DELETE);

Ресурсы

Ресурсы являются сущностями, с которыми взаимодействует пользователь.

Доступны следующие ресурсы:

Имя ресурса Представление целым числом Id ресурса

Application (Cockpit, Tasklist, …​)

0

admin/cockpit/tasklist/*

Authorization

4

Authorization Id

Batch

13

Batch Id

Decision Definition

10

Decision Definition Key

Decision Requirements Definition

14

Decision Requirements Definition Key

Deployment

9

Deployment Id

Filter

5

Filter Id

Group

2

Group Id

Group Membership

3

Group Id

Process Definition

6

Process Definition Key

Process Instance

8

Process Instance Id

Task

7

Task Id

Historic Task

19

Historic Task Id

Historic Process Instance

20

Historic Process Instance Id

Tenant

11

Tenant Id

Tenant Membership

12

Tenant Id

User

1

User Id

Report

15

Report Id

Dashboard

16

Dashboard Id

User Operation Log Category

17

User Operation Log Entry Category

System

21

+ Системные ресурсы не поддерживают id индивидуальных ресурсов. Вам придется использовать wildcard id (*).

Примечание: Id ресурса должен быть '*', когда вы создаете новую авторизацию только с разрешениями вида CREATE.

Типы авторизации

Существуют три типа авторизации:

Тип авторизации Описание Представление целым числом

Global Authorization, глобальная авторизация (AUTH_TYPE_GLOBAL)

Распространяется на всех пользователей и на все группы (userId = ANY) и обычно используется для назначения "базовых" aразрешений для ресурса.

0

Grant Authorization, авторизация для выдачи прав (AUTH_TYPE_GRANT)

Распространяется на пользователей и группы и выдает набор разрешений. Такие авторизации обычно используются для добавления разрешений пользователю или группе, которые были отняты глобальной авторизацией.

1

Revoke Authorization, авторизация для отъема прав (AUTH_TYPE_REVOKE)

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

2

{{< note class="warning" title="Performance of REVOKE Authorizations" >}} См. раздел "Вопросы производительности" link:{{< relref "#performance-considerations" >}}[] на этой странице.

Приоритеты авторизаций

Авторизации могут распространяться на всех пользователей, на индивидуального пользователя или группу пользователей либо они могут применяться к индивидуальному экземпляру ресурса или ко всем экземплярам одного и того же типа (resourceId = ANY). Приоритетность определяется следующим образом:

  • Авторизация, применяемая к индивидуальному ресурсу, имеет более высокий приоритет, чем авторизации, применяемые ко всем экземплярам одного и того же типа ресурса.

  • Авторизация для индивидуального пользователя имеет более высокий приоритет, чем авторизация для группы.

  • Авторизация для группы имеет более высокий приоритет, чем авторизация типа GLOBAL.

  • Авторизация для группы типа GRANT имеет более высокий приоритет, чем авторизация для группы типа REVOKE.

  • Авторизация для пользователя типа GRANT имеет более высокий приоритет, чем авторизация для пользователя типа REVOKE.

Когда проверяются авторизации?

Авторизации проверяются, если

  • Конфигурационная опция authorizationEnabled установлена в true (значение по умолчанию равно false)

  • Присутствует пользователь, аутентифицированный в настоящий момент

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

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

{{< note class="info" title="Authentication vs. Authorization" >}} Аутентификация и авторизация — это два разных понятия, что объясняется здесь.

Разрешения по ресурсам

В этом разделе объясняется, какие разрешения доступны для каких ресурсов.

Read, Update, Create, Delete

Разрешения вида Read, Update, Create и Delete доступны для большинства ресурсов. Следующая таблица дает обзорную информацию относительно того, для каких ресурсов они доступны:

Read Update Create Delete

Авторизация

X

X

X

X

Batch

X

X

X

X

Определение решения

X

X

Определение требований к решению

X

Деплоймент

X

X

X

Фильтр

X

X

X

X

Группа

X

X

X

X

Членство в группе

X

X

Определение процесса

X

X

X

Экземпляр процесса

X

X

X

X

Задача

X

X

X

X

Историческая задача

X

Исторически экземпляр процесса

X

Арендатор

X

X

X

X

Членство в арендаторе

X

X

Пользователь

X

X

X

X

Категория лога для пользовательских операций

X

X

X

Чтобы выполнить операцию асинхронно, требуется только разрешение Create на batch-ресурсе. Однако, при выполнении той же операции синхронно специфические разрешения (например, Delete на ресурсе экземпляра процесса) проверяются.

Например, пользователь без разрешения Update на ресурсе экземпляра процесса, но получивший разрешение Create на ресурсе batch, может модифицировать многочисленные экземпляры процессов асинхронно через создание batch. Однако, пользователь не может выполнять такую операцию синхронно.

Дополнительные разрешения для задач

В дополнение к Update, Read и Delete, для ресурса задачи доступны следующие разрешения:

  • Task Assign (назначить задачу)

  • Task Work (работа по задаче)

  • Update Variable (обновить переменную)

Пользователь может выполнять различные действия над задачей, такие как назначение задачи, затребование задачи или выполнение задачи. Если у пользователя есть разрешение Update на задачу (или разрешение Update Task на соответствующее определение процесса), такой пользователь авторизован выполнять все эти действия над задачами. Если требуются более точно определяемые авторизации, можно использовать разрешения вида Task Work и Task Assign. Интуитивное понимание Task Work подсказывает нам, что оно позволяет пользователю только работать над задачей (то есть, затребовать ее себе и выполнить ее), но не назначать ее на другого пользователя или "распределять работу" между коллегами каким-либо иным способом.

Если у пользователя есть разрешение Update Variable на задаче (или разрешение Update Task Variable на соответствующем определении процесса), пользователь авторизован выполнять действия установить/удалить переменную задачи.

Приведенная ниже таблица дает подробный обзор того, какие разрешения позволяют пользователю выполнять какие действия:

Task Work Task Assign Update Variable Update

Затребовать

X

X

Выполнить

X

X

Добавить пользователя-кандидата

X

X

Удалить пользователя-кандидата

X

X

Установить назначенного сотрудника

X

X

Установить владельца

X

X

Добавить группу-кандидата

X

X

Удалить группу-кандидата

X

X

Сохранить

X

X

Установить приоритет

X

X

Установить название

X

X

Установить описание

X

X

Установить дату выполнения

X

X

Установить дату проверки (Follow Up Date)

X

X

Установить локальную переменную

X

X

Удалить локальную переменную

X

X

Операции GRANT (выдать) и REVOKE (отозвать) на авторизациях с разрешениями Task Work, Task Assign и Update Variable имеют более высокий приоритет, чем Update и Update Task.

Разрешения для задач по умолчанию

Когда пользователь имеет отношение к задаче как исполнитель, пользователь-кандидат, чатсь группы-кандидата или владелец, такие пользователи получают разрешение по умолчанию, которое равно либо Task Work, либо Update, в зависимости от конфигурационного свойства defaultUserPermissionNameForTask движка управления процессами.

Если конфигурационная опция defaultUserPermissionNameForTask не установлена, то по умолчанию выдается разрешение Update.

Дополнительные разрешения определения процесса

В дополнение к Update, Read и Delete для ресурса определения процесса доступны следующие разрешения:

  • Read Task (считать задачу)

  • Update Task (обновить задачу)

  • Task Work (работать над задачей)

  • Task Assign (назначить задачу)

  • Create Instance (создать экземпляр)

  • Read Instance (считать экземпляр)

  • Update Instance (обновить экземпляр)

  • Retry Job (повторно попытаться запустить джобу)

  • Suspend (приостановить)

  • Suspend Instance (приостановить экземпляр)

  • Update Instance Variable (обновить переменную экземпляра)

  • Update Task Variable (обновить переменную задачи)

  • Migrate Instance (мигрировать экземпляр)

  • Delete Instance (удалить экземпляр)

  • Read History (прочитать историю)

  • Delete History (удалить историю)

  • Update History (обновить историю)

Разрешение Create Instance требуется для запуска новых экземпляров процесса.

ЗАПУСК НОВОГО ЭКЗЕМПЛЯРА ПРОЦЕССА: Чтобы выполнить это действие, пользователю также необходимо иметь разрешение Create на ресурсе экземпляра процесса.

Операции GRANT (выдать) и REVOKE (отозвать) на авторизациях с разрешениями Retry Job, Suspend, Suspend Instance, Update Instance Variable и Update Task Variable имеею более высокий приоритет, чем Update. Помните, что пользователь, которому разрешено выполнять обновления переменных, может вызвать другие изменения в процессе через обновление переменной. Например, успешное вычисление условного события, относящегося к этой переменной.

Дополнительные разрешения экземпляра процесса

В добавление к Create, Read, Update и Delete следующие разрешения доступны для ресурса экземпляра процесса:

  • Retry Job (повторный запуск джобы)

  • Suspend (приостановить)

  • Update Variable (обновить переменную)

Операции GRANT (выдать) и REVOKE (отозвать) на авторизациях с разрешениями Retry Job, Suspend и Update Variable имеют более высокий приоритет, чем Update. Помните, что пользователь, которому разрешено производить обновление переменных, может вызвать другие изменения через обновление переменной. Например, успешное вычисление условного события, относящегося к этой переменной.

Additional Decision Definition Permissions

В дополнение к Update, Read и Delete следующие разрешения доступны для ресурса определения решения:

  • Create Instance (создать экземпляр)

  • Read History (считать историю)

  • Delete History (удалить историю)

Разрешение Create Instance требуется для оценки решений с помощью сервиса решений.

Дополнительные разрешения для batch

В дополнение к Create, Update, Read и Delete следующие разрешения доступны для ресурса batch:

  • Read History (считать историю)

  • Delete History (удалить историю)

  • Create Batch Migrate Process Instances (создать экземпляры процесса миграции в режиме batch)

  • Create Batch Modify Process Instances (создать экземпляры процесса модификации в режиме batch)

  • Create Batch Restart Process Instances (создать экземпляры процесса перезапуска в режиме batch)

  • Create Batch Delete Running Process Instances (создать экземпляры процесса прогона в режиме batch)

  • Create Batch Delete Finished Process Instances (создать экземпляры процесса удаления завершенных в режиме batch)

  • Create Batch Delete Decision Instances (создать экземпляры удаления решений в режиме batch)

  • Create Batch Set Job Retries (создание установленных повторных попыток запуска джоб в режиме batch)

  • Create Batch Set External Task Retries (создание установленных повторных попыток запуска задач в режиме batch)

  • Create Batch Update Process Instances Suspend (создание приостановки обновлений экземпляров процесса в режиме batch)

  • Create Batch Set Removal Time (создание установок времений удаления в режиме batch)

  • Create Batch Set Variables (создание установленных переменных в режиме batch)

  • Create Batch Correlate Messages (создание коррелирующихся сообщений в режиме batch)

Операции GRANT (выдать) и REVOKE (отозвать) на авторизациях с разрешениями Create Batch … имеют более высокий авторитет, чем Create.

Разрешения по умолчанию на чтение переенных

Когда конфигурационная опция enforceSpecificVariablePermission в движке управления процессами включена, тогда для чтения переменных пользователью необходимо иметь следующие разрешения:

Для задач

  • Read Variable (для процессов и отдельно стоящих задач)

Для исторических задач

Для определений процессов

  • Read Instance Variable (для переменных экземпляров рантайм-процессов)

  • Read History Variable (для исторических переменных)

  • Read Task Variable (для переменных рантайм-задач)

Разрешения для приложений

Ресурс "Application" (приложение) является единственным, поддерживающим разрешение Access (доступ). Разрешение Access управляет тем, имеет ли пользователь доступ к веб-приложениям OpenBPM Engine или нет. Из коробки оно может быть выдано следующим приложениям (id ресурсов):

  • admin

  • cockpit

  • tasklist

  • optimize

  • * (Any / All)

Разрешения для лога пользовательских операций

Ресурс "User Operation Log Category" (Категория лога пользовательских операций) контролирует, может ли пользователь получать доступ к вхождениям в лог пользовательских операций из заданной категории. Из коробки такое разрешение может быть выдано для следующих категорий (id ресурсов):

  • TaskWorker

  • Admin

  • Operator

  • * (Any / All)

Разрешения для исторических экземпляров

Эти ресурсы контролируют, может ли пользователь считывать историю, относящуюся к заданному экземпляру.

В отличие от рантайм-разрешений, исторические разрешения не удаляются немедленно, как только соответствующий экземпляр завершает работу. Стратегия [Removal-Time-based History Cleanup Strategy] (стратегия очистки, базирующаяся на времени удаления) удаляет исторические разрешения позже.

Вы можете включить разрешения с помощью [конфигурационного флага движка управления процессами] [hist-inst-perm-config-flag]:

<property name="enableHistoricInstancePermissions">true</property>

Эта функция отключена по умолчанию по двум причинам:

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

  2. Когда она включена и Identity Link (связь идентичностей) добавляется к задаче, соответствующий пользователь или группа получают авторизацию на чтение ассоциированной истории (например, на историю задачи, переменной или Identity Link ).

Разрешения для исторических задач

Когда разрешения выдаются на историческую задачу, вы можете использовать следующие запросы, чтобы извлекать сущности, относящиеся к исторической задаче:

  • Historic Task Instance Query

  • Historic Variable Instance Query

  • Historic Detail Query

  • Identity Link Log Query

  • User Operation Log Query

Разрешения для исторических экземпляров процессов

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

  • Historic Process Instance Query

  • Historic Activity Instance Query

  • Historic Task Instance Query

  • Historic Variable Instance Query

  • Historic Detail Query

  • Identity Link Log Query

  • Historic Incident Query

  • Job Log Query

  • External Task Log Query

  • User Operation Log Query

Системные разрешения

Разрешения на системные ресурсы обычно выдаются операционным инженерам, которые следят за процессами и приложениями и обеспечивают их бесперебойную работу с технической точки зрения. Как правило, этим людям не нужен полный доступ к системе, который есть у администратора. У них должна быть возможность получать доступ и менять системную информацию, включая системные свойства, метрики, информацию о базе данных, телеметрию и данные о лицензионных ключах. Администраторам не нужны системные разрешения, поскольку их роль уже дает им доступ ко всем функциям. См. также раздел <a href="#Administrators">Администраторы</a>.

Следующая таблица предоставляет обзор функций, к которым дают доступ системные разрешения.

Чтение Установка Удаление

Configure Telemetry (Deprecated) — конфигурирование телеметрии

X

Get Telemetry Data — установка данных телеметрии

X

Get Telemetry Status (Deprecated) — получение статуса телеметрии

X

Get Database Table Count — получить количество записей в таблице в базе данных

X

Get Database Table Name — получить имя аблицы в базе данных

X

Get Database Table Meta Data — получить метаданные из таблицы базы данных

X

Get History Level — получить уровень истории

X

Get Property — получить свойство

X

Set Property — установить свойство

X

Delete Property — удалить свойство

X

Get License Key — получить лицензионный ключ

X

Set License Key — установить лицензионный ключ

X

Delete License Key — удалить лицензионный ключ

X

Register Process Application — зарегистрировать процессное приложение

X

Unregister Process Application — удалить регистрацию процессного приложения

X

Get Process Application for Deployment — получить процессное приложение для деплоймента

X

Register Deployment — зарегистрировать деплоймент

X

Unregister Deployment — удалить регистрацию деплоймента

X

Get Registered Deployment — получить зарегистрированный деплоймент

X

Delete Metrics — удалить метрики

X

Delete Task Metrics — удалить метрики задачи

X

Query Schema Log — отправить запрос к логу схемы

X

Администраторы

OpenBPM Engine не имеет явной концепции "администратора" помимо того, что это пользователь, которому выданы все права на все ресурсы.

The "openbpm-engine-admin" Group

При скачивании дистрибутива OpenBPM Engine приложение "Invoice example" создает группу с id openbpm-engine-admin и выдает все права ко всем ресурсам этой группе.

При отсутствии демо-приложения эта задача выполняется веб приложением OpenBPM Engine Admin. Если веб приложение OpenBPM Engine запущено в первый раз и в базе данных нет ни одного пользователя, оно просит вас выполнить "initial setup". В рамках этого процесса создается группа openbpm-engine-admin, и ей выдаются все разрешения на все ресурсы.

LDAP: Группа "openbpm-engine-admin" не создается при использовании LDAP (поскольку доступ к LDAP можно получить только в режиме "только для чтения"). Также см. нижеприведенный раздел по вопросу о плагине авторизации администратора.

Плагин авторизации администратора

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

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

Далее приведен пример того, как конфигурировать плагин авторизации администратора в bpm-platform.xml / processes.xml:

<process-engine name="default">
  ...
  <plugins>
    <plugin>
      <class>io.openbpm.bpm.engine.impl.plugin.AdministratorAuthorizationPlugin</class>
      <properties>
        <property name="administratorUserName">admin</property>
      </properties>
    </plugin>
  </plugins>
</process-engine>

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

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

Полный список конфигурационных свойств:

Свойство Описание

administratorUserName

Имя пользователя-администратора. Если это имя установлено в непустое значение, не равное null, плагин создаст авторизации администратора на уровне пользователя для всех встроенных ресурсов.

administratorGroupName

Имя группы-администратора. Если это имя установлено в непустое значение, не равное null, плагин создаст авторизации администратора на уровне группы для всех встроенных ресурсов.

Конфигурационные опции

Этот раздел объясняет доступные опции для конфигурирования движка управления процессами, относящиеся к авторизации.

Включение проверок авторизации

Проверки авторизации могут быть включены или отключены глобально с использованием конфигурационной опции authorizationEnabled. Значение по умолчанию для этой конфигурационной опции — false.

Включение проверок авторизации для кода пользователя

Конфигурационная опция authorizationEnabledForCustomCode контролирует, выполняются ли проверки авторизации для команд, выполняемых с кодом делегации (то есть Java Delegate). Значение по умолчанию для этой конфигурационной опции — false.

Проверка Revoke-авторизаций

Конфигурационная опция authorizationCheckRevokes контролирует, берут ли проверки авторизации в расчет авторизации типа Revoke (отобрать).

Доступные значения следующие:

  • always: всегда включает проверки для revoke-авторизаций. Этот режим эквивалентен поведению < 7.5.

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

  • never: никогда не проверять revoke-авторизации. Этот режим имеет максимальную производительность и по сути отключает использование revoke-авторизаций.

Мы настоятельно рекомендуем использовать этот режим.

  • auto (значение по умолчанию): этот режим проверяет revoke-авторизации только в том случае, если хотя бы одна revoke-авторизация существует для текущего пользователя или одной из групп, где текущий пользователь является участником. Чтобы достичь этого, производится проверка один раз на команду на наличие потенциально применимых revoke-авторизаци. В зависимости от результата, проверка авторизации затем использует или не использует revoke.

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

Также см. раздел "Вопросы производительности" link:{{< relref "#performance-considerations" >}}[] на этой странице.

Пример для Java API

Создается авторизация между пользователем/группой и ресурсом. Она описывает разрешения для пользователя/группы на доступ к этому ресурсу. Авторизация может выражаться в различных разрешениях, таких как Read (считать), Update (обновить) и Delete (удалить) ресурс. (См. "Авторизация", чтобы узнать ббольше подробностей).

Чтобы выдать разрешение на доступ к определенному ресурсу, создается объект-авторизация. Например, чтобы выдать доступ к некоему фильтру:

Authorization auth = authorizationService.createNewAuthorization(AUTH_TYPE_GRANT);

// The authorization object can be configured either for a user or a group:
auth.setUserId("john");
//  -OR-
auth.setGroupId("management");

//and a resource:
auth.setResource("filter");
auth.setResourceId("2313");
// a resource can also be a process definition
auth.setResource(Resources.PROCESS_INSTANCE);
// the process defintion key is the resource id
auth.setResourceId("invoice");

// finally the permissions to access that resource can be assigned:
auth.addPermission(Permissions.READ);
// more than one permission can be granted
auth.addPermission(Permissions.CREATE);

// and the authorization object is saved:
authorizationService.saveAuthorization(auth);

В результате заданный пользователь или группа получает разрешение Read (считать) означенный фильтр.

Другой возможный пример — ограничить группу людей, которым разрешено запускать некий процесс:

//we need to authorizations, one to access the process definition and another one to create process instances
Authorization authProcessDefinition = authorizationService.createNewAuthorization(AUTH_TYPE_GRANT);
Authorization authProcessInstance = authorizationService.createNewAuthorization(AUTH_TYPE_GRANT);

authProcessDefinition.setUserId("johnny");
authProcessInstance.setUserId("johnny");

authProcessDefinition.setResource(Resources.PROCESS_DEFINITION);
authProcessInstance.setResource(Resources.PROCESS_INSTANCE);
//the resource id for a process definition is the process definition key
authProcessDefinition.setResourceId("invoice");
//asterisk to allow the start of a process instance
authProcessInstance.setResourceId("*")
// allow the user to create instances of this process definition
authProcessDefinition.addPermission(Permissions.CREATE_INSTANCE);
// and to create processes
authProcessInstance.addPermission(Permissions.CREATE);

authorizationService.saveAuthorization(authProcessDefinition);
authorizationService.saveAuthorization(authProcessInstance);

Веб приложение Admin от OpenBPM Engine

Веб приложение Admin от OpenBPM Engine предоставляет графический интерфейс для конфигурирования авторизаций из коробки.

Вопросы производительности

Авторизации вычисляются в базах данных, что является наиболее эффективным методом. Пример: при выполнении запроса по задачам, запрос к базе данных возвращает только те задачи, для которых пользователь имеет авторизацию типа READ.

Performance of Checking Grant Authorizations

Когда используются только авторизации типа Grant (выдать), проверка весьма эффективна, поскольку таблица авторизаций может быть соединена через join с таблицей ресурсов (задач, экземпляров процессов и т.д.).

Ппоизводительность проверок Revoke-авторизаций

Revoke-авторизации имеют высокую стоимость проверок. Проверка должна принимать во внимание приоритетность авторизаций. Пример: Grant на уровне пользователя имеет более высокий приоритет, чем Revoke на уровне группы. Последовательность вложенных SQL-команд типа CASE использует вложенный select для учета приоритетности. Этот подход имеет два недостатка:

  • Проверка масштабируется линейно с кардинальностью таблицы ресурса (удвоение числа задач вдвое замедляет запрос)

  • Конкретный констракт, основанный на командах CASE имеет исключительно низкую производительность на следующих базах данных: PostgreSQL, DB2

На этих базах данных авторизации типа Revoke практически непригодны для использования.

См. также раздел #_check_revoke_authorizations на этой странице.

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org