Огляд єдиного входу¶

Зміст¶

1. Вступ і огляд
2. Посібники для постачальників
3. Кроки налаштування
4. Налаштування дашборду
5. Налаштування бекенду
6. Тестування входу
7. Усунення несправностей
8. Підтримувані постачальники

Вступ і огляд¶

У цьому посібнику наведено покрокові інструкції з інтеграції єдиного входу (SSO) з платформою digna за допомогою OpenID Connect (OIDC).

Що таке SSO?¶

Єдиний вхід дозволяє користувачам безпечно входити в digna з корпоративними обліковими даними через зовнішніх постачальників ідентичності. Користувачі можуть автентифікуватися за допомогою корпоративних облікових даних, а не керувати окремими паролями digna.

Як це працює¶

SSO у digna реалізовано за допомогою протоколу OIDC. Кілька постачальників ідентичності можна налаштувати паралельно, змінивши два ключові файли конфігурації:

• dashboard_config.toml — керує інтерфейсом входу у фронтенді
• config.toml — налаштовує підключення OIDC у бекенді

Підтримувані постачальники¶

У прикладах цього посібника використано Microsoft і Google, але будь-якого постачальника, сумісного з OIDC, можна інтегрувати за тією самою схемою.

Посібники для постачальників¶

Кожному постачальнику потрібні ті самі чотири значення — ідентифікатор клієнта, секрет клієнта, URI перенаправлення та URL виявлення (discovery URL), — але кожен розміщує їх у різних місцях своєї консолі адміністратора, а в кількох є специфічний крок, якого немає в інших. Наведені нижче посібники охоплюють цю половину роботи; ця сторінка описує половину на боці digna, яка однакова для всіх.

Будь-який інший постачальник, сумісний з OIDC, працює так само — див. Інші постачальники OIDC.

Кроки налаштування¶

Для налаштування SSO потрібно оновити два файли. У цьому розділі пояснюється, як налаштувати кожен із них.

Огляд файлів конфігурації¶

Щоб SSO працював правильно, необхідно налаштувати обидва файли.

Налаштування дашборду¶

Розташування файлу¶

dashboard/dashboard_config.toml

Крок 1: Додайте постачальників OIDC¶

Додайте записи в масив [[login.oidc]] для кожного постачальника ідентичності, якого ви хочете підтримувати.

Приклад з Microsoft і Google:

[[login.oidc]]
key = "microsoft"
label = "Login with Microsoft"

[[login.oidc]]
key = "google"
label = "Login with Google"

Крок 2: Налаштуйте параметри входу¶

Укажіть, чи дозволено вхід за паролем:

[login]
usePassword = true

Параметри конфігурації¶

Розділ [[login.oidc]]¶

Розділ [login]¶

Як працює usePassword¶

Якщо usePassword = true: - Екран входу показує кнопки SSO (наприклад, "Login with Microsoft") - Екран входу також показує поля імені користувача та пароля - Користувачі можуть автентифікуватися будь-яким із цих способів - Можливі гібридні налаштування, коли одні користувачі входять через SSO, а інші — за паролем

Якщо usePassword = false (або параметр не вказано): - Екран входу показує лише кнопки SSO - Полів імені користувача та пароля немає - Доступна лише автентифікація OIDC

Повний приклад¶

[login]
usePassword = true

[[login.oidc]]
key = "microsoft"
label = "Login with Microsoft"

[[login.oidc]]
key = "google"
label = "Login with Google"

[[login.oidc]]
key = "okta"
label = "Login with Okta"

Налаштування бекенду¶

Розташування файлу¶

/config.toml

(Кореневий каталог інсталяції digna)

Крок 1: Додайте розділи постачальників OIDC¶

Кожен постачальник повинен мати окремий розділ [oidc_clients.<key>]. Ключ має збігатися зі значенням key, визначеним у dashboard_config.toml.

Налаштування Microsoft¶

[oidc_clients.microsoft]
DIGNA_OIDC_CLIENT_ID = "<client_id>"
DIGNA_OIDC_CLIENT_SECRET = "<client_secret>"
DIGNA_OIDC_REDIRECT_URI = "http://localhost:5173/oidc/callback"
DIGNA_OIDC_CONFIGURATION_URL = "https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration"

Налаштування Google¶

[oidc_clients.google]
DIGNA_OIDC_CLIENT_ID = "<client_id>"
DIGNA_OIDC_CLIENT_SECRET = "<client_secret>"
DIGNA_OIDC_REDIRECT_URI = "http://localhost:5173/oidc/callback"
DIGNA_OIDC_CONFIGURATION_URL = "https://accounts.google.com/.well-known/openid-configuration"

Параметри конфігурації¶

URI перенаправлення¶

URI перенаправлення має бути таким самим у конфігурації вашого постачальника ідентичності:

http://localhost:5173/oidc/callback

Якщо digna розміщено на іншому домені, змініть його відповідно: - Локально: http://localhost:5173/oidc/callback - Робоче середовище: https://digna.yourdomain.com/oidc/callback

Повний приклад¶

[oidc_clients.microsoft]
DIGNA_OIDC_CLIENT_ID = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
DIGNA_OIDC_CLIENT_SECRET = "abc123xyz789def456ghi"
DIGNA_OIDC_REDIRECT_URI = "https://digna.yourdomain.com/oidc/callback"
DIGNA_OIDC_CONFIGURATION_URL = "https://login.microsoftonline.com/12345678-1234-1234-1234-123456789012/v2.0/.well-known/openid-configuration"

[oidc_clients.google]
DIGNA_OIDC_CLIENT_ID = "123456789-abcdefghijklmnopqrstuvwxyz.apps.googleusercontent.com"
DIGNA_OIDC_CLIENT_SECRET = "google_secret_xyz789"
DIGNA_OIDC_REDIRECT_URI = "https://digna.yourdomain.com/oidc/callback"
DIGNA_OIDC_CONFIGURATION_URL = "https://accounts.google.com/.well-known/openid-configuration"

Тестування входу¶

Після завершення налаштування переконайтеся, що SSO працює правильно.

Контрольний список перед тестуванням¶

Перед тестуванням переконайтеся, що:

• dashboard_config.toml оновлено з постачальниками OIDC
• config.toml оновлено з обліковими даними OIDC
• Обидва файли збережено
• Облікові дані правильні (ідентифікатор клієнта, секрет клієнта)
• URI перенаправлення відповідає URL вашого розгортання
• Застосунок у постачальника ідентичності налаштовано з цим URI перенаправлення

Кроки тестування¶

Крок 1: Перезапустіть служби¶

Перезапустіть бекенд digna і вебсервер, щоб застосувати зміни.

Якщо digna працює як служба у Windows:

cd C:\path\to\digna
digna windows stop
digna windows start

Якщо digna працює як служба в Linux або macOS:

cd /opt/digna/bin
sudo ./stop_service.sh
sudo ./start_service.sh

Якщо digna запущено вручну:

digna serve --address localhost --port 8082

Перезапустіть також вебсервер — IIS або Tomcat у Windows, nginx або Apache в Linux і macOS.

Крок 2: Відкрийте дашборд¶

Відкрийте дашборд digna у браузері:

http://localhost:5173

(або налаштований вами URL дашборду)

Крок 3: Перевірте кнопки входу¶

Переконайтеся, що для кожного налаштованого постачальника з'являються кнопки входу:

• Має бути кнопка "Login with Microsoft"
• Має бути кнопка "Login with Google"
• (Якщо usePassword = true) Мають бути поля імені користувача та пароля

Якщо кнопки не з'являються: - Перевірте, чи збережено dashboard_config.toml - Перевірте, чи перезапущено службу дашборду - Перевірте консоль браузера (F12) на наявність помилок

Крок 4: Перевірте вхід через SSO¶

Натисніть одну з кнопок SSO (наприклад, "Login with Microsoft"):

1. Вас має бути перенаправлено на сторінку входу постачальника ідентичності
2. Увійдіть із корпоративними обліковими даними
3. Вас має бути перенаправлено назад до digna
4. Ви маєте увійти в digna

Крок 5: Перевірте створення користувача¶

Після успішного входу через SSO:

• Користувача має бути автоматично створено в digna
• Користувач має бути в системі
• Профіль користувача має показувати ваші облікові дані від постачальника ідентичності
• Ви маєте бачити дашборд digna

Крок 6: Перевірте вхід за паролем (якщо ввімкнено)¶

Якщо usePassword = true:

1. Вийдіть із digna
2. На сторінці входу введіть ім'я користувача та пароль
3. Ви маєте змогу увійти з обліковими даними за паролем

Усунення несправностей¶

Кнопки входу не з'являються¶

Симптоми: - Кнопки входу OIDC не видно на сторінці входу - Видно лише поля пароля (якщо usePassword = true)

Причини та рішення: 1. Перевірте, чи dashboard_config.toml знаходиться в каталозі dashboard/ 2. Переконайтеся, що розділи [[login.oidc]] присутні та мають правильний синтаксис 3. Перезапустіть службу дашборду 4. Очистіть кеш браузера (Ctrl+Shift+Delete або Cmd+Shift+Delete) 5. Перевірте консоль браузера (F12 → вкладка Console) на наявність помилок

Помилка невідповідності URI перенаправлення¶

Симптоми: - Після натискання кнопки SSO з'являється помилка "redirect_uri mismatch" - Помилка "The redirect URI is not registered"

Причини та рішення: 1. Перевірте, чи правильний DIGNA_OIDC_REDIRECT_URI у config.toml 2. Перевірте, чи зареєстровано URI перенаправлення в налаштуваннях постачальника ідентичності 3. Переконайтеся, що обидва місця використовують ідентичні URL (включно з протоколом, доменом і шляхом) 4. Перевірте URI перенаправлення на наявність друкарських помилок 5. Якщо використовується HTTPS, переконайтеся, що сертифікат дійсний

Помилка недійсних облікових даних клієнта¶

Симптоми: - Помилка "Invalid client ID or secret" - Автентифікація не вдається з помилкою облікових даних

Причини та рішення: 1. Перевірте, чи правильні DIGNA_OIDC_CLIENT_ID і DIGNA_OIDC_CLIENT_SECRET 2. Переконайтеся, що немає зайвих пробілів або спеціальних символів 3. Перевірте, чи не минув термін дії облікових даних і чи їх не відкликано 4. Перезапустіть службу бекенду після оновлення конфігурації 5. Перевірте в консолі постачальника ідентичності, що облікові дані активні

Вхід зависає або завершується за тайм-аутом¶

Симптоми: - Натискання кнопки SSO нічого не робить - Тайм-аут через кілька секунд - Браузер показує "Failed to connect" або подібне повідомлення

Причини та рішення: 1. Перевірте, чи працює бекенд digna: digna repo check 2. Перевірте мережеве з'єднання з постачальником ідентичності 3. Перевірте доступність DIGNA_OIDC_CONFIGURATION_URL 4. Переконайтеся, що правила брандмауера дозволяють вихідні підключення HTTPS 5. Переконайтеся, що бекенд і дашборд можуть зв'язатися один з одним

Користувачі не створюються автоматично¶

Симптоми: - Вхід через SSO успішний, але користувача в digna не створено - Після входу через SSO з'являється помилка дозволів

Причини та рішення: 1. Перевірте правильність конфігурації OIDC 2. Перевірте, чи налаштовано дозволи користувачів 3. Перегляньте журнали digna на наявність повідомлень про помилки 4. Перезапустіть службу бекенду 5. Якщо проблема не зникає, зверніться на support@digna.ai

Підтримувані постачальники¶

Протестовані та підтримувані¶

Наведених нижче постачальників OIDC протестовано, і вони гарантовано працюють:

Інші постачальники OIDC¶

Можна інтегрувати будь-якого постачальника, що підтримує OpenID Connect. Потрібна інформація:

• Ідентифікатор клієнта (Client ID)
• Секрет клієнта (Client secret)
• URL конфігурації OpenID (зазвичай за адресою /.well-known/openid-configuration)
• Підтримувані області (scopes) (зазвичай openid profile email)

Якщо вам потрібна допомога з інтеграцією певного постачальника, зверніться на support@digna.ai.

Найкращі практики¶

РОБІТЬ: - Використовуйте HTTPS у робочому середовищі (а не HTTP) - Зберігайте секрети клієнта в безпечному місці (за можливості використовуйте змінні середовища) - Періодично змінюйте секрети - Спочатку тестуйте в неробочому середовищі - Документуйте, які постачальники налаштовано - Відстежуйте журнали входу на предмет незвичної активності - Підтримуйте конфігурацію постачальника ідентичності синхронізованою з конфігурацією digna

НЕ РОБІТЬ: - Не зберігайте секрети клієнта в системі керування версіями - Не використовуйте URI перенаправлення HTTP у робочому середовищі - Не налаштовуйте кількох постачальників з однаковим ключем - Не залишайте стандартні або тестові облікові дані в робочому середовищі - Не відкривайте доступ до файлів конфігурації, що містять секрети - Не змішуйте облікові дані середовищ розробки та робочого середовища

Підтримка¶

Потрібна допомога з налаштуванням SSO?

• Електронна пошта: support@digna.ai
• Документація: https://docs.digna.ai
• Вебсайт: https://www.digna.ai

Останнє оновлення: 30 серпня 2026 р.
Випуск: 2026.04
© 2026 digna GmbH — www.digna.ai