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

Около 4 мин

Система авторизации (OAuth2, Keycloak, ADFS)

OAuth2 (рекомендуется)

Корпоративная авторизация через внешние провайдеры (Keycloak, Azure AD, и др.)

Параметр	Описание	Пример значения
OAuthIsEnabled	Включение OAuth2	`true`
OAuthClientId	ID клиента в провайдере	`stormbpmn-client`
OAuthClientSecret	Секрет клиента	`your-client-secret`
OAuthAuthorizeUri	URL авторизации	`https://keycloak.company.com/auth/realms/master/protocol/openid-connect/auth`
OAuthUserInfoUri	URL получения информации о пользователе	`https://keycloak.company.com/auth/realms/master/protocol/openid-connect/userinfo`
OAuthTokenUri	URL получения токена	`https://keycloak.company.com/auth/realms/master/protocol/openid-connect/token`
OAuthButtonLabel	Текст на кнопке входа	`"Войти через корпоративный аккаунт"`
OAuthRedirectUri	URL возврата после авторизации	`https://stormbpmn.company.com/app/signin`
OAuthFlowMode	Режим потока: `PKCE` или `implicit_flow`	`PKCE`

Режим потока: PKCE или implicit

StormBPMN умеет работать в двух режимах, переключает их параметр OAuthFlowMode:

Режим	Что происходит	Когда выбирать
`PKCE` (рекомендуется)	Authorization Code Flow с PKCE: провайдер возвращает `code`, сервер меняет его на токен по защищённому каналу	Всегда, если провайдер умеет Authorization Code Flow. Implicit flow включать не нужно
`implicit_flow` (legacy)	`response_type=token`, access token приходит в браузер во фрагменте URL, данные пользователя берутся из `/userinfo`	Провайдер выдаёт непрозрачный (не JWT) access token или не поддерживает PKCE

Если параметр не задан, используется implicit_flow — это сделано ради обратной совместимости со старыми установками.

Параметры режима PKCE

Параметр	Значение	Примечание
OAuthFlowMode	`PKCE`	Включает Authorization Code Flow
OAuthResponseType	`code`	Обязательно задать вместе с `OAuthFlowMode`
OAuthScope	`openid profile email`	Должен давать доступ к email пользователя
OAuthCodeChallengeMethod	`S256`	Оставляйте `S256`, `plain` — только для древних провайдеров
OAuthResource	Идентификатор Web API	Только для ADFS, остальные провайдеры параметр игнорируют

OAuthFlowMode и OAuthResponseType меняются вместе

Если включить OAuthFlowMode = PKCE, но не заполнить OAuthResponseType, страница входа уйдёт к провайдеру со старым response_type=token и будет ждать code, которого не будет. Вход зависнет без внятной ошибки. Для PKCE нужны оба параметра.

Требования к клиенту в режиме PKCE

Клиент должен быть конфиденциальным: OAuthClientSecret обязателен и отправляется при обмене кода на токен.
Access token должен быть JWT и содержать email (либо upn, либо unique_name). Провайдерам с непрозрачными токенами оставляйте implicit_flow.
OAuthRedirectUri должен совпадать с зарегистрированным у провайдера символ в символ.

Сессия StormBPMN может жить ровно столько, сколько сессия у провайдера

По умолчанию после входа StormBPMN выпускает собственный токен на срок SESSION_EXPIRATION и живёт им независимо от провайдера. Если политика безопасности этого не допускает, включите привязку сессии к SSO — тогда токен продлевается у провайдера по refresh_token, а отзыв сессии в провайдере разлогинивает пользователя в StormBPMN.

Подробности и порядок включения — Привязка сессии к SSO.

Настройка Keycloak

Пошаговая инструкция для Keycloak 26.0.7:

Создать клиента в нужном realm
Client ID: stormbpmn-client
Valid redirect URIs: https://stormbpmn.company.com/app/signin
Web origins: https://stormbpmn.company.com
Client authentication: ON
Standard flow: ON. Implicit flow оставьте OFF, если в StormBPMN выбран OAuthFlowMode = PKCE; включать его нужно только для legacy-режима implicit_flow
Для PKCE: вкладка Advanced → Proof Key for Code Exchange Code Challenge Method → S256
Client Scopes: email и profile должны быть default
Получить Client Secret на вкладке Credentials

Заполнение ФИО в профиле пользователя

При каждом входе через OAuth2 StormBPMN синхронизирует поля профиля «Полное имя» (fullName), «Имя» (firstName) и «Фамилия» (lastName) из данных провайдера — сменили фамилию в провайдере, при следующем входе она обновится и в StormBPMN. Если провайдер атрибуты имени не передаёт, уже заполненные поля профиля не затираются.

Откуда берутся данные — зависит от режима потока:

Режим	Источник	Атрибуты
`implicit_flow`	Ответ `/userinfo`	`family_name` — фамилия, `given_name` (или `name`, если `given_name` нет) — имя, `middle_name` — отчество
`PKCE`	Claims access token	Готовый `full_name` или `displayname`; если их нет — ФИО собирается из `family_name` (или `surname`), `given_name` и `middle_name`

«Полное имя» собирается в формате «Фамилия Имя Отчество» из тех частей, которые провайдер передал.

Что настраивать у провайдера

Как правило, достаточно стандартного scope profile — он отдаёт атрибуты имени в /userinfo. Специальных прав или кастомных маппингов не требуется: если провайдер передаёт family_name, given_name/name и middle_name, ФИО заполнится автоматически.

Microsoft ADFS

Особенности Microsoft ADFS

Компания Microsoft имеет специфический (альтернативно-одарённый) подход к стандартам OAuth2/OpenID Connect. В частности, ADFS не возвращает информацию о пользователе через стандартную ручку /userinfo, что усложняет интеграцию. Также интерфейсы ADFS (особенно в русской локализации) могут показаться запутанными.

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

Шаг 1: Настройка ADFS

Создание группы приложений

В оснастке ADFS Management создайте группу приложений:
В группе создайте 2 приложения:

Настройка серверного приложения

Первое приложение - Server application (серверное приложение):
В настройках укажите:
- Правильный Redirect URI перенаправления
- Запомните Client ID и Client Secret

Настройка веб-API

Второе приложение - Web API (веб-интерфейс API):
Создайте Relying party identifier (идентификатор проверяющей стороны) и запомните его

Настройка политик доступа

Выберите подходящую Access Control Policy (политику контроля доступа):

Настройка маппинга атрибутов

В разделе Issuance Transform Rules (Правила преобразования выдачи) настройте маппинг атрибутов:

Важно: маппинг claims

StormBPMN ожидает следующие claims в токене:

Поле StormBPMN	Ожидаемый claim	Тип
`email`	`email`	Стандартный
`firstName`	`given_name`	Стандартный
`lastName`	`family_name`	Стандартный
`middleName`	`middle_name`	Стандартный
`fullName`	`full_name`	Кастомный
`position`	`position`	Кастомный

Кастомный claim full_name настраивать не обязательно: если его (и displayname) в токене нет, StormBPMN соберёт «Полное имя» сам из family_name (или surname), given_name и middle_name — в формате «Фамилия Имя Отчество».

Кастомные claims (Полное Имя, Должность) должны быть созданы и опубликованы в описании утверждений (Claims Description).
Настройки в админке

Настройка разрешений

Установите разрешения клиента:

Завершенная настройка

Если все шаги выполнены внимательно, настройка ADFS на стороне сервера завершена.

Шаг 2: Настройка StormBPMN

Параметры для настройки

Вам потребуются сохраненные значения:

Client ID (из серверного приложения)
Client Secret (из серверного приложения)
Resource identifier (идентификатор ресурса из Web API)

Настройка в административной панели

Перейдите в административную панель: /app/admin → вкладка Безопасность
Укажите следующие параметры:

Параметр	Значение	Примечание
OAuthClientId	Ваш Client ID	Из серверного приложения ADFS
OAuthClientSecret	Ваш Client Secret	Из серверного приложения ADFS
OAuthAuthorizeUri	`/adfs/oauth2/authorize`	Стандартный путь ADFS
OAuthUserInfoUri	`/adfs/userinfo`	Для обратной совместимости (ADFS не использует эту ручку)
OAuthTokenUri	`/adfs/oauth2/token`	Стандартный путь ADFS
OAuthButtonLabel	`"Войти через ADFS"`	Текст на кнопке входа
OAuthIsEnabled	`true`	Включение OAuth2
OAuthRedirectUri	`https://your-storm-url/app/signin`	URL вашего StormBPMN
OAuthResponseType	`code`	Тип ответа
OAuthScope	`openid profile email`	Области доступа
OAuthCodeChallengeMethod	`S256`	Метод challenge
OAuthFlowMode	`PKCE`	Режим потока
OAuthResource	Ваш Resource identifier	Из Web API приложения

Завершенная настройка

Дополнительные требования

Сертификаты

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

Тестирование

Настройка протестирована и гарантированно работает с:

Windows Server 2022
ADFS 4.0

Если интеграция не работает, проверьте:

Корректность всех параметров
Правильность маппинга claims
Наличие всех необходимых разрешений в ADFS
Доверенные сертификаты (если используются)

Проверка Claims

Дополнительная проверка прав в токене OAuth2:

Параметр	Описание	Пример значения
OAuthCheckClaim	Включить проверку	`true`
OAuthClaimName	Название claim	`groups`
OAuthClaimValue	Требуемое значение	`stormbpmn-users`

Откуда берётся claim

Источник значения зависит от режима потока: при OAuthFlowMode = PKCE claim читается из access token, при implicit_flow — из ответа /userinfo. Переключая режим, проверьте, что нужный claim попадает именно туда: в Keycloak за это отвечает соответствующий mapper в client scope.

Встроенная авторизация

Только для тестирования

Встроенная авторизация подходит только для тестовых сред. В production используйте OAuth2.

Аварийный вход: Добавьте ?showBasicLogin=true к URL входа для доступа к базовой форме, даже если OAuth2 включен.

Смена пароля

Безопасность смены пароля

В версии продукта реализованы усиленные правила безопасности для встроенной авторизации:

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