OCI IAM with Identity Domains

解決する課題

• OCI コンソールへのログインと業務アプリへのログインを別々の ID 基盤で管理したくない → 一つの ID 基盤に集約したい
• 管理者やユーザーに**多要素認証（MFA）**を強制し、パスワードだけのログインをやめたい
• 既存の社内 IdP（Microsoft Entra ID など）の ID を OCI でも使い、重複したアカウント管理をなくしたい
• 組織・環境・顧客テナントごとに ID 空間を分離し、ユーザーやポリシーが混ざらないようにしたい
• SaaS や自社アプリへのログインを **SSO（シングルサインオン）**でまとめ、利用者のパスワード数を減らしたい

主要概念と用語

• アイデンティティドメイン（Identity Domain）: ユーザー・グループ・認証設定・アプリ登録を束ねる ID 空間の入れ物。OCI に内蔵された IDaaS であり、旧 Oracle Identity Cloud Service（IDCS）の後継。テナンシ内に複数作成できる
• Default ドメイン: テナンシ作成時に自動で用意されるドメイン。OCI コンソール／API の認証に使われる既定の ID 空間
• ユーザー / グループ: ドメインに属する ID と、その束。OCI の権限（IAM ポリシー）はこのグループに対して付与する
• サインオンポリシー（Sign-On Policy）: 誰が・どんな条件でサインインを許可／拒否されるか、MFA を要求するかを定義するルール
• MFA（多要素認証）: パスワードに加えて認証アプリ・FIDO・SMS などの第二要素を要求する仕組み。ドメイン単位で方式を有効化する
• フェデレーション（Federation）: 外部 IdP に認証を委ねる連携。SAML 2.0 / OpenID Connect に対応し、社内の認証基盤に ID を寄せられる
• アプリ（Application）: ドメインに登録する SSO 対象のアプリケーション。OAuth/OIDC クライアントや SAML サービスプロバイダーとして構成する
• プロビジョニング / SCIM: 外部システムとユーザー情報を同期する仕組み。SCIM 標準でユーザーの作成・更新・削除を自動連携する
• ブランディング: サインイン画面のロゴ・配色・文言などをドメインごとにカスタマイズする設定

仕様・制限・クォータ

• アイデンティティドメインは OCI IAM の一部であり、ドメインに属するユーザー・グループに対して IAM ポリシーで OCI リソースのアクセス権を付与する。「ID の管理」と「OCI の認可」は連動している
• テナンシには Default ドメインが必ず存在し、追加で複数ドメインを作成できる。各ドメインは独立した ID 空間で、ユーザー・グループ・サインオンポリシーを共有しない
• ドメインには**タイプ（機能レベル）**があり、OCI 操作向けの基本機能を提供する無償タイプと、外部アプリ SSO や大規模 ID 管理などを含む上位タイプに分かれる。利用できる機能と課金はタイプに依存する
• フェデレーションは SAML 2.0 と OpenID Connect に対応し、Microsoft Entra ID・Okta・Active Directory フェデレーションなど外部 IdP と連携できる
• 認証連携の標準として OAuth 2.0 / OIDC / SAML / SCIM をサポートし、アプリ SSO とユーザープロビジョニングを標準プロトコルで構成する
• ドメインは作成時にリージョンを持つ。利用形態に応じて他リージョンへレプリケーションする運用が可能だが、対応範囲はドメインタイプにより異なる
• ユーザー数・アプリ数・グループ数などにはサービス上限があり、ドメインタイプやテナンシ既定で異なる。具体値は変動するため公式ドキュメントで都度確認する

内部の仕組み

アイデンティティドメインは、認証（ユーザーが本人か）と ID 管理（誰がどのグループに属するか）を担い、OCI IAM の認可エンジンと連携します。ユーザーが OCI コンソールやアプリにサインインしようとすると、ドメインはサインオンポリシーを評価し、対象ユーザー・ネットワーク・デバイスなどの条件に応じてサインインの許可・拒否・MFA 要求を決定します。

外部 IdP とフェデレーションしている場合、ドメインは自前でパスワードを検証せず、SAML アサーションや OIDC トークンを外部 IdP から受け取って本人性を確認します。SSO 対象のアプリに対しては、ドメインが IdP（または認可サーバー）として振る舞い、OIDC のトークンや SAML アサーションを発行してアプリへのログインを成立させます。SCIM によるプロビジョニングが構成されていれば、ユーザーの作成・更新・無効化が外部システムと自動同期されます。

認証が済んだユーザーが OCI リソースを操作するときは、所属グループに紐づく **IAM ポリシー（Allow 文）**が評価され、許可された操作だけが通ります。つまりドメインが「誰か」を確定し、IAM ポリシーが「何をできるか」を決める分担です。

設計パターン / ベストプラクティス

• ドメインで ID 空間を分離: 本番と検証、社内向けと顧客向け（B2B/B2C）など、混ぜたくない ID 集合は別ドメインに分ける。ユーザーもサインオンポリシーも分離される
• 管理者には MFA を必須化: 特権ユーザーのサインオンポリシーで MFA を強制し、認証アプリや FIDO などフィッシング耐性の高い要素を優先する
• 権限はグループに、人は直接持たせない: OCI の権限はグループ単位で IAM ポリシーから付与し、人の入れ替えはグループのメンバー変更で対応する
• 既存 IdP にフェデレーション: 社内に Entra ID 等があるなら SAML/OIDC で連携し、人の ID とパスワードを社の認証基盤に一元化する
• SCIM で自動プロビジョニング: 入退社に合わせてユーザーの作成・無効化を自動化し、休眠アカウントの放置を防ぐ
• アプリ SSO の集約: 自社アプリや SaaS をドメインのアプリとして登録し、利用者のパスワード数とログイン手間を減らす

運用・監視

• ドメインの認証・管理操作は OCI Audit に記録され、誰がいつサインイン設定やユーザーを変更したかを追跡できる
• ドメインはサインインの成否やユーザーアクティビティのレポートを持ち、不審なログインやロックアウトの傾向を確認できる
• サインインに失敗する場合は、サインオンポリシーの条件・MFA 登録状況・フェデレーション連携先（IdP）の状態の順に切り分ける
• 外部 IdP 連携では、証明書やメタデータの有効期限を監視し、期限切れによる一斉ログイン不能を防ぐ
• ユーザーやグループの増減、休眠アカウントを定期棚卸しし、SCIM 連携の整合性を点検する

コスト

アイデンティティドメインは OCI 操作のための認証認可（基本機能・MFA・基本フェデレーション）が追加料金なしで使える無償タイプを持ちます。外部アプリの SSO や大規模 ID 管理などの高度な機能を使う上位タイプは、ユーザー規模に応じた課金になります。

正確な料金体系はドメインタイプ・ユーザー数・リージョンで変動するため、見積もりは公式の料金情報で確認してください。

セキュリティ

• MFA を強制: サインオンポリシーで多要素認証を必須化し、特に管理者にはフィッシング耐性の高い要素を優先する
• 条件付きアクセス: サインオンポリシーで送信元ネットワークやデバイスの条件を設定し、想定外の場所からのサインインを抑止する
• フェデレーションで認証を一元化: 外部 IdP に認証を寄せ、ID とパスワードの管理点を一つにしてアカウントの分散を防ぐ
• 最小権限のグループ設計: ドメインのグループに対して IAM ポリシーで必要最小限の権限だけを与え、過剰な管理権限を避ける
• 監査と棚卸し: OCI Audit でサインイン設定の変更を追跡し、休眠アカウントや過剰権限を定期的に見直す

関連サービス・比較

最も近い関連サービスは OCI IAM のポリシーエンジンです。アイデンティティドメインが「誰か（認証・ID 管理）」を担い、IAM ポリシーが「何をできるか（認可）」を担う、という分担関係にあります。

他クラウドで例えると、アイデンティティドメインは Microsoft Entra ID や AWS IAM Identity Center に近い ID 基盤で、SSO・MFA・フェデレーションを担います。OCI ではこれが IAM に内蔵され、OCI リソースへの認可（Allow ポリシー）とシームレスに連動する点が特徴です。

ハンズオン / CLI例

# 1) テナンシ内のアイデンティティドメイン一覧を確認
oci iam domain list \
  --compartment-id $OCI_TENANCY

# 2) 新しいドメインを作成（用途や組織ごとに ID 空間を分離）
#    --license-type にはドメインのタイプ（機能レベル）を指定する
oci iam domain create \
  --compartment-id $OCI_TENANCY \
  --display-name partner-b2b \
  --description "Identity domain for partner B2B users" \
  --home-region-url $DOMAIN_HOME_REGION_URL \
  --license-type "premium"

# 3) ドメインのエンドポイント（管理 URL）を確認
oci iam domain get \
  --domain-id $DOMAIN_OCID

# 4) ドメイン内のユーザーは Identity Domains 専用 API で管理する
#    （SCIM ベースの users エンドポイント）
oci identity-domains user list \
  --endpoint $DOMAIN_URL

# 5) ドメイン内にグループを作成（OCI 権限はこのグループへ IAM ポリシーで付与）
oci identity-domains group create \
  --endpoint $DOMAIN_URL \
  --display-name app-readers \
  --schemas '["urn:ietf:params:scim:schemas:core:2.0:Group"]'