【OCI_16】OCI IAM Identity DomainsでAWSとSAMLでの認証連携を実施

2025/10/29

この記事を書いている人 - WRITER -

ブログ運営者のtkjzblogです。仕事柄新しいシステムに触れることが多いです。 Windows、Linux（RHEL）がメインです。その他、VMwareやOffice365など仮想環境やクラウド環境も少しですが触れることがあります。いろいろ忘れがちのため、このサイトへ情報を書き溜めていきたいと思います。どうぞ、よろしくお願い致します。

OCI IAM Identity Domains と AWS でSAML認証連携（SP Initiate）を設定してみます。
役割としては、OCI IAM Identity DomainsがIdPでAWSがSPとなります。
AWS側にユーザーが存在していなくてもOCI側のユーザーでAWSへサインインできるという感じです。

OCIとは関係ないですが、以前AWSとトラスト・ログインでSAML認証連携を検証してみましたので興味のある方は、以下の記事を参照ください。

【AWS_52】AWSとトラスト・ログインを利用してSAML認証を検証する

以下OCIチュートリアルを参考に検証しています。ただ、情報が少し古いのか今の画面構成と異なる箇所が多数あります。

OCI IAM Identity DomainsとAWSとの認証連携設定手順
https://speakerdeck.com/oracle4engineer/oci-iam-identity-domainstoawstonoren-zheng-lian-xi-she-ding-shou-shun?slide=2

1 SAML認証とは
2 事前確認
3 OCI IAM Identity Domains でSAMLアプリケーションを作成
4 OCI IAM Identity Domains でメタデータを取得
5 AWSでIDプロバイダ（SP）を作成
6 AWSでIAMロールを作成
7 OCI IAM Identity Domains で属性構成を登録
8 動作確認
9 まとめ

SAML認証とは

概要

・SAML (Security Assertion Markup Language) は、異なるサービス間でシングルサインオン (SSO) を実現するための標準規格です。
・ユーザーが一度ログインすれば、別のサービスにも再ログインなしで入れる仕組みを提供します。
・SAML認証は、「ユーザー認証をIdPに任せ、SPはその証明を信頼する仕組み」で、これによりシングルサインオンが実現し、利便性とセキュリティが両立できるようになります。

登場人物

・IdP (Identity Provider：アイデンティティプロバイダー)
　　ユーザーを認証する側
　　例：トラスト・ログイン、Okta、Azure ADなど

・SP (Service Provider：サービスプロバイダー)
　　IdP で認証されたユーザーを受け入れてサービスを提供する側
　　例：AWS、Dropbox、Google Workspaceなど

「IdP Initiated」と「SP Initiated」

超ざっくり言うと最初にIdPへアクセスして認証を開始するか、SPへアクセスして認証を開始するかの違いです。

・IdP Initiated（IdP開始型）
ユーザーが最初に IdP（Identity Provider）にアクセスして認証し、その後に SP（Service Provider）に遷移する方式です。
　認証の流れ：
　　1. ユーザー　→　IdP にログイン
　　2. IdP が SAML アサーションを発行
　　3. ユーザーを SP（AWS など）へリダイレクト　→　ログイン完了

・SP Initiated（SP開始型）
ユーザーが最初に SP（Service Provider）にアクセスし、そこから IdP へリダイレクトされる方式です。
　認証の流れ：
　　ユーザー　→　SP（AWS など）にアクセス
　　SP が「この人は未認証」と判断して IdP にリダイレクト
　　IdP で認証　→　SAML アサーションを SP に返す　→　ログイン完了

AWSとOCIにおけるSAML認証のいろいろ

わたしが検証する前に疑問に思っていたことを調べたメモとなります。

・SAML 認証で AWS にログインするのは「IAM ユーザー」ではなく「IAM ロール」
そのため「AWS にユーザーを事前に作成しておく必要はありません。
SAML認証でログインするときは「IdP 側のユーザー」と「AWS 側の IAM ユーザー」はまったく別物として扱われます。

・AWSのユーザーと同名のユーザーをIdP側（OCI）に作成し、SAML認証したら？
SAML認証でログインするときは「IdP 側のユーザー」と「AWS 側の IAM ユーザー」は別物として扱われます。
そのため、IdP側（OCI）の同名ユーザーでSAML認証によってAWSへログインしてもAWSのユーザーと同じ権限は付与されません。まったく別物扱いのためです。

・SAML認証のためにAWSで作成するIAMロール、IAMポリシーの用途について
「SAML ログインできるかどうか」は信頼ポリシー、すなわちIAMロールを作成する時の「信頼されたエンティティ」で決まります。IAMロール作成後「信頼関係」タブで確認できます。
「ログイン後に何ができるか」は権限ポリシーで決まり、すなわちIAMポリシー「Administrator Access」や「AmazonEC2FullAccess」です。IAMポリシーを作成して信頼ポリシーだけで他は設定しないとSAML認証後は、AWSコンソールへログインするだけの権限しかありません。

事前確認

AWSの環境へ管理者でサインインできることを前提としています。

OCI IAM Identity Domains でSAMLアプリケーションを作成

今回、OCIのドメイン「testdomain」にSAMLアプリケーションを作成して「testdomain」のユーザーでSAML認証してみたいと思います。
※ユーザー名は、マスクしています

AWSとSAML認証を構成するためにSAMLアプリケーションを作成するため、OCIの全体管理者でサインインします。
左上ハンバーガーメニューからアイデンティティとセキュリティ > ドメインを選択し、AWSと認証連携したいドメインを選択します。

「統合アプリケーション」タブを選択し、「アプリケーションの追加」をクリックします。

アプリケーションの追加で「SAMLアプリケーション」を選択し、「ワークフローの起動」をクリックします。

SAMLアプリケーションの追加で以下を入力、選択します。

　名前：任意名
　説明：任意名
　アプリケーション・リンクの追加：ON（デフォルト）

URLは、何も入力していません。

表示設定、認証と認可で以下を設定します。
　「自分のアプリケーション」に表示：ON
　ユーザーにアクセス権のリクエストを許可：ON
　権限付与を認可として実施：ON（デフォルト）

タグは何も設定せず、右下の「送信」をクリックします。
※「次の手順」にもあるとおり、SSOを構成していく流れになります。

作成したSAMLアプリケーションのページに遷移するので「SAML SSO構成」タブを選択し、「SSO構成の編集」をクリックします。

SSO構成の編集で以下を入力、選択し、画面を下へスクロールします。
　エンティティID：https://signin.aws.amazon.com/saml
　アサーション・コンシューマのURL：https://signin.aws.amazon.com/saml
　名前IDフォーマット：永続
　名前IDの値：プライマリ電子メール（デフォルト）

追加構成で「シングル・ログアウトの有効化」を無効（OFF）にします。それ以外はデフォルトのままとし、右下の「変更の保存」をクリックします。

念のため、シングル・ログアウトを無効化してよいかchatgptへ聞いたところ、シングル・ログアウトを「無効」にして問題ないとの回答でした。
理由は、AWS公式ドキュメントでも、SAMLログアウトには非対応で、IdPがシングル・ログアウトを要求してもSP側が応答できない構成とのことですのでシングル・ログアウトを無効化するのが実運用でも検証でも正解とのことでした。

SAMLアプリケーションのSAML SSOが構成されました。

OCI IAM Identity Domains でメタデータを取得

作成したSAMLアプリケーションをアクティブ化してメタデータを取得します。メタデータはAWS側で利用します。

左上ハンバーガーメニューからアイデンティティとセキュリティ > ドメインを選択し、AWSと認証連携したいドメインを選択します。
「統合アプリケーション」タブを選択、作成したSAMLアプリケーション名の右側のトリコロンを展開、「アクティブ化」をクリックします。

「アプリケーションのアクティブ化」をクリックします。

SAMLアプリケーションが「アクティブ」になりました。

SAMLアプリケーションをクリック、「SAML SSO構成」タブを選択し、「アイデンティティ・プロバイダ・メタデータ」の「ダウンロード」をクリックします。

ブラウザが警告を表示した場合は、「保存」をクリックしてダウンロードします。

xmlファイルがダウンロードされました。
Identity Domains のメタデータ取得は、以上となります。

AWSでIDプロバイダ（SP）を作成

AWS側でIDプロバイダ（SP）を作成していきます。

管理者でサインインし、「IAM」をクリックします。

左ペインの「IDプロバイダー」を選択、「プロバイダを追加」をクリックします。

ID プロバイダーを追加画面で以下を選択、入力、メタデータをアップロードします。

プロバイダのタイプ：SAML
プロバイダ名：任意名（今回は ocilogin としました）
メタデータドキュメント：先ほどOCIのSAMLアプリケーションからダウンロードしたメタデータをアップロードします
画面右下の「プロバイダーを追加」をクリックします。

作成されたIDプロバイダー名をクリックします。

「プロバイダのARN」を控えておきます。

AWSでIAMロールを作成

SAML 認証で AWS にログインするのは「IAM ロール」です。
次はそのIAMロールを作成していきます。引き続き管理者で作業します。

「IAM」を開き、左ペインの「ロール」を選択、「ロールを作成」をクリックします。

信頼されたエンティティを選択は、「SAML 2.0 フェデレーション」を選択します。

SAML 2.0 フェデレーションで、以下のとおり設定します。
　SAML プロバイダー：事前に作成したプロバイダーを選択
　許可されるアクセス：プログラムと AWS マネジメントコンソールへのアクセスを許可する

サインインエンドポイントは、以下のとおり設定して、「次へ」をクリックします。
　サインインエンドポイントタイプ：非リージョンレベルのエンドポイント
　一意の識別子を含めるサインイン URL：デフォルト（一意の識別子付き）

今回、SAML認証でログインしたユーザーはEC2インスタンスが作成できるようになっていてほしいので、ここで「AmazonEC2FullAccess」をアタッチしたいと思います。
検索ウィンドウで「AmazonEC2FullAccess」を入力し、表示されたポリシー名の左側にチェックを入れて「次へ」をクリックします。

名前、確認、および作成画面で任意のロール名を入力し、その他はデフォルトのままで「ロールを作成」をクリックします。
ロール名は「20251027_oci_saml」としました。

ロールが作成されました。
「信頼されたエンティティ」を編集したいので作成したロールを選択して開きます。
なぜ編集するかと言いますと以前AWSとトラスト・ログインのSAML認証を検証した際、編集せずに進めると認証に失敗したからです。ここの時点で修正しておく必要がありました。

「信頼関係」タブを選択し、「信頼ポリシーを編集」をクリックします。
「SAML:aud」行を編集します。

chatgptに尋ねると「”SAML:aud” の値が https://signin.aws.amazon.com/saml/acs/… になっています。」、「正しくは AWS ドキュメント通りに https://signin.aws.amazon.com/saml でなければいけません。」でした。

aud（Audience）は「このアサーションを誰向けに発行したか」を表すフィールドでAWS が期待している値は固定で https://signin.aws.amazon.com/saml です。
いま設定されている ACS URL は、サインインエンドポイント用の URL であって、audience ではありません。」とのことでした。

以下のとおり編集したら「ポリシーを更新」をクリックします。

　編集前：　”SAML:aud”: “https://signin.aws.amazon.com/saml/acs/SAMLSPV8N7M510NDABBISX”
　編集後：　”SAML:aud”: “https://signin.aws.amazon.com/saml”