Uncategorized

SAML

 

🔐 認証・認可フロー詳細図解（提供側・利用側共通）

① IdP Initiated SAML認証の開始（Keycloakが起点）

  • 業務システムがブラウザ経由でKeycloakにリダイレクトされる。
  • Keycloakは事前登録された職員の資格情報（例：LDAP連携など）で本人認証を実施。
  • Keycloakは、SAMLアサーション（認証結果と属性情報）を生成。

② SAMLアサーションの受け渡し

  • Keycloakは、信頼関係を結んだAWS IAMのSAMLプロバイダーにアサーションを送信。
  • アサーションには、AssumeRoleWithSAML APIで利用するためのRole ARNなどが含まれる。

③ AWS STSにより一時的な認証情報を取得

  • AWS IAMは受け取ったSAMLアサーションを検証し、対応するIAMロールにAssumeRoleWithSAMLでスイッチ。
  • これにより、以下の一時セキュリティ情報を返す：
    • 一時的なAccessKeyId / SecretAccessKey
    • SessionToken
    • 有効期限（最大1時間）

④ ファイル連携の実施（S3アクセス）

  • 業務システムは、取得したSTSの資格情報を使って、AWS SDKやCLI経由でS3バケットにアクセス。
    • 提供側：ファイルをアップロード
    • 利用側：ファイルをダウンロード
  • バケットポリシーは、IAMロールベースで操作権限を制限（例：prefixによるアクセス制御）

Step 1：業務システムA（アップロード処理）

  1. 職員ユーザーが業務システムAにログイン
    • KeycloakをIdPとしたSAML2.0のSSOで認証（IdP initiated flow）。
    • KeycloakはSAMLアサーションを発行し、IAMに転送。
  2. Keycloak → AWS IAM
    • AssumeRoleWithSAML を通じてIAMロールにスイッチ（提供者用のRole）。
    • IAMからSTSの一時的な認証情報（AccessKeyId/SecretAccessKey/SessionToken）を取得。
  3. 業務システムA → S3
    • STSで得た一時クレデンシャルを使い、S3へファイルをアップロード。
  4. アップロード完了後 → Lambda起動
    • ファイル格納完了イベントをトリガーにLambda（Notification File Creation Lambda）が起動。
    • 通知ファイルを作成し、業務システムBの起動契機となる。

🔹 Step 2：業務システムB（ダウンロード処理）

  1. 業務システムB → Lambda通知受信
    • Notification Fileにより、S3上の新規ファイルの存在を認識。
  2. 業務システムB → KeycloakでSSO
    • 同様にKeycloakでSAML認証 → AWS IAMにSAMLアサーション送信。
  3. IAMでのロール切替（AssumeRoleWithSAML）
    • 業務システムB専用のIAMロールに切替。
    • STSから一時的なアクセス資格情報を取得。
  4. 業務システムB → S3アクセス
    • 取得した資格情報を使って、対象ファイルをダウンロード。
項目SAML + IAMロール連携IAMロール同士のAssume
発信元外部IdP（Keycloakなど）AWS内のIAMエンティティ（ロール/ユーザー）
認証方式SAMLアサーションIAMで既に認証済み
使用するAPIAssumeRoleWithSAMLAssumeRole
検証項目アサーションの署名・Issuer・Audience・期限など信頼ポリシーのPrincipalのみ
主な用途外部ユーザーのフェデレーションログインAWS内のクロスアカウントや権限昇格
必要な構成SAMLプロバイダー＋メタデータ＋IAM信頼ポリシーIAM信頼ポリシー＋IAMロール間の関係のみ

はい、まさにその通りです！🎯
あなたが言うように、①（SAML + IAMロール連携）は、特に以下のようなアプリケーションや業務バッチに対してIAMロールを動的に引き継がせたい場合にとても有効な選択肢です。

✅ SAML + IAMロール連携が有効なシーン

🔧 想定例：業務バッチ（ECS / Lambda など）＋ Keycloak 認証

  • 業務バッチは Keycloak経由で認証
  • 認証後に取得した SAMLアサーションを使ってAWSにアクセス
  • アサーションをSTSに渡して 一時的な認証情報（IAMロール）を取得
  • S3やDynamoDBなど、IAMポリシーで許可されたAWSリソースにアクセス

📌 なぜ有効か？

理由説明
✅ AWSユーザー/ロールを直接発行しなくて済むユーザー管理はKeycloakに集約され、AWS側はIAMロールのみ
✅ セキュリティ強化アサーションには有効期限があり、STSトークンも一時的（デフォルト1時間）
✅ 外部の認証基盤と統合しやすいKeycloak、AzureAD、ADFSなどを使って統一された認証を実現可能
✅ 多様なアプリケーションに対応Webアプリ、業務バッチ、CLIツールなどSAMLに対応した形で統合可能

📦 バッチ処理の一般的な構成（例）

[1] 業務バッチ（ECS/EC2）
   ↓ SAML認証リクエスト
[2] Keycloak（IdP）
   ↓ SAMLアサーション（署名付き）
[3] バッチが AWS STS にアサーションを送信
   ↓
[4] STS がロールに基づく一時認証情報（AccessKey, SecretKey, SessionToken）を返す
   ↓
[5] バッチが S3 や DynamoDB にアクセス（ロールのポリシー内で許可されている範囲）

✅ まとめ

SAML連携は、AWSアカウント内にIAMユーザーやIAMロールを静的に持たずに、認証された外部アプリに最小限のアクセス権を一時的に委譲できる強力な手段です。

バッチやAPIの実行に 都度SAMLアサーションを発行して短時間だけ使わせる構成は、セキュリティ・可用性・拡張性の観点で非常に優れています。

もしご希望であれば、JavaScriptやNode.jsでのSAMLアサーション＋AssumeRoleWithSAMLの実装パターンもご紹介できます。

RELATED POST