Перейти до основного вмісту

DolphinScheduler, IoTDB та інші платформи даних Apache: SSO з Casdoor

· Читання за 9 хв
Yang Luo
Yang Luo
Casdoor Maintainer

Кілька проектів Apache для роботи з даними та проміжного ПЗ мають власну інтеграцію входу через Casdoor: Apache DolphinScheduler має тип автентифікації CASDOOR_SSO (починаючи з 3.2.0) та загальний режим OIDC (починаючи з 3.4.0), Apache ShenYu має плагін Casdoor (починаючи з 2.5.1), Apache Pulsar Manager має кнопку "Log in with Casdoor" (починаючи з 0.3.0), а Apache APISIX має плагін authz-casdoor (починаючи з 2.14.0). Винятком є Apache IoTDB: сама база даних автентифікується за допомогою власних користувачів і паролів, і лише вже архівований IoTDB Web Workbench взаємодіє з Casdoor. У таблиці нижче перелічено кожен проект, версію та де знаходяться налаштування; друга частина посту покроково налаштовує автентифікацію користувачів в IoTDB.

Які проекти Apache підтримують Casdoor​

Усі факти в цій таблиці взято з дерева початкового коду кожного проекту та тегів релізів, перевірено 2026-11-02.

ПроектЯк він підключається до CasdoorПерший релізНалаштування
Apache DolphinSchedulerВбудований тип автентифікації CASDOOR_SSO (Java SDK Casdoor, потік коду OAuth 2.0)3.2.0security.authentication.type, casdoor.* у файлі dolphinscheduler-api/src/main/resources/application.yaml
Apache DolphinSchedulerЗагальний вхід через OIDC (Spring Security)3.4.0security.authentication.oidc.* у тому ж файлі
Apache IoTDB Web WorkbenchВхід через Casdoor у веб-консолінемає тегованого релізу, репозиторій архівованийcasdoor.* у backend/src/main/resources/application.properties, VUE_APP_CASDOOR у frontend/.env
Apache IoTDB (сервер)Нативні користувачі та ролі; OpenIdAuthorizer існував до 2.0.8 і був видаленийн/ддив. розділ IoTDB нижче
Apache ShenYuПлагін Casdoor на шлюзі2.5.1конфігурація плагіна endpoint, client_id, client_secrect, certificate, organization-name, application-name
Apache Pulsar ManagerКнопка "Log in with Casdoor" поруч із формою пароля0.3.0casdoor.* у src/main/resources/application.properties; конфігурація фронтенду у front-end/src/main.js починаючи з 0.4.0
Apache ShardingSphere ElasticJob UIКнопка "Login with Casdoor"тільки master, після 3.0.2casdoor.* у бекенді application.properties
Apache APISIXПлагін authz-casdoor або openid-connect2.14.0endpoint_addr, client_id, client_secret, callback_url
RuoYi-Cloud (не проект Apache)Зміни коду з використанням Spring Boot SDK Casdoorн/дваш власний контролер входу

Кожна інтеграція на основі SDK у таблиці дотримується однакового шаблону. Ви створюєте застосунок в Casdoor, копіюєте його client ID, client secret та публічний сертифікат із поля token cert і вставляєте їх у конфігурацію проєкту разом з іменами організації та застосунку. Проєкт перенаправляє браузер до Casdoor, отримує код авторизації, обмінює його на JWT і перевіряє JWT за допомогою сертифіката. Цей сертифікат знаходиться в розділі Certs адміністративної консолі Casdoor; див. сертифікати та поле Token cert у довіднику налаштувань застосунку.

Apache DolphinScheduler​

DolphinScheduler надає два способи інтеграції.

CASDOOR_SSO існує з версії 3.2.0. Встановіть тип і заповніть верхній блок casdoor у файлі dolphinscheduler-api/src/main/resources/application.yaml:

security:
  authentication:
    type: CASDOOR_SSO
    casdoor:
      user:
        admin: "alice"   # this Casdoor user becomes a DolphinScheduler admin
casdoor:
  endpoint: https://door.example.com
  client-id: <client id>
  client-secret: <client secret>
  certificate: |-
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  organization-name: my-org
  application-name: app-dolphinscheduler
  redirect-url: http://localhost:5173/login

redirect-url — це сторінка входу в інтерфейс користувача DolphinScheduler, і вона також має бути додана в поле Redirect URLs застосунку Casdoor. При першому вході DolphinScheduler створює локального користувача з ім'ям та електронною поштою користувача Casdoor. Користувач, зазначений у security.authentication.casdoor.user.admin, отримує тип адміністратора; всі інші стають звичайними користувачами. У нашому посібнику для DolphinScheduler є скріншоти.

OIDC з'явився у версії 3.4.0. Це загальний протокол, тому Casdoor працює як звичайний issuer. Механізм виявлення Spring Security вимагає, щоб налаштований issuer збігався зі значенням issuer у документі виявлення, а оскільки issuer Casdoor — це origin його бекенду, то issuer-uri — це просто URL-адреса Casdoor:

api:
  base-url: https://ds.example.com/dolphinscheduler
  ui-url: https://ds.example.com
security:
  authentication:
    type: OIDC
    oidc:
      enable: true
      providers:
        casdoor:
          display-name: "Login with Casdoor"
          issuer-uri: https://door.example.com
          client-id: <client id>
          client-secret: <client secret>
          scope: openid, profile, email
          user-name-attribute: preferred_username
          groups-claim: groups
      user:
        auto-create: true
        default-tenant-code: "default"
        default-queue: "default"
        admin-group-mapping:
          - my-org/ds-admins

URL перенаправлення, який потрібно зареєструвати в Casdoor, — це https://ds.example.com/dolphinscheduler/login/oauth2/code/casdoor, тобто api.base-url плюс /login/oauth2/code/ плюс ключ провайдера. З областю profile endpoint UserInfo Casdoor повертає preferred_username та groups. За замовчуванням групи надходять у форматі my-org/ds-admins. Якщо ви хочете використовувати ds-admins у admin-group-mapping, встановіть Token group format у значення Name (group) у налаштуваннях застосунку. Якщо auto-create встановлено в false (стандартне значення upstream), увійти можуть лише ті користувачі, які вже існують у DolphinScheduler. У посібнику стандартного OIDC-клієнта описано, що повертають документ виявлення та UserInfo.

Apache ShenYu​

Плагін Casdoor поставляється разом із шлюзом ShenYu починаючи з версії 2.5.1. Ви вмикаєте його в адміністративній консолі ShenYu та заповнюєте дані плагіна. Деякі деталі взяті безпосередньо з вихідного коду, а не з документації. По-перше, секретний ключ названо client_secrect. По-друге, поле сертифіката є однорядковим, тому замість розривів рядків слід писати \n. Плагін приймає JWT із заголовка Authorization або параметри code та state у рядку запиту. Потім він передає дані користувача далі через заголовки name, id та organization. Запити, що не містять нічого з цього, відхиляються з помилкою токена, а не перенаправляються. У гілці master ShenYu (жовтень 2026 року) плагін був переміщений із основного репозиторію в магазин плагінів ShenYu. Назва плагіна, поля та заголовки залишилися незмінними, але вам потрібно самостійно додати стартер shenyu-spring-boot-starter-plugin-casdoor. Див. Використання Casdoor у ShenYu.

Apache Pulsar Manager та ShardingSphere ElasticJob UI​

Pulsar Manager додав підтримку Casdoor у версії 0.3.0. Бекенд читає casdoor.endpoint, casdoor.clientId, casdoor.clientSecret, casdoor.certificate, casdoor.organizationName та casdoor.applicationName з файлу src/main/resources/application.properties. Починаючи з версії 0.4.0, фронтенд використовує casdoor-vue-sdk, налаштований у front-end/src/main.js за допомогою параметрів serverUrl, clientId, organizationName, appName та redirectPath. Новий користувач Casdoor автоматично отримує локальний акаунт у Pulsar Manager. Див. Pulsar Manager.

ElasticJob UI, консоль Apache ShardingSphere ElasticJob, отримала підтримку входу через Casdoor у листопаді 2022 року. Це сталося після останнього релізу, версії 3.0.2, тому вам потрібно збирати версію з гілки master. Ключі використовують дефіси: casdoor.endpoint, casdoor.client-id, casdoor.client-secret, casdoor.certificate, casdoor.organization-name, casdoor.application-name. Див. ShardingSphere.

Для Apache APISIX обидва плагіни описані у статті APISIX.

Покрокове налаштування автентифікації користувачів в Apache IoTDB​

IoTDB автентифікує кожну сесію (CLI, JDBC, Session API) за допомогою імені користувача та пароля, що зберігаються базою даних. Оскільки на серверній стороні немає входу через Casdoor, налаштування виконується за допомогою нативної моделі користувачів IoTDB. Наведені нижче оператори призначені для tree model. Table model у IoTDB 2.x має власний синтаксис, описаний у посібнику table model.

Крок 1. Змініть пароль root. root — єдиний адміністратор, і його не можна видалити. Увійдіть через CLI та встановіть складний пароль:

ALTER USER root SET PASSWORD 'Str0ng_Passw0rd!';

Крок 2. Створіть користувачів. Імена користувачів та паролі мають довжину від 4 до 32 символів. Вони можуть містити літери, цифри та символи !@#$%^&*()_+-=, а починаючи з V2.0.7 пароль не може співпадати з іменем користувача. TimechoDB, комерційна дистрибуція IoTDB від Timecho, вимагає від 12 до 32 символів з великими та малими літерами, цифрою та спеціальним символом, а також має інший пароль root за замовчуванням. Змініть його таким же чином.

CREATE USER ln_reader 'Read_Passw0rd!';
CREATE USER ops_admin 'Ops_Passw0rd!';

Крок 3. Групи привілеїв у ролях. Нові користувачі не мають жодних привілеїв. Серійні привілеї (READ_DATA, WRITE_DATA, READ_SCHEMA, WRITE_SCHEMA або альтернативи READ, WRITE, ALL) надаються на патерни шляхів:

CREATE ROLE ln_readers;
GRANT READ ON root.ln.** TO ROLE ln_readers;
GRANT ROLE ln_readers TO ln_reader;

Крок 4. Делегуйте керування користувачами. Тут існують відмінності між версіями. Починаючи з V2.0.7 глобальні привілеї — це SYSTEM та SECURITY. До цього вони були розподілені між MANAGE_USER, MANAGE_ROLE, MANAGE_DATABASE та іншими. Глобальні привілеї завжди надаються на root.**:

-- IoTDB V2.0.7 and later, TimechoDB
GRANT SECURITY ON root.** TO USER ops_admin;
-- before V2.0.7
GRANT MANAGE_USER, MANAGE_ROLE ON root.** TO USER ops_admin;

Крок 5. Підключіться та перевірте.

sbin/start-cli.sh -h 127.0.0.1 -p 6667 -u ln_reader -pw 'Read_Passw0rd!'

Потім виконайте команду LIST PRIVILEGES OF USER ln_reader;. Ефективні привілеї користувача — це об'єднання його власних привілеїв та привілеїв його ролей. Щоб позбавити користувача привілею, відкликати його потрібно як у самого користувача, так і в усіх ролях, які цей привілей надають.

Що стосується OIDC в IoTDB?​

У старіших версіях IoTDB використовувалися authorizer_provider_class=org.apache.iotdb.commons.auth.authorizer.OpenIdAuthorizer та openID_url. Клієнт передавав токен доступу як ім'я користувача з порожнім паролем. Цей авторизатор був побудований навколо Keycloak. Він розглядає користувача як адміністратора лише якщо realm_access.roles у токені містить iotdb_admin, і кожна перевірка привілеїв зводиться до цієї умови. Його аналізатор токенів також встановлює майже нескінченне відхилення годинника (clock skew), що на практиці ігнорує термін дії токенів. Casdoor не генерує поле realm_access, тому ця інтеграція ніколи не була сумісною. IoTDB видалив цю функціональність у березні 2026 року (apache/iotdb#17320), і вона відсутня у версіях 2.0.10 та 2.0.11.

Якщо ви хочете використовувати облікові записи Casdoor перед IoTDB, наявним варіантом є інтеграція IoTDB Web Workbench. Її репозиторій архівований на GitHub, тому розглядайте його як початкову точку, а не підтримувану продукцію. Саме з'єднання з базою даних все ще використовує користувача IoTDB із кроків вище.

RuoYi​

RuoYi-Cloud не має перемикача для Casdoor. Наш посібник RuoYi замінює вхід за паролем на потік авторизаційного коду Casdoor через SDK Casdoor Spring Boot. Він синхронізує існуючих користувачів RuoYi в Casdoor за допомогою синхронізатора, використовуючи bcrypt, щоб їхні паролі залишалися робочими. Для звичайного додатку Spring Boot почніть з SSO в Spring Boot за допомогою OIDC.

Посилання​