IdP / SSO / SAML / 証明書 / AWS IAM の関係について

2026年5月27日2026年6月7日

IdP / SSO / SAML / 証明書 / AWS IAM の関係についてしっかりと把握できるよう詳しく解説します。試験にも結構出てきます。しかし一夜漬けの暗記だけでは、複雑に補完し合う認証周りの構成が把握できず何度も不明な状態になります。

登場人物

まずは登場人物を3つに分けると理解しやすいです。

ユーザー　…　AWS にログインしたい人
IdP　…　ユーザーを認証する場所
AWS　…　IdP の認証結果を信じてログインを許可する場所

詳しい全体の流れ

流れはこうです。

1. ユーザーが AWS コンソールにアクセスする

2. AWS はユーザーがログイン済みか確認する

3. 未ログインなので、AWS は IdP に認証を依頼する
   ここで SAML 認証リクエスト、つまり AuthnRequest が作られる

4. ユーザーのブラウザは IdP のログイン画面に移動する

5. ユーザーは IdP に ID・パスワード・MFA でログインする

6. IdP はユーザーを認証する
   さらに、そのユーザーに AWS アクセス権があるか確認する

7. IdP は SAML 応答を作る
   中には、ユーザー情報、認証結果、利用可能な IAM ロールなどが含まれる

8. IdP は SAML 応答に秘密鍵で署名する

9. ユーザーのブラウザ経由で、署名付き SAML 応答が AWS に送られる

10. AWS は IAM の SAML ID プロバイダー設定を見る

11. AWS はそこに登録されている SAML メタデータ内の証明書で、
    SAML 応答の署名を検証する

12. 署名、有効期限、宛先、ロール情報などが正しければ、
    AWS は SAML 応答を信頼する

13. AWS STS が AssumeRoleWithSAML により、
    指定された IAM ロールの一時クレデンシャルを発行する

14. AWS コンソール用のログインセッションが作られる

15. ユーザーは AWS コンソールにログイン成功する

登場人物と役割

もの	どこにあるか	何をするか
ユーザー	人	AWS コンソールにログインしたい人
ブラウザ	ユーザーのPC	AWS と IdP の間を移動し、SAML 応答を AWS に渡す
AWS コンソール	AWS 側	ユーザーが最終的に使いたい画面
IdP	AWS の外部	ユーザーを認証して、SAML 応答を発行する
SAML 認証リクエスト	AWS → IdP	AWS から IdP への「この人を認証してください」という依頼
SAML 応答	IdP → AWS	IdP から AWS への「この人は認証済みです」という返答
署名	SAML 応答の中	SAML 応答が本物で改ざんされていないことを証明する
SAML メタデータ	IdP から取得し AWS に登録	IdP の識別子、ログインURL、署名検証用証明書などが入ったXML
AWS IAM の SAML ID プロバイダー	AWS IAM 側	AWS 側に登録された「この IdP を信頼する」という設定
IAM ロール	AWS IAM 側	SSO 後にユーザーが使う AWS 権限の入れ物
IAM ロールの信頼ポリシー	IAM ロール側	「誰がこのロールを引き受けてよいか」を決める
IAM ロールの権限ポリシー	IAM ロール側	「このロールを使った人が AWS で何をしてよいか」を決める
AWS STS	AWS 側	`AssumeRoleWithSAML` により一時クレデンシャルを発行する
一時クレデンシャル	STS が発行	AWS コンソールや API を一時的に使うための認証情報

IdP とは何か？

IdP は Identity Provider の略です。ID プロバイダー と呼びます。簡単に言うと、ユーザーが本人であることを認証する側（システム）です。

たとえば以下が IdP になります。

Microsoft Entra ID
Okta
OneLogin
Google Workspace
Ping Identity
社内認証基盤

ユーザーは AWS に直接ログインするのではなく、まず IdP にログインします。認証は以下のイメージになります。

ユーザー
 ↓ ログイン
IdP（Okta / Entra ID など）
 ↓ 認証結果を AWS に渡す
AWS
 ↓
AWS マネジメントコンソールにログイン成功

AWS 側は、ユーザーのパスワードを直接知りません。しかし、AWS は IdP から渡された情報を見て、「この人は正しく認証された人だな」と判断します。

IdP の役割

IdP の役割は以下であるという情報を発行することです。IdP はログイン元・認証元です。

このユーザーは本人です
このユーザーはこのグループに所属しています
このユーザーには AWS のこのロールを使わせてよいです

ユーザーが IdP でログインするとどうなるか

最初にユーザーが IdP でログイン済みの状態になると以下のように進んでいきます。

1. ユーザーのブラウザには IdP のログイン状態がある

ユーザーが IdP に ID・パスワード・MFA でログインすると、IdP はブラウザにログイン状態を保持させます。多くの場合、これは Cookie です。

ユーザーのブラウザ
  ↓
IdP 用のログイン Cookie を持っている

この Cookie があるので、同じブラウザで別のサービスにアクセスしたときに、IdP はこう判断できます。

このブラウザのユーザーは、さっきログイン済みだな

そのため、AWS 以外の別サービスにアクセスしても、再度 ID・パスワードを求められないことがあります。これが SSO っぽく見える一番分かりやすい部分です。

2. IdP 側では「このユーザーは認証済みセッションを持っている」状態

IdP 側では、ユーザーのログインセッションが有効になっています。たとえばイメージとしては、以下のようなイメージです。

ユーザー: sasuke@example.com
認証状態: 成功
MFA: 済み
ログイン時刻: 10:00
セッション有効期限: 18:00
所属グループ: AWS-Admin, AWS-Developer

IdP はこの情報をもとに、「このユーザーは本人確認済み」「AWS 用の SAML 応答を発行してよい」と判断します。

3. IdP は AWS 向けの SAML 応答を発行する

AWS にログインするには、IdP が AWS 向けに SAML 応答を作ります。この SAML 応答には、ざっくり次の情報が入ります。

このユーザーは認証済みです
このユーザーはこの IAM ロールを使えます
この応答は AWS 向けです
この応答の有効期限はここまでです

そして IdP は、この SAML 応答に秘密鍵で署名します。

IdP
  ↓
SAML 応答を作成
  ↓
秘密鍵で署名

ここで初めて、AWS に対して「この人は認証済みです」と証明する材料ができます。このような流れで進んでいきます。

AWS IAM SAML ID プロバイダーとは

IdP だけでなく、AWS IAM の SAML ID プロバイダーもあります。AWS 側に作る設定です。これは実際にユーザーを認証するシステムではありません。AWS は直接パスワードを確認しているわけではありません。

AWS 側に以下を教えるための設定です。

この IdP から来た SAML 応答は信頼してよい
この IdP の署名は、この証明書で検証する

AWS IAM コンソールで作成する SAML プロバイダーは、いわば IdP の登録情報 です。何か処理を能動的に実行するサービスではありません。AWS が IdP を信頼するために保持している登録情報です。中には、IdP から取得した SAML メタデータが登録されています。

ユーザー
  ↓
Okta / Entra ID などの IdP
  ↓
SAML 応答を AWS に送る
  ↓
AWS が IAM に登録済みの SAML ID プロバイダー情報を見る
  ↓
署名が正しければログイン許可

IdP と AWS IAM SAML ID プロバイダーの違い

項目	IdP	AWS IAM の SAML ID プロバイダー
場所	AWS の外側	AWS IAM の中
実体	Okta、Entra ID などの認証基盤	IAM に作る設定リソース
役割	ユーザーを認証する	IdP を AWS 側で信頼する
SAML 応答	発行する側	検証に使われる側
秘密鍵	持つ	持たない
公開鍵/証明書	SAML メタデータに含めて提供する	SAML メタデータとして登録される
ユーザー認証	する	しない

SAML とは何か

SAML は、SSO を実現するための認証連携の仕組みです。正式には、Security Assertion Markup Language と言います。難しく言うと、IdP と AWS の間で、認証情報を安全にやり取りするための標準規格です。簡単に言うと、IdP が「このユーザーは認証済みです」と AWS に伝えるためのルールです。

SAML 応答とは何か

AWS 側は、ユーザーが SSO ログインしようとしたときに、IdP に対してこういうリクエストを出します。

このユーザーを認証してください。
認証できたら、結果を AWS に返してください。

このリクエストを SAML 認証リクエスト、または AuthnRequest と呼びます。SAML 認証では、AWS などのサービス側から IdP に送られた「認証リクエスト」に対して、以下の情報を送り応答します。

・誰がログインしたか
・認証に成功したか
・どの AWS ロールを使えるか
・どの AWS アカウントに入れるか
・この情報が IdP から発行されたことを示す署名

この情報を SAML 応答 や SAML Assertion と呼びます。ただし、AWS はその情報をそのまま信じるわけではありません。なぜなら、誰かが偽の SAML 応答を作って「私は管理者です」と AWS に送ってきたら危険だからです。そこで使われるのが署名です。AWS はその署名を検証して、信頼できる認証情報かどうかを判断します。

署名とは何か

なぜ AWS は、IdP から来た情報を信用するのでしょうか？ SAML 応答にはデジタル署名が付いているからです。IdP は SAML 応答に デジタル署名 を付けます。イメージとしては、「この SAML 応答は確かに IdP が発行しました」「途中で改ざんされていません」という証明です。たとえるなら、会社の正式な書類に押す社印のようなものです。

AWS はこのデジタル署名を検証します。「本当に信頼している IdP から来たものか？」「途中で改ざんされていないか？」「有効期限内か？」などチェックします。問題なければログインさせます。

IdP が SAML 応答を作る
  ↓
IdP が秘密鍵で署名する
  ↓
AWS が公開鍵で署名を検証する

この検証で重要なのが、以下の鍵と証明書になります。勝手にデジタル署名を作られても摘発できるように鍵を利用します。

秘密鍵
公開鍵
証明書

秘密鍵と公開鍵の関係

SAML の署名検証では、ざっくり次の関係になります。

種類	持つ場所	用途
秘密鍵	IdP 側だけが持つ	SAML 応答に署名する
公開鍵 / 証明書	AWS 側にも登録される	署名を検証する

重要なのは、AWS に秘密鍵をアップロードするわけではないという点です。AWS 側に必要なのは、IdP が付けた署名を検証するための 公開鍵情報 です。この公開鍵情報は、通常 SAML メタデータファイル の中に含まれています。

なので、AWS にアップロードするのは秘密鍵ではなく、最新の SAML メタデータになります。

SAML メタデータファイルとは何か

SAML メタデータファイルとは、IdP の設定情報が入った XML ファイルです。中には、たとえば以下のような情報が入っています。

・IdP の識別子
・SSO 用のエンドポイント URL
・ログイン先 URL
・署名検証に使う証明書
・公開鍵情報

SAML メタデータファイルの具体例

<EntityDescriptor
    entityID="https://idp.example.com/saml"
    xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

  <IDPSSODescriptor
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

    <KeyDescriptor use="signing">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>
MIIC8DCCAdigAwIBAgIQ...
          </X509Certificate>
        </X509Data>
      </KeyInfo>
    </KeyDescriptor>

    <SingleSignOnService
        Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
        Location="https://idp.example.com/sso/saml"/>

  </IDPSSODescriptor>
</EntityDescriptor>

つまり、AWS 側はこのメタデータファイルを見ることで、「この IdP から来た SAML 応答は、この証明書で検証すればよいのだな」と分かります。

EntityDescriptor　…　この IdP 自体の定義
entityID　…　IdP の識別子
IDPSSODescriptor　…　この IdP が SAML SSO に対応していることを示す情報
KeyDescriptor　…　署名検証に使う証明書情報
X509Certificate　…　公開鍵を含む証明書
SingleSignOnService　…　ユーザーをどこにリダイレクトすればよいかという IdP のログイン URL
validUntil　…　メタデータや証明書の有効期限情報が含まれる場合がある

X509Certificate に IdP の 公開鍵を含む証明書が入っています。秘密鍵は入っていません。秘密鍵は IdP 側が持っています。外には出てきません。

IdP 側：
秘密鍵で署名する

AWS 側：
公開鍵入り証明書で検証する

IdP 側で証明書が変わった場合の運用

IdP 側で証明書が変わった場合、AWS 側の SAML プロバイダー設定も更新する必要があります。以下のような運用になります。

1. IdP 管理画面にログイン
2. AWS 用 SAML アプリケーションのメタデータをダウンロード
3. AWS IAM の SAML プロバイダーを確認
4. update-saml-provider でメタデータを更新
5. ユーザーが AWS に SSO ログインできるか確認

IAM ロールの一時クレデンシャルを発行

AWS が SAML 応答を受けて検証し、問題がなければ AWS STS が AssumeRoleWithSAML により、指定された IAM ロールの一時クレデンシャルを発行します。

STS とは何か

AWS STS は Security Token Service の略です。役割は、一時的な AWS 認証情報を発行するサービスです。

AWS にアクセスするには通常、以下の認証情報が必要です。

AccessKeyId
SecretAccessKey
SessionToken

IAM ユーザーのアクセスキーは長期的に使えるものですが、STS が発行するものは 一時的 です。STS API を呼び出して一時的な認証情報を取得し、それを後続の AWS API 呼び出しに使います。

STS は一時的な認証情報を返す

AssumeRoleWithSAML が成功すると、STS は一時的な認証情報を返します。

{
  "Credentials": {
    "AccessKeyId": "ASIA....",
    "SecretAccessKey": "xxxxxxxx",
    "SessionToken": "xxxxxxxx",
    "Expiration": "2026-05-28T10:00:00Z"
  },
  "AssumedRoleUser": {
    "AssumedRoleId": "AROA....:user@example.com",
    "Arn": "arn:aws:sts::123456789012:assumed-role/AdminRole/user@example.com"
  }
}

確認するポイントは期限（Expiration）があることです。STS は一時的な認証なので、一定時間が過ぎると無効になります。

一時的な認証が重要

一時クレデンシャルには以下のメリットがあります。

漏えいしても有効期限がある
ユーザー退職時に IAM ユーザー削除が不要
IdP 側でユーザー無効化すればログインできなくなる
MFA や条件付きアクセスを IdP 側で集中管理できる
長期アクセスキーを配布しなくてよい

実際にエンタープライズ系の巨大企業の場合は社員や外部ベンダー、業務委託、派遣社員などを含めると1万人近い人間が業務に携わっています。毎日数十人の入社や参画があり、毎日数十人の退職や離任があります。いまだにユーザー一人一人に IAM ユーザーを作成して引き渡して、アクセスキーとシークレットアクセスキーで AWS CLI を実行しているケースもありますが、SSO を利用した方が圧倒的に楽でセキュリティレベルが向上します。

AssumeRoleWithSAML とは何か

AssumeRoleWithSAML は STS の API の1つです。意味を分解すると、WithSAML（= SAML 認証結果を使って）、AssumeRole（= IAM ロールを引き受ける）です。つまり、SAML 応答を根拠にして、IAM ロールを一時的に使えるようにする APIです。AssumeRoleWithSAML では SAML プロバイダー ARN、引き受ける IAM ロール ARN、IdP からの SAML アサーションを渡す と説明されています。

AssumeRoleWithSAML に渡される情報

RoleArn　…　引き受けたい IAM ロール
PrincipalArn　…　AWS IAM の SAML ID プロバイダー
SAMLAssertion　…　IdP から受け取った SAML 応答

IAM ロール側の信頼ポリシー

SAML 用の IAM ロールの信頼ポリシーは以下のようになっています。信頼ポリシーで誰がそのロールを引き受けられるか（誰がそのロールを引き受けてよいか）を定義します。SAML の場合は「この SAML ID プロバイダーから来たユーザーなら、このロールを使ってよい」という条件を書きます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/ExampleIdP"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

SSO とは

SSO は Single Sign-On の略で、シングルサインオン と言います。簡単に言うと、1回ログインすれば、複数のサービスに再ログインせず使える仕組みです。

通常のログイン

普通は、サービスごとにログインします。それぞれにログインする際にパスワードだったり MFA だったりとログイン方法が異なったり、パスワードポリシーが異なったりします。結構大変ですよね。毎朝の儀式のような感じになります（笑）

AWS にログイン
GitHub にログイン
Salesforce にログイン
Google Workspace にログイン

SSO の場合のログイン

SSO を使うと、会社の認証基盤に一度ログインすれば、複数サービスに入れます。

会社のログイン画面でログイン
  ↓
AWS に入れる
GitHub に入れる
Salesforce に入れる
Google Workspace に入れる

つまり、各サービスに直接パスワードを登録するのではなく、会社の認証システムが「この人は本人です」と証明する 形になります。ただ、実際一度会社の認証システムでログインしたら、その他のサービスが全部ノーパスワードで利用できるようになるかと言えば、そんなことはありません（笑）仕様とかセキュリティとかいろいろな事情があり、SSO を導入している企業でも結局普通のログインのようにログインすることになることが多いです。

SSO の登場人物

ユーザー　…　ログインしたい人
IdP　…　ユーザーを認証する側
SP　…　Service Provider、使いたいサービス側

SSO で利用する技術

SAML　…　AWS、企業向けSaaS、社内SSO
OIDC / OAuth　…　Webアプリ、スマホアプリ、Googleログインなど

SSO のメリット

すべて完璧に対応とはいかなくてもある程度対応できればかなり毎朝の儀式（まずはこのポータルにログイン、次にこの Web サイトにログインなど）が楽になります（笑）更に退職者が出ても迅速に退職者のアカウントを停止したり削除することができます。それだけでもリスクはかなり低くなります。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

【AWS】Aurora MySQL クエリログを取得する方法

この記事を書いた人

サイト管理人

コメントする

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。