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

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

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

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

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

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

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

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

/v1/scim/v2/Users
/v1/scim/v2/Groups

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

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

Источники реестров питают инвентарь личностей модуля 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 и им подобные) — это твёрдый сигнал на каждого агента; реестры групп/каталогов оттачивают людей и служебные учётные записи.

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

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

Связанное

• Подключить источник — почему личность является жёсткой зависимостью.
• Управлять и одобрять — роли, RBAC и что даёт mapped_role.
• Коннекторы и уровни покрытия — полный список источников личности (Vault, Infisical, Keycloak, SPIFFE, виды федерации личности агентов).