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

業務においてSAML認証の理解が必要かもしれないとなったのでAWSとトラスト・ログインを利用してSAML認証を検証してみたいと思います。
AWSがSP (Service Provider：サービスプロバイダー)、トラスト・ログインがIdP (Identity Provider：アイデンティティプロバイダー)の役割となります。
トラスト・ログインで認証されたらAWSコンソールへサインインできる、IdP Initiated（IdP開始型）の動きを確認します。

GMO トラスト・ログイン社の記事を参考にさせていただきました。

AWS IAM のSAML認証の設定方法（GMO トラスト・ログイン） https://support.trustlogin.com/hc/ja/articles/900002447206-AWS-IAM-%E3%81%AESAML%E8%AA%8D%E8%A8%BC%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%96%B9%E6%B3%95

　　　

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 へリダイレクトされる方式です。
　認証の流れ：
　　1. ユーザー　→　SP（AWS など）にアクセス
　　2. SP が「この人は未認証」と判断して IdP にリダイレクト
　　3. IdP で認証　→　SAML アサーションを SP に返す　→　ログイン完了

　　　

AWSとトラスト・ログインでにおけるSAML認証のいろいろ

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

・SAML 認証で AWS にログインするのは「IAM ユーザー」ではなく「IAM ロール」
そのため「AWS にユーザーを事前に作成しておく必要はありません。
SAML認証でログインするときは「IdP 側のユーザー」と「AWS 側の IAM ユーザー」はまったく別物として扱われます。
　
・AWSのユーザーと同名のユーザーをIdP側（トラスト・ログイン）に作成し、SAML認証したら？
SAML認証でログインするときは「IdP 側のユーザー」と「AWS 側の IAM ユーザー」は別物として扱われます。
そのため、IdP側（トラスト・ログイン）の同名ユーザーでSAML認証によってAWSへログインしてもAWSのユーザーと同じ権限は付与されません。まったく別物扱いのためです。
　
・SAML認証のためにAWSで作成するIAMロール、IAMポリシーの用途について
「SAML ログインできるかどうか」は信頼ポリシー、すなわちIAMロールを作成する時の「信頼されたエンティティ」で決まります。IAMロール作成後「信頼関係」タブで確認できます。
「ログイン後に何ができるか」は権限ポリシーで決まり、すなわちIAMポリシー「Administrator Access」や「AmazonEC2FullAccess」です。IAMポリシーを作成して信頼ポリシーだけで他は設定しないとSAML認証後は、AWSコンソールへログインするだけとなります。

　　　

トラスト・ログイン_管理者アカウント作成

トラスト・ログインで無料アカウントを作成すればSAML認証を試すことができます。
※画像は、2025年9月時点のもので変更される可能性がありますのでご了承ください

https://trustlogin.com/　へアクセスして「お問い合わせ」をクリックします。

「無料登録はこちら」をクリックします。

必要な情報を入力、利用約款のリンクを開き、「確認画面へ」をクリックします。

次の画面で「登録する」をクリックします。

ログイン画面が表示されるので認証後、ログインできました。

　　　

トラスト・ログイン_検証ユーザー作成

事前に検証ユーザーを作成しておきます。検証ユーザーは「testuser01」とし、AWSには存在していないユーザーです。
検証ユーザー「testuser01」をSAML認証させてAWSへログインする想定です。
ログオンした画面で「管理」をクリックします。

ダッシュボード画面で「追加」をクリックします。

「個別追加」をクリックします。

お名前、メールアドレスを入力し、「次へ」をクリックします。
メールアドレスは、パスワード入力画面のURLが送信されてくるので実際に利用しているメールアドレスを入力する必要があります。

内容を確認し、「登録」をクリックします。

登録したメールアドレス宛てへパスワード設定URLが送信されるのでパスワードを設定します。
作成したユーザーでログインできることを確認します。
一般ユーザーで権限がないので「管理」アイコンは表示されていません。

　　　

トラスト・ログイン_アプリ登録

トラスト・ログインでSAML認証用のアプリを登録します。
管理者でトラスト・ログインにログイン、管理 > アプリを選択し、画面右上の「アプリ登録」ボタンをクリックします。。

検索ウィンドウで「aws」を入力してEnterをクリック、表示された「AWS IAM (SAML)」アイコンをクリックします。

「IDプロバイダーの情報」 の「メタデータをダウンロード」よりメタデータをダウンロードします。

xmlファイルがダウンロードされます。この後、AWSコンソールへアップロードします。

メタデータのダウンロードが完了したら、次はAWSコンソール側の作業に移ります。
トラスト・ログイン画面は閉じずにこのままで別ウィンドウでAWSコンソールを開きます。

　　　

AWS_IDプロバイダーの作成

管理者ユーザーでAWSコンソールへログインします。
「IAM」を開き、左ペインの「IDプロバイダー」を選択、「プロバイダを追加」をクリックします。

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

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

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

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

　　　

AWS_ロールの作成

管理者ユーザーでAWSコンソールへログインします。
「IAM」を開き、左ペインの「ロール」を選択、「ロールを作成」をクリックします。

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

SAML 2.0 フェデレーションで、以下のとおり設定します。

SAML プロバイダー：事前に作成したプロバイダーを選択
許可されるアクセス：プログラムと AWS マネジメントコンソールへのアクセスを許可する

サインインエンドポイントは、以下のとおり設定します。

サインインエンドポイントタイプ：非リージョンレベルのエンドポイント
一意の識別子を含めるサインイン URL：デフォルト（一意の識別子付き）

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

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

ロールが作成されました。
「信頼されたエンティティ」を編集したいので作成したロールを選択して開きます。
なぜ編集するかと言いますと実際に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認証がうまくいきました。後述の記事を参照ください）

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

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

IAMロールの画面で上部の「ロールARN」を控えておきます。

次は、トラスト・ログインの設定ページに戻ります。

　　　

トラスト・ログイン_SAML属性の設定

トラスト・ログイン画面に戻り、先ほどメタデータをダウンロードした画面を下へスクロールします。
ここは確認だけで下へスクロールします。

サービスプロバイダーの設定は、デフォルトのままとします。

SAML属性の設定で属性値を入力します。デフォルトでは以下のとおり日本語（ロールのARN,・・・）が入力されています。

赤枠に事前にAWSで控えておいた「ロールのARN」と「プロバイダのARN」を「,」で区切った「ロールのARN,プロバイダのARN」の形式で入力します。
私の場合は、以下となります。
※数値は変更しています、ご自身の環境に合わせて変更してください

画面上部までスクロールし、「登録」ボタンで保存します。

登録されました。
アプリ登録はできましたが、このアプリを利用するメンバーがまだ誰も登録されていないことが確認できます。

　　　

トラスト・ログイン_アプリへユーザーを追加

作成したアプリ「AWS IAM(SAML)」を利用するユーザーを追加します。
アプリ名をクリックします。

右上の「メンバー追加」をクリックします。

一番最初に作成した「testuser01」を選択し、「登録」をクリックします。

「メンバー」タブを選択すると「testuser01」が登録されていることが確認できます。

「一般設定」タブへ移動し、「ログインURL」を控えておきます。

　　　

トラスト・ログイン_SAML認証実施

トラスト・ログイン、AWSコンソールともに、いったんログアウトしておきます。
アクセスするURLによって画面遷移が異なるので２パターン検証してみます。
　・パターン１：IdPログイン後にSPを指定せず、いっきにSPへログインする
　・パターン２：IdPログイン後にSPを選択してからSPへログインする

　　　

パターン１：IdPログイン後にSPを指定せず、いっきにSPへログインする

最初から「AWS アプリを開く」ことが目的のURLであるため、トラスト・ログインへログインすると即座に SAML アサーションが発行され、AWS にリダイレクトされます。

ブラウザで以下へアクセスします。 https://portal.trustlogin.com/trustlogin2025/idp/294977/saml/auth

以下のURLへリダイレクトされます。
https://portal.trustlogin.com/users/sign_in

testuser01のメールアドレスを入力し、ログインをクリックします。
（無料プランでは、ログインIDを入力してログイン処理ができないようなのでメールアドレスを入力しています）

パスワードを入力し、ログインをクリックします。

AWSへログインできました！
アカウント名の箇所も「IAMロール名／トラスト・ログインアカウント名」になっています。

EC2インスタンスを起動画面も開けてエラーなど表示されてないので、IAMポリシー「AmazonEC2FullAccess」が適用されていることが確認できます。

ちなみにIAMを表示すると「アクセス拒否」が表示されました。

　　　

パターン２：IdPログイン後にSPを選択してからSPへログインする

ブラウザで以下へアクセスします。
https://portal.trustlogin.com/

testuser01のメールアドレスを入力し、ログインをクリックします。
（無料プランでは、ログインIDを入力してログイン処理ができないようなのでメールアドレスを入力しています）

パスワードを入力し、ログインをクリックします。

いったんトラスト・ログインが表示されます。
画面の灰色の箇所をクリックします。

AWSのSAML認証用アイコンが表示されているのでクリックします。

AWSへログインできました！
アカウント名の箇所も「IAMロール名／トラスト・ログインアカウント名」になっています。

　　　

まとめ

AWSとトラスト・ログインを利用してSAML認証を検証しました。実際に設定して動作確認することで理解を深めることができました。皆様の参考になれば幸いです。　　　

　　　

記事一覧