Роли и доступ

Доступ в шлюзе разграничен на двух уровнях RBAC с ролевыми профилями поверх фиксированной матрицы ролей. Роли покрывают команду разработки без отдельной «роли разработчика»: поверхность MCP делится по оси чтение / запись / администрирование.

Роли

• Viewer: участники только-чтение. Все 7 read-инструментов из IDE или чат-клиента; создавать черновики и администрировать нельзя.
• Manager (или Accountant, который дополнительно может проводить и отменять проведение в веб-консоли): read-инструменты плюс 4 write-инструмента, создающие черновики на одобрение.
• Admin: управление пользователями, настройками, аудитом и инструментами.
• Owner: всё, что умеет Admin, плюс биллинг. Один Owner создаётся при установке.

Отдельной роли «разработчик» нет намеренно: она дублировала бы Viewer (только чтение) или Manager (чтение плюс черновики) с чисто косметическим отличием, поэтому используется существующая матрица.

Каждый участник выпускает собственные API-токены и атрибутируется в журнале аудита независимо. Черновики участника приватны для него и не видны коллегам даже через list_my_drafts / get_draft. Минимальные роли по каждому инструменту перечислены в таблице на странице архитектуры.

Два уровня RBAC

• Уровень 1, подключение к серверу. Достижимость MCP-сервера проверяется на подключении; отказ возвращает 403 без утечки факта существования сервера.
• Уровень 2, вызов инструмента. Право на конкретный инструмент проверяется при диспетчеризации каждого вызова по матрице ролей.

Обе проверки fail-closed: неизвестное или устаревшее состояние трактуется как отказ.

Ролевые профили

Поверх фиксированной матрицы ролей администратор настраивает именованные ролевые профили в разделе /web/admin/role-profiles. Профиль может только сужать доступ: настройка компонуется с потолком роли по И, поэтому расширить доступ выше потолка структурно невозможно, а пустая настройка ничего не меняет.

Кроме прав, профиль задаёт per-role параметры ответов:

• строгость маскирования PII: inherit / strict / moderate / off;
• подробность ответов: concise / normal / detailed.

Пресеты профилей

Три готовых пресета применяются администратором по явному действию:

• developer-read-only: убирает право записи dev-поверхности;
• accountant-view и manager-view: убирают создание черновиков (draft:create).

Пресеты сужающие по построению: применённый пресет только убирает доступ, эскалация структурно невозможна. Все view-пресеты идут со строгостью маскирования inherit, поэтому никогда не ослабляют маскирование ниже значения по умолчанию инсталляции.

Группы доступа

Именованные группы доступа с менеджерами групп определяют, какие пользователи и менеджеры достигают какие информационные базы. Группы работают слоем под потолком RBAC: они сужают охват, а не расширяют права.

Токены и сессии

Веб-консоль работает по сессионным cookie с CSRF-защитой. MCP-клиенты аутентифицируются Bearer-токенами вида ent_live_<...>, которые выпускаются через веб-интерфейс; маршрутизация запросов по-пользовательская. Неудачные попытки Bearer-аутентификации ограничены по частоте (см. квоты и лимиты).

Корпоративный вход (SSO)

Для входа в веб-консоль через корпоративный каталог есть три адаптера за одним швом внешней идентичности. Все выключены по умолчанию и включаются администратором.

• OIDC (/web/admin/sso): Authorization Code с PKCE. Валидация ID-токена fail-closed: подпись, издатель, аудитория, срок действия, nonce и state; TLS обязателен на все обнаруженные endpoints провайдера.
• LDAP / Active Directory (/web/admin/ldap): схема search-then-bind, настраивается под каталог (AD, OpenLDAP, ALD Pro, Samba: фильтр пользователя, атрибут UUID, атрибут групп). LDAPS или StartTLS обязателен, открытым текстом соединение не устанавливается. Идентичность привязывается к неизменяемому objectGUID или entryUUID, а не к DN или логину.
• SAML 2.0: вход, инициированный сервис-провайдером (Keycloak, ADFS и другие IdP). Подпись ответа проверяется по закреплённому сертификату IdP до какого-либо доверия содержимому; принимается только persistent NameID.

Общие правила для всех адаптеров:

• автосоздание пользователя мапит группы IdP в роли, но никогда в Owner; Admin назначается только по явному маппингу;
• существующий аккаунт присоединяется, только если его набор прав это подмножество замапленной роли (fail-closed);
• секреты адаптеров хранятся запечатанными, поля форм только на запись;
• локальный вход владельца никогда не идёт через SSO и не отключается (break-glass).

Рабочие места

Шлюз управляет рабочими местами команды в рамках лицензии: масштабирование на людей это приглашение новых пользователей и выпуск их токенов.