Перейти к содержимому
Olivares AI docs

SSO, SCIM и источники личности (твёрдая атрибуция)

Личность — это жёсткая зависимость под всей картой доступа: нативный аудит атрибутирует доступ к учётным данным, и только реестр личностей может привязать эти учётные данные к агенту или человеку. Эта страница подключает три поверхности личности: вход SSO в консоль, провижининг SCIM в control plane и источники реестров (LDAP, Okta, Entra ID), которые делают атрибуцию attributed вместо approximate.

1. SSO в консоль (OIDC / SAML)

Заголовок раздела «1. SSO в консоль (OIDC / SAML)»

Федеративный вход обслуживается через шов федерации движка. Состояние честно по построению:

  • Конечные точки потока входа существуют в каждой сборке, и движок держит каждое значение потока, несущее секрет, на стороне сервера — состояние CSRF, nonce OIDC, верификатор PKCE (провайдеру уходит только S256-challenge). Authorization Code + PKCE всегда включён.
  • Вход OIDC/SAML с одним IdP доступен во всех редакциях, включая Community. Настройте его через управляемые параметры SSO в консоли. Если управляемой конфигурации нет, движок использует переменные окружения при запуске (OLIVARES_SSO_PROTOCOL, OLIVARES_OIDC_* или OLIVARES_SAML_*). Без настроенного провайдера NoFederation возвращает 501 sso_not_configured: это отсутствие конфигурации, а не ограничение протокола коммерческими редакциями.
  • URI перенаправления/ACS, который должен нести ваш IdP, является точным (…/v1/auth/federation/callback на origin вашей консоли — точное сопоставление по RFC 9700, без трюков с префиксами).

Вкладка консоли Identity & NHI → SSO & SCIM документирует живую конфигурацию, проверяет URI перенаправления вашего IdP относительно точного ожидаемого значения и показывает состояние соединения — а там, где бэкенд панели является объявленным контрактом, ещё не запущенным в работу, она говорит “backend pending” вместо отрисовки сфабрикованных данных:

Представление Identity & access: пользователи и группы, вход через SSO, машинные идентичности (NHI) и состояние ключей. Представление Identity & access: пользователи и группы, вход через SSO, машинные идентичности (NHI) и состояние ключей.

2. Провижининг SCIM (входящий) — Business

Заголовок раздела «2. Провижининг SCIM (входящий) — Business»

Входящий SCIM-сервер — возможность Business (Identity & Scale). Сервер Community монтирует те же URL, аутентифицирует токен и затем отвечает HTTP 501 в формате ошибки SCIM, называя Business; ничего не читается и не записывается. В Community человека удаляют из организации в консоли (Люди) или запросом DELETE /v1/members/{id}.

С Business control plane является стандартным SCIM 2.0 (RFC 7644) поставщиком услуг по адресам:

/v1/scim/v2/Users
/v1/scim/v2/Groups
  • Аутентификация: привязанный к тенанту API-токен admin/owner на интеграции SCIM — та же модель непрозрачного токена, что и в остальной части API, без отдельного типа секрета для SCIM. URL смонтированы всегда (не закрыты функциональным флагом); Community отвечает там 501.
  • Users создаёт и удаляет предоставленный доступ для идентичностей. Изменения зависят от доставки и успешной обработки запроса SCIM. Проверяйте ответ и затронутые права доступа: событие кадровой системы само по себе не доказывает завершённый отзыв. SCIM не удаляет учётные записи операционной системы.
  • Groups несёт справочные данные связи личность-группа. Каждая группа может отображаться на роль control plane через mapped_role — и это отображение принадлежит оператору: оно устанавливается на стороне control plane и аудируется (scim.group.role.map); push от IdP никогда не повышает роль молчаливо. Неизвестные участники в отправленной группе пропускаются и аудируются, а не выдумываются.

3. Источники реестров: LDAP, Okta, Entra ID — Business/Enterprise

Заголовок раздела «3. Источники реестров: LDAP, Okta, Entra ID — Business/Enterprise»

Источники реестров питают инвентарь личностей модуля VI и — вот в чём суть — дают модулю III привязки, повышающие атрибуцию:

{
  "sources": [
    {
      "name": "corp-ldap",
      "kind": "ldap",
      "tenant": "<tenant-id>",
      "config": {
        "url": "ldaps://ldap.corp.example:636",
        "bind_dn": "cn=olivares-ro,ou=svc,dc=corp,dc=example",
        "bind_password": "<reference>",
        "base_dn": "dc=corp,dc=example"
      }
    },
    {
      "name": "okta",
      "kind": "idp",
      "tenant": "<tenant-id>",
      "config": { "provider": "okta", "base_url": "https://corp.okta.com", "api_token": "<reference>" }
    }
  ]
}

Ключевые опции LDAP (из поставляемого дескриптора): user_filter / group_filter, privileged_group_dns (группы, само членство в которых является сигналом привилегированного доступа), nhi_dn_suffix (какое поддерево содержит нечеловеческие личности), start_tls, page_size. Вид idp принимает provider: okta (с api_token) или provider: entra (с tenant_id / client_id / client_secret); okta и entra также работают напрямую как kind.

Как именно это повышает атрибуцию

Заголовок раздела «Как именно это повышает атрибуцию»

Источник реестра регистрирует личности (по внешнему идентификатору) и, где каталог их объявляет, разрешённые гранты. Когда инициатор наблюдаемого ребра совпадает с необщей личностью реестра, модуль III привязывает доступ к этой личности, и достоверность ребра повышается до attributed. Личности, разделяемые несколькими рабочими нагрузками, остаются честно approximate — реестр не может разделить общие учётные данные обратно; только выдача личности на каждого агента может (мост к управлению).

Выделенные виды личности агента и личности рабочей нагрузки (источники федерации агентов — Entra Agent ID, AgentCore, SPIFFE и им подобные) — это твёрдый сигнал на каждого агента; реестры групп/каталогов оттачивают людей и служебные учётные записи.

Честные ограничения

Заголовок раздела «Честные ограничения»
  • Community включает SSO с одним IdP. Маршрутизация между несколькими IdP и сопоставление групп при входе предоставляет соответствующий закрытый модуль идентификации. Общее управление пользователями, группами и разрешениями остаётся доступным в Community.
  • Реестр не может починить общие учётные данные. Он может лишь честно сообщить вам, что учётные данные являются общими.
  • SCIM — это входящий провижининг — control plane не отправляет личности обратно в ваш IdP, а приёмник Security-Event-Token является входящей поверхностью, а не исходящим webhook.

Связанное

Заголовок раздела «Связанное»