Головна/Credentials/Credentials організації ENУКРРУС API-довідник (ReDoc) ↗

Credentials організації

Один ключ на весь тенант — керують ним менеджерські ролі, обслуговує він кожного учасника.

Credential організації належить тенанту, а не людині: сервер ставить owner_type=organization і owner_id = клейм org_id вашого токена. Один запис обслуговує всю команду — збережіть спільний вендорський ключ один раз, ротуйте його один раз, замість того щоб копіювати його в персональні credentials кожного учасника.

API — це дзеркало

/v1/org-credentials віддзеркалює Personal Credentials ендпоїнт-в-ендпоїнт — create, list, get, PATCH-ротація, make-default, disable/enable, delete — з ідентичною семантикою (default-записи, версії, м'яке видалення) плюс поле owner_id у відповідях. Різниця — хто може це викликати.

Доступ: лише менеджерські ролі

І читання, і запис вимагають, щоб той, хто викликає, був менеджером організації. Діють два ґейти, обидва відповідають 403 FORBIDDEN:

  1. Звичайний рольовий ґейт: user/provider_admin мутують, auditor лише читає.
  2. Ґейт організації: ваш токен мусить нести org_id, а ваша сира роль в організації (як її видав identity provider — owner, admin, member, viewer) мусить бути в менеджерському списку сервісу (JWT_ORG_MANAGER_ROLES, за замовчуванням owner і admin).

Логіка така: інвентар секретів організації — навіть маскований — це справа її адміністраторів. member-у треба знати, чи працюватиме переклад, і для цього є Credential Status, який може викликати будь-яка роль і який звітує про рівень організації, не розкриваючи жодного запису.

Ізоляція між організаціями абсолютна: записи іншого тенанта відповідають 404, а audit-стрічка фіксує sub діючого користувача як актора кожної зміни.

Що бачать учасники

Щойно менеджер зберіг default організації для провайдера, resolve віддає його кожному учаснику без персонального credential — ланцюг USER → ORGANIZATION → PLATFORM. Учасник із власним ключем далі користується власним; вимкніть org-запис — і учасники провалюються на platform-рівень (там, де він дозволений).

Розібраний приклад, включно з 403, який бачить не-менеджер: сценарій cookbook 05.

Немає контексту організації — немає API

Токен без org_id (користувач не обрав організацію на логіні) отримує 403 на кожному ендпоїнті /v1/org-credentials — просто немає тенанта, від імені якого діяти. Яка це організація — вирішує token-exchange флоу identity provider; див. User Plane Tokens.