Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

SAML 2.0 フェデレーション

フォーカスモード
SAML 2.0 フェデレーション - AWS Identity and Access Management

AWS は SAML 2.0 (Security Assertion Markup Language) を使用した ID フェデレーションをサポートします。これは、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。この機能はフェデレーションシングルサインオン (SSO) を有効にします。したがって、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS Management Console にログインしたり、AWS API オペレーションを呼び出したりできるようになります。SAML を使用すると、カスタム ID プロキシコードの書き込みの代わりに IdP のサービスを使用できるため、AWS を使用してフェデレーションを構成するプロセスを簡素化できます。

IAM フェデレーションは次のユースケースをサポートします。

SAML ベースのフェデレーションを使用した AWS への API アクセス

自分のコンピューターからバックアップフォルダにデータをコピーする方法を従業員に提供すると仮定します。ユーザーが、自分のコンピューターで実行できるアプリケーションを構築します。バックエンドで、アプリケーションは Amazon S3 バケットのオブジェクトを読み書きします。ユーザーは AWS に直接アクセスできません。代わりに、次のプロセスを使用します。

  1. 組織のユーザーが、クライアントアプリを使用して、組織の IdP に認証を要求します。

  2. IdP がユーザーを組織の ID ストアに対して認証します。

  3. IdP はユーザーに関する情報を使用して SAML アサーションを構築し、クライアントアプリにアサーションを送信します。

  4. クライアントアプリが、AWS STS AssumeRoleWithSAML API を呼び出して、SAML プロバイダーの ARN、引き受けるロールの ARN、および IdP からの SAML アサーションを渡します。

  5. API は一時的なセキュリティ認証情報を含むレスポンスをクライアントアプリに返します。

  6. クライアントアプリでは、一時的なセキュリティ証明書を使用して Amazon S3 API オペレーションを呼び出します。

SAML 2.0 ベースのフェデレーション設定の概要

前述のシナリオと図に示すように SAML 2.0 ベースのフェデレーションを使用するには、事前に組織の IdP と AWS アカウント を設定して相互に信頼する必要があります。この信頼を設定するための一般的なプロセスを次の手順で説明します。組織内に、Microsoft Active Directory フェデレーションサービス (AD FS、Windows Server の一部)、Shibboleth など、SAML 2.0 をサポートする IdP、または互換性のある他の SAML 2.0 プロバイダーを用意する必要があります。

注記

フェデレーションの耐障害性を高めるには、IdP と AWS フェデレーションを、複数の SAML サインインエンドポイントをサポートするように設定することをお勧めします。詳細については、AWS セキュリティブログの記事「フェイルオーバーにリージョン SAML エンドポイントを使用する方法」を参照してください。

組織の IdP と AWS が互いを信頼するように設定する
  1. 組織の IdP を使用し、サービスプロバイダー (SP) として AWS を登録します。https://region-code.signin.aws.amazon.com/static/saml-metadata.xml から SAML メタデータドキュメントを使用する

    実行可能な region-code 値のリストについては、「AWS サインインエンドポイント」の [Region] (リージョン) 列を参照します。

    任意で、https://signin.aws.amazon.com/static/saml-metadata.xml から SAML メタデータドキュメントが使用できます。

  2. 組織の IdP を使用して、AWS の IAM ID プロバイダーとして IdP を記述できる同等の SAML メタデータ XML ファイルを生成します。これには、発行元名、作成日、失効日、AWS が組織からの認証応答 (アサーション) を検証するために使用するキーを含める必要があります。

    注記

    SAML V2.0 メタデータ相互運用性プロファイルバージョン 1.0 で定義されているように、IAM は SAML メタデータドキュメントの X.509 証明書の有効期限で評価したりアクションを実行したりすることはできません。期限切れの X.509 証明書について懸念がある場合は、組織のガバナンスとセキュリティポリシーに従って証明書の有効期限をモニタリングし、証明書をローテーションすることをお勧めします。

  3. IAM コンソールで、SAML ID プロバイダーを作成します。このプロセスの一環として、組織の IdP によって生成された SAML メタデータドキュメントとを ステップ 2 でアップロードします。詳細については、「IAM で SAML ID プロバイダーを作成する」を参照してください。

  4. IAM で、 1 つ以上の ロールを作成します。ロールの信頼ポリシーで SAML プロバイダーを、組織と AWS 間の信頼関係を確立するプリンシパルとして設定します。ロールのアクセス許可ポリシーは、AWS で組織のユーザーが実行できることを設定します。詳細については、「サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する」を参照してください。

    注記

    ロール信頼ポリシーで使用される SAML IDP は、そのロールと同じアカウントにある必要があります。

  5. 組織の IdP で、組織のユーザーまたはグループを IAM ロールにマッピングするアサーションを定義します。組織内の異なるユーザーとグループは、異なる IAM ロールにマップされている場合があることに注意してください。マッピングを実行するための正確な手順は、使用している IdP によって異なります。ユーザーのフォルダに関する Amazon S3 の前述のシナリオでは、すべてのユーザーを Amazon S3 アクセス許可を提供する同じロールにマッピングすることができます。詳細については、「認証レスポンス用の SAML アサーションを設定する」を参照してください。

    IdP が AWS コンソールに SSO を有効にすると、コンソールセッションの最大継続時間を設定できます。詳細については、「SAML 2.0 フェデレーティッドユーザーが AWS Management Consoleにアクセス可能にする」を参照してください。

  6. 作成中のアプリケーションで、AWS Security Token ServiceAssumeRoleWithSAML API を呼び出し、ステップ「ステップ 3」で作成した SAML プロバイダーの ARN に渡します。ロールの ARN はステップ「ステップ 4」で作成したものとし、現在のユーザーに関する SAML アサーションは IdP から取得したものとします。AWS では、ロールを引き受けるリクエストは SAML プロバイダーで参照される IdP からのリクエストであることを確認します。

    詳細については、https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html API リファレンス の「AWS Security Token ServiceAssumeRoleWithSAML」を参照してください。

  7. リクエストが成功すると、API から一時的セキュリティ認証情報一式が返され、アプリケーションではこれを利用して AWS に対して署名付きリクエストを作成します。前のシナリオで説明したように、アプリケーションは、現在のユーザーの情報を取得し、Amazon S3 のユーザー固有のフォルダにアクセスできます。

AWS リソースへの SAML フェデレーションアクセスを許可するロールの概要

IAMで作成するロールは、組織のどのフェデレーションユーザーが AWS での操作を許可されるかを定義します。ロールの信頼ポリシーを作成するときは、前に Principal として作成した SAML プロバイダーを指定します。さらに、特定の SAML 属性に一致するユーザーにのみロールへのアクセスを許可するように、Condition 付きの信頼ポリシーのスコープを設定できます。たとえば、次のサンプルポリシーに示されているように、 (https://openidp.feide.no によってアサートされるように) SAML の所属が staff であるユーザーのみロールにアクセスできるように指定できます。

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"}, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "saml:aud": "https://us-west-2.signin.aws.amazon.com/saml", "saml:iss": "https://openidp.feide.no" }, "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]} } }] }
注記

ロール信頼ポリシーで使用される SAML IDP は、そのロールと同じアカウントにある必要があります。

ポリシーの saml:aud コンテキストキーは、コンソールにサインインするときにブラウザに表示される URL を指定します。このサインインエンドポイント URL は、ID プロバイダーの受取人属性と一致する必要があります。特定のリージョン内にサインイン URL を含めることができます。AWS では、フェデレーションの耐障害性を向上させるために、グローバルエンドポイントの代わりにリージョンエンドポイントを使用することをお勧めします。エンドポイントが 1 つしか設定されていない場合、エンドポイントが使用できなくなっても、AWS にフェデレーションすることはできません。実行可能な region-code 値のリストについては、「AWS サインインエンドポイント」の [リージョン] 列を参照します。

次の例は、オプションの region-code を使用したサインイン URL 形式を示しています。

https://region-code.signin.aws.amazon.com/saml

SAML 暗号化が必要な場合、サインイン URL に SAML プロバイダーに割り当てる一意の識別子 AWS が含まれている必要があります。この識別子は ID プロバイダーの詳細ページで確認できます。次の例では、サインイン URL に IdP の一意の識別子が含まれています。この識別子には、サインインパスに /acs/ を追加する必要があります。

https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID

ロールのアクセス許可ポリシーでは、ロールに付与するアクセス許可を自由に指定します。たとえば、組織のユーザーが Amazon Elastic Compute Cloud インスタンスを管理できる場合、AmazonEC2FullAccess 管理ポリシーのように、アクセス許可ポリシーで明示的に Amazon EC2 アクションを許可します。

ポリシーでチェック可能な SAML キーの詳細については、「SAML ベースの AWS STS フェデレーションに利用可能なキー」を参照してください。

SAML ベースのフェデレーションでユーザーを一意に識別する

IAM でアクセスポリシーを作成するときに、ユーザーの ID に基づいてアクセス許可を指定できると、便利です。たとえば、SAML を使用してフェデレーションされたユーザーの情報は、アプリケーションで以下のような構造体を使用して Amazon S3 に保存することをお勧めします。

amzn-s3-demo-bucket/app1/user1 amzn-s3-demo-bucket/app1/user2 amzn-s3-demo-bucket/app1/user3

バケット (amzn-s3-demo-bucket) およびフォルダ (app1) は静的な値であるため、Amazon S3 コンソールまたは AWS CLI で作成できます。ただし、ユーザー固有のフォルダ (user1user2user3 など) は、ユーザーが最初にフェデレーションプロセスを通してサインインするまでユーザーを特定する値がわからないため、実行時にコードを使用して作成する必要があります。

リソース名の一部としてユーザー固有の詳細を参照するポリシーを記述するには、ユーザー ID がポリシー条件で使用できる SAML キーで利用可能である必要があります。IAM ポリシーで使用する SAML 2.0 ベースのフェデレーションでは、次のキーを使用できます。以下のキーによって返される値を使用して、Amazon S3 フォルダなどのリソースの一意のユーザー ID を作成できます。

  • saml:namequalifier.Issuer のレスポンス値 (saml:iss)、AWS アカウント ID および IAM の SAML プロバイダーのわかりやすい名前 (ARN の最後の部分) の文字列を連結したハッシュ値。アカウント ID および SAML プロバイダーのわかりやすい名前の連結はキー saml:doc として、IAM のポリシーで使用できます。アカウント ID とプロバイダー名は、「123456789012/provider_name」のように「/」で区切る必要があります。詳細については、「saml:doc」の SAML ベースの AWS STS フェデレーションに利用可能なキー キーを参照してください。

    NameQualifierSubject の組み合わせを使用して、フェデレーティッドユーザーを一意に識別できます。次の擬似コードは、この値の計算方法を示します。この擬似コードで + は連結を表し、SHA1 は SHA-1 を使用してメッセージダイジェストを生成する関数を、Base64 は Base-64 でエンコードされたバージョンのハッシュ出力を生成する関数を示します。

    Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )

    SAML ベースのフェデレーションで利用可能なポリシーキーの詳細については、「SAML ベースの AWS STS フェデレーションに利用可能なキー」を参照してください。

  • saml:sub(文字列)。* これはクレームの件名です。組織内の個々のユーザーを一意に識別する値が含まれます(例: _cbb88bf52c2510eabe00c1642d4643f41430fe25e3)。

  • saml:sub_type(文字列)。このキーは、persistenttransient、または SAML アサーションで使用されている Format および Subject 要素の完全な NameID URI とすることができます。persistent の値は、すべてのセッションでユーザーの saml:sub 値が同じことを意味します。値が transient の場合、ユーザーの saml:sub 値はセッションごとに異なります。NameID 要素の Format 属性の詳細については、「認証レスポンス用の SAML アサーションを設定する」を参照してください。

以下の例は前述のキーを使用して Amazon S3 のユーザー固有のフォルダにアクセス許可を付与するためのアクセスポリシーを示します。ポリシーは、Amazon S3 オブジェクトが saml:namequalifiersaml:sub の両方を含むプレフィックスを使用して特定されていることを前提としていまします。Condition 要素には、saml:sub_typepersistent に設定されていることを確認するテストが含まれることに注意してください。transient" に設定されている場合、ユーザーの saml:sub 値はセッションごとに異なる可能性があるため、値の組み合わせを使用してユーザー固有のフォルダを識別することはできません。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}", "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*" ], "Condition": {"StringEquals": {"saml:sub_type": "persistent"}} } }

IdP からポリシーキーにアサーションをマッピングする方法については、「認証レスポンス用の SAML アサーションを設定する」を参照してください。

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.