IdP・SAML2.0・SSOを使ったシングルサインオンをやさしく解説
IAM（Identity and Access Management） は、会社の入退室管理システムのようなものです。
ユーザーが本当に本人かどうかを確認
適切な権限を持つ人だけがリソースにアクセス可能
すべてのユーザーと権限を中央で管理
IdP は、運転免許証を発行する警察署や、学生証を発行する大学のような 信頼できる身元証明機関 です。
IdPが身元を証明 → ユーザーがAWSにアクセス
ユーザーのパスワードやMFAを管理
AWSがIdPを信頼してユーザーを受け入れ
SAML 2.0 は、身分証明書の 国際標準フォーマット のようなものです。どこの国でも読める共通の形式です。
📝 ユーザー情報： 田中太郎
🏢 所属： ABC株式会社
📧 メール： tanaka@abc.com
👥 グループ： 開発部
⏰ 有効期限： 1時間
🔏 電子署名： IdPによる改ざん防止
異なるシステム間でも共通理解
暗号化と電子署名で保護
一度認証すれば複数サービスで利用可能
フェデレーション は、大学間の単位互換制度のような 組織間の信頼関係 です。A大学の学生証でB大学の図書館も使えるイメージです。
SSO は、ホテルのマスターキーのようなもので、 一度ログインすれば複数のサービス にアクセスできます。
パスワードを覚える負担軽減
パスワード使い回しのリスク削減
IT部門の管理負担軽減
SP（Service Provider） は、クレジットカード会社（IdP）と提携する お店 のようなものです。AWSを「お店」として登録することで、従業員が「会社カード」でサービスを利用できます。
会社のActive Directory
信頼関係構築
SPとして登録
AWS・Office365・Slack
• SP識別子（Entity ID）
• アクセス先URL（ACS URL）
• 属性マッピング設定
• SAMLプロバイダー作成
• IAMロール設定
• 信頼関係の構築
• Entity ID:
urn:amazon:webservices
• ACS URL:
https://signin.aws.amazon.com/saml
• 属性マッピング: 部署 → IAMロール
• SAMLプロバイダー: CompanyAD
• メタデータ: IdPの設定情報（XMLファイル）
• IAMロール: SAML-DeveloperRole
登録前:
従業員はAWS専用のパスワードが必要
登録後:
会社のIDとパスワードだけでAWSにアクセス可能！
部署に応じて自動的に適切な権限が割り当てられます
会社のIDカードで劇場（AWS）に入る流れを想像してください。
1.
田中さんがAWSコンソールにアクセス
2.
AWSが「会社のIdPで認証してください」と案内
3.
田中さんが会社のパスワードでログイン
4.
IdPが「田中さんは開発部の正社員です」という証明書（SAMLトークン）を発行
5.
田中さんがその証明書をAWSに提示
6.
AWSが証明書を確認して、開発部用の権限でアクセス許可
SAMLアサーション は、コンサートの 入場チケット のようなもので、ユーザーの身元と権限を証明する「デジタル身分証明書」です。
ユーザー： 田中太郎
認証時刻： 2025-06-06 14:30
認証方法： パスワード + MFA
メール： tanaka@company.com
部署： 開発部
グループ： Developers
AWSロール： arn:aws:iam::123456789:role/DeveloperRole
有効期限： 1時間
発行者： 会社IdP（電子署名付き）
•
デジタル署名
：改ざん検出
•
暗号化
：情報保護
•
有効期限
：リスク最小化
•
認証情報
：誰が、いつ、どうやって
•
属性情報
：ユーザーの詳細
•
認可情報
：アクセス権限
•
一時的
：短時間で失効
•
標準化
：SAML 2.0準拠
•
信頼性
：IdPの保証付き
SAMLアサーションは
「使い捨てのデジタルチケット」
です。
一度使用すると短時間で無効になり、毎回新しいものが発行されるため、
セキュリティが高く保たれています。
信頼ポリシー は、高級ホテルが作る 「信頼できる旅行代理店リスト」 のようなものです。事前に「どの代理店からの予約なら受け入れるか」を決めておきます。
VIPルームを管理
予約を取り扱う
VIPルームを利用したい
受付マニュアル
✅ ABC株式会社旅行部 （SAMLプロバイダー）
✅ XYZ旅行代理店
❌ 怪しい代理店X（登録なし）
知らない代理店（IdP）からの予約（SAMLアサーション）は受け入れない
事前に「誰を信頼するか」を決めておく受付マニュアル
リストにあれば自動でOK、なければ自動でNG
実際のAWS信頼ポリシーは、 ホテルの詳細な受付マニュアル のようなものです。
📋 信頼する代理店:
ABC株式会社旅行部のみ
✅ 受け入れ条件:
• 正式な予約確認書を持参
• 開発部の社員のみ
• 平日営業時間内
🚫 禁止事項:
• リストにない代理店はNG
• 確認書なしはNG
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"SAML": "arn:aws:iam::123:saml-provider/ABC"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:Department": "開発部"
}
}
}]
}
SAML: 「この特定のSAMLプロバイダーを信頼します」
arn:aws:iam::123:saml-provider/ABC
→ ABC会社のIdPからの認証のみ受け入れ
sts:AssumeRoleWithSAML
→ SAMLアサーションを使ってロールを引き受ける操作を許可
SAML:Department = "開発部"
→ SAMLアサーションに「開発部」の属性がある場合のみ許可
1.
田中さん（開発部）がAWSにアクセス
2.
AWSが信頼ポリシーをチェック
3.
「ABC会社のIdP？✅」「開発部？✅」「OK！」
4.
山田さん（総務部）の場合は「総務部？❌」でNG
AWSの
セキュリティの門番
誰が何にアクセスできるかを管理
信頼できる身元証明機関
ユーザーの認証を担当
共通の身分証明書フォーマット
異なるシステム間の橋渡し
組織間の信頼関係
外部IdPとAWSの連携
一度のログインで全てアクセス
利便性とセキュリティを両立
効率的で安全なアクセス管理
ユーザーも管理者もハッピー
会社のIDひとつで、AWS・Office365・Slackなど
すべてのクラウドサービスが使える！
パスワード管理の煩わしさから解放され、セキュリティも向上
Created by SSuzuki1063
AWS SAP Learning Resources
Created by SSuzuki1063
AWS SAP Learning Resources