OpenID Connect
АРХИВА поддерживает аутентификацию и авторизацию пользователей через протокол OpenID Connect (OIDC). Это позволяет вашим сотрудникам использовать одну учетную запись (например, Keycloak, Google или Microsoft Azure AD) для доступа к системе.
Настройка подключения
Для интеграции с провайдером OpenID вам потребуется указать параметры сервера, данные клиента и правила, по которым пользователи будут получать роли в АРХИВА.
Параметры конфигурации
Большинство современных провайдеров поддерживают функцию Discovery, которая позволяет системе автоматически получить все необходимые адреса (эндпоинты).
Discovery и Эндпоинты
Параметр | Описание | Пример |
|---|---|---|
Использовать Discovery | Включает автоматическое получение настроек от провайдера. |
|
Discovery URL | Ссылка на документ конфигурации провайдера. Обычно заканчивается на |
|
Callback URL | Адрес, на который система вернет пользователя после успешного входа. |
|
Authorization Endpoint | URL-адрес страницы авторизации. Заполняется вручную, если Discovery выключен. |
|
Token Endpoint | URL-адрес для обмена кода на токен доступа. |
|
UserInfo Endpoint | Адрес для получения данных о пользователе (имя, email). |
|
JWK Endpoint | Ссылка на публичные ключи для проверки безопасности токенов. |
|
Параметры клиента
Эти данные вы получаете при регистрации АРХИВА в панели управления вашего OpenID провайдера.
Параметр | Описание | Пример |
|---|---|---|
Client ID | Уникальный идентификатор вашего приложения. |
|
Client Secret | Секретный ключ (пароль) клиента. Храните его в секрете. |
|
Scopes | Права доступа, которые запрашивает система. Обязательно должен быть |
|
Алгоритм JWS | Метод шифрования подписи. Чаще всего используется |
|
Сопоставление данных пользователя
После входа система получает данные о пользователе от провайдера. Вам нужно указать, из каких полей (атрибутов) брать информацию для профиля в АРХИВА.
Параметр | Описание | Пример |
|---|---|---|
Атрибут привязки | Основной логин пользователя в системе. |
|
Атрибут Email | Поле, в котором передается адрес электронной почты. |
|
Значение Email | Правило (регулярное выражение) для проверки email. Обычно |
|
Отображаемое имя | Имя пользователя, которое будет видно в интерфейсе. |
|
Атрибут телефона | Поле с номером телефона (если необходимо). |
|
Автоматическое назначение ролей
Вы можете настроить правила, по которым пользователи будут автоматически получать определенные права доступа в АРХИВА в зависимости от их данных в OpenID.
Пример правила:
Роль: Выберите роль из списка (например, «Администратор»).
Атрибут: Поле для проверки (например,
email).Условие: Способ проверки (например,
contains— содержит).Критерий: Значение, которое мы ищем (например,
admin@company.ru).
В этом случае каждый, чей email содержит admin@company.ru, автоматически станет администратором при входе.
Защита от CSRF и домены
Для корректной работы защиты от CSRF (Cross-Site Request Forgery) важно, чтобы домен, на котором развернута АРХИВА, и домен, указанный в Callback URL, полностью совпадали.
Проблема: Если вы заходите в систему по адресу
http://ip-address:8090, а в Callback URL указаноhttp://domain-name:8090/authorize.do, авторизация может завершиться ошибкой безопасности.Решение: Всегда используйте один и тот же FQDN (полное доменное имя) как для доступа к интерфейсу, так и в настройках Callback URL.
Другие «подводные камни»
Синхронизация времени: Разница во времени между сервером АРХИВА и сервером провайдера (IdP) не должна превышать 5 минут. В противном случае проверка токена (iat/exp claims) завершится ошибкой. Рекомендуется использовать NTP-серверы для синхронизации.
Доступность эндпоинтов: Сервер, на котором установлена АРХИВА, должен иметь прямой сетевой доступ к Discovery URL и всем эндпоинтам провайдера (особенно к Token и UserInfo эндпоинтам).
HTTPS: Многие провайдеры требуют использования защищенного протокола HTTPS для Callback URL.