メニュー
AWS Identity and Access Management
ユーザーガイド

SAML 2.0 ベースのフェデレーションについて

AWS は SAML 2.0 (Security Assertion Markup Language) を使用した ID フェデレーションをサポートします。これは、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。この機能はフェデレーティッドシングルサインオン (SSO) を有効にします。従って、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS マネジメントコンソールにログインしたり、AWS API を呼び出したりできるようになります。SAML を利用すると、カスタム ID プロキシコードを記述する代わりに IdP のサービスを利用できるため、AWS で簡単にフェデレーションを設定できます。

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

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

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

  SAML アサーションに基づいて一時的セキュリティ認証情報を取得する
  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 プロバイダーを用意する必要があります。

  1. IdP を使用して AWS を登録することから開始します。組織の IdP で、次の URL から取得した SAML メタデータドキュメントを使用して、AWS をサービスプロバイダー (SP) として登録します。

    https://signin.aws.amazon.com/static/saml-metadata.xml

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

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

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

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

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

    注記

    SAML 2.0 フェデレーションの AWS 実装では、ID プロバイダーと AWS 間の暗号化 SAML アサーションはサポートされていません。ただし、お客様のシステムと AWS 間のトラフィックは暗号化 (TLS) チャネルを介して送信されます。

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

    詳細については、『AWS Security Token Service API リファレンス』の「AssumeRoleWithSAML」を参照してください。

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

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

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

Copy
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"AWS": "arn:aws:sts::ACCOUNT-ID-WITHOUT-HYPHENS:saml-provider/ExampleOrgSSOProvider"}, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "saml:aud": "https://signin.aws.amazon.com/saml", "saml:iss": "https://openidp.feide.no" }, "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]} } }] }

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

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

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

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

Copy
myBucket/app1/user1 myBucket/app1/user2 myBucket/app1/user3

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

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

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

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

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

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

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

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

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

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

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