SSO、SCIM、アイデンティティソース（確かな帰属）

アイデンティティはアクセスマップ全体の根底にある厳しい依存関係だ: ネイティブ監査はアクセスをクレデンシャルに帰属させるが、そのクレデンシャルを エージェントまたは人に結びつけられるのはアイデンティティロスターだけだ。このページでは 3 つのアイデンティティの面を配線する: コンソールの SSO ログイン、コントロールプレーンへの SCIM プロビジョニング、そして帰属を approximate ではなく attributed にするロスターソース （LDAP、Okta、Entra ID）だ。

1. コンソール SSO（OIDC / SAML）

フェデレーテッドログインはエンジンのフェデレーションシームを通じて提供される。態勢は構成上、正直だ:

ログインフローのエンドポイントはすべてのビルドに存在し、エンジンは秘密を含むすべてのフロー値をサーバー側に保持する——CSRF state、OIDC nonce、 PKCE verifier（プロバイダーに送られるのは S256 challenge のみ）。 Authorization Code + PKCE は常時オンだ。
単一 IdP による OIDC/SAML ログインはすべてのエディションで利用できる（Community を含む）。 コンソールの管理対象 SSO 設定で構成する。管理対象の設定がない場合、エンジンは起動時の環境変数（OLIVARES_SSO_PROTOCOL、OLIVARES_OIDC_* または OLIVARES_SAML_*）を使用する。プロバイダーが未設定なら、NoFederation が 501 sso_not_configured を返す。これは設定がないことを示し、プロトコルが商用エディション専用であることを意味しない。
IdP が持つべきリダイレクト/ACS URI は厳密だ（コンソールオリジン上の …/v1/auth/federation/callback ——RFC 9700 の厳密一致、プレフィックスの小細工は不可）。

コンソールの Identity & NHI → SSO & SCIM タブはライブ構成を文書化し、 IdP のリダイレクト URI を厳密に期待される値と照合し、接続状態を表示する—— そして、あるパネルのバックエンドが宣言された契約でまだ稼働していない場合、捏造データをレンダリングするのではなく「backend pending」と表示する:

Identity & access ビュー: ユーザーとグループ、SSO サインイン、マシンアイデンティティ(NHI)、鍵の態勢。

2. SCIM プロビジョニング（インバウンド） — Business

インバウンド SCIM サーバーは Business（Identity & Scale）の機能である。Community のサーバーは同じ URL をマウントし、トークンを認証したうえで、Business を名指しした SCIM エラー形式の HTTP 501 を返す。読み取りも書き込みも行われない。Community では、コンソール（ユーザー）または DELETE /v1/members/{id} で組織から個人を削除する。

Business では、コントロールプレーンは、次のエンドポイントで標準的な SCIM 2.0（RFC 7644）サービスプロバイダーとして機能する:

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

認証: SCIM 連携に対するテナント束縛の管理者/オーナー API トークン ——API の他の部分と同じ不透明トークンモデルであり、別個の SCIM シークレット型はない。URL は常にマウントされている（フィーチャーゲートされない）。Community ではそこで 501 を返す。
Users は ID をプロビジョニングおよび解除する。変更の反映には SCIM リクエストの配信と正常な処理が必要となる。人事イベントだけで失効の完了を判断せず、応答と対象のアクセス権を確認する。SCIM は OS のアカウントを削除しない。
Groups はアイデンティティ対グループの参照データを運ぶ。各グループは mapped_role を介してコントロールプレーンのロールにマッピングできる—— そしてそのマッピングはオペレーター所有だ: コントロールプレーン側で設定され、監査される（scim.group.role.map）。IdP のプッシュがロールを無言で昇格させることはない。プッシュされたグループ内の未知のメンバーはスキップされ、かつ監査される——捏造されることはない。

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 kind は provider: okta（api_token 付き）または provider: entra（tenant_id / client_id / client_secret 付き）を取る。okta と entra は kind として直接機能させることもできる。

これがどのように帰属を格上げするか——正確に

ロスターソースはアイデンティティを（external id で）登録し、ディレクトリが宣言している場合は許可されたグラントも登録する。観測されたエッジの起点が 非共有のロスターアイデンティティに一致すると、モジュール III はアクセスをそのアイデンティティに結びつけ、エッジの信頼度は attributed に格上げされる。複数のワークロードが共有するアイデンティティは正直に approximate のまま残る ——ロスターはクレデンシャルの共有を解消できない。それができるのはエージェントごとのアイデンティティを発行することだけだ（ガバナンスへの橋渡し）。

専用のエージェントアイデンティティおよびワークロードアイデンティティの kind （エージェントフェデレーションソース——Entra Agent ID、AgentCore、SPIFFE および同種のもの）は、確かなエージェントごとのシグナルだ。グループ/ディレクトリのロスターは人とサービスアカウントを鋭くする。

正直な限界

Community は単一 IdP の SSO を含む。 複数 IdP のルーティングとログイン時のグループマッピングは、対応する非公開の ID モジュールが提供する。一般的なユーザー、グループ、権限の管理は Community でも利用できる。
ロスターは共有クレデンシャルを修正できない。 クレデンシャルが共有されていることを正直に告げることだけができる。
SCIM はインバウンドプロビジョニングだ ——コントロールプレーンはアイデンティティを IdP に押し返さず、Security-Event-Token レシーバーはアウトバウンド webhook ではなくインバウンドの面だ。