Главная/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-провайдер — owner, admin, member, viewer) должна быть в списке менеджеров сервиса (JWT_ORG_MANAGER_ROLES, по умолчанию owner и admin).

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

Изоляция между организациями абсолютна: записи другого тенанта отвечают 404, а audit-лента записывает sub действующего пользователя как актора каждого изменения.

Что видят участники

Как только менеджер сохранил организационный default для провайдера, resolve отдаёт его каждому участнику без личного credential — цепочка: USER → ORGANIZATION → PLATFORM. Участник с собственным ключом продолжает пользоваться своим; отключите org-запись — и участники провалятся на платформенный уровень (где он разрешён).

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

Нет контекста организации — нет API

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