SAML ベースのフェデレーションを使用した AWS への API アクセス SAML 2.0 ベースのフェデレーション設定の概要 AWS リソースへの SAML フェデレーションアクセスを許可するロールの概要 SAML ベースのフェデレーションでユーザーを一意に識別する

SAML 2.0 フェデレーション

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

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

組織のユーザーまたはアプリケーションが AWS API オペレーションを呼び出すことを許可するフェデレーティッドアクセス。組織で生成した SAML アサーションを (認証レスポンスの一部として) 使用して、一時的セキュリティ認証情報を取得します。このシナリオは、「一時的なセキュリティ認証情報のリクエスト」および「OIDC フェデレーション」で説明されているような、IAM でサポートされている他のフェデレーションのシナリオに似ています。ただし、認証と認可のチェックの実行時は、組織の SAML 2.0 ベースの IdP によってその詳細の多くが処理されます。これは、このトピックで説明するシナリオです。
組織から AWS Management Console へのウェブベースのシングルサインオン (SSO)。ユーザーが SAML 2.0 互換 IdP でホストされる組織のポータルにサインインして、AWS に移動するオプションを選択すると、追加でサインインの情報を入力しなくてもコンソールにリダイレクトされます。サードパーティーの SAML IdP を使用してコンソールへの SSO アクセスを確立するか、外部ユーザーのコンソールアクセスを有効にするカスタム IdP を作成することができます。カスタム IdP の構築の詳細については、「カスタム ID ブローカーに対する AWS コンソールへのアクセスの許可」を参照してください。

トピック

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

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

組織のユーザーが、クライアントアプリを使用して、組織の IdP に認証を要求します。
IdP がユーザーを組織の ID ストアに対して認証します。
IdP はユーザーに関する情報を使用して SAML アサーションを構築し、クライアントアプリにアサーションを送信します。
クライアントアプリが、AWS STS AssumeRoleWithSAML API を呼び出して、SAML プロバイダーの ARN、引き受けるロールの ARN、および IdP からの SAML アサーションを渡します。
API は一時的なセキュリティ認証情報を含むレスポンスをクライアントアプリに返します。
クライアントアプリでは、一時的なセキュリティ証明書を使用して 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 が互いを信頼するように設定するには

組織の 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 メタデータドキュメントが使用できます。
組織の IdP を使用して、AWS の IAM ID プロバイダーとして IdP を記述できる同等のメタデータ XML ファイルを生成します。これには、発行元名、作成日、失効日、AWS が組織からの認証応答 (アサーション) を検証するために使用するキーを含める必要があります。
IAM コンソールで、SAML ID プロバイダーのエンティティを作成します。このプロセスの一環として、組織の IdP によって生成された SAML メタデータドキュメントをステップ 2 でアップロードします。詳細については、「IAM で SAML ID プロバイダーを作成する」を参照してください。
IAM で、 1 つ以上のロールを作成します。ロールの信頼ポリシーで SAML プロバイダーを、組織と AWS 間の信頼関係を確立するプリンシパルとして設定します。ロールのアクセス許可ポリシーは、AWS で組織のユーザーが実行できることを設定します。詳細については、「サードパーティー ID プロバイダー (フェデレーション) 用のロールの作成」を参照してください。

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

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

注記
SAML 2.0 フェデレーションの AWS 実装では、IAM ID プロバイダーと AWS 間の暗号化 SAML アサーションはサポートされていません。ただし、お客様のシステムと AWS 間のトラフィックは暗号化 (TLS) チャネルを介して送信されます。
作成中のアプリケーションで、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」を参照してください。
リクエストが成功すると、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://signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}

注記

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

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

https://region-code.signin.aws.amazon.com/static/saml-metadata.xml で saml:aud 属性のリージョナルエンドポイントを含めることができます。実行可能な region-code 値のリストについては、「AWS サインインエンドポイント」の [Region] (リージョン) 列を参照します。

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

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

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


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

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

リソース名の一部としてユーザー固有の詳細を参照するポリシーを記述するには、ユーザー 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 フェデレーションに利用可能なキーキーを参照してください。

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

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

SAML ベースのフェデレーションで利用可能なポリシーキーの詳細については、「SAML ベースの AWS STS フェデレーションに利用可能なキー」を参照してください。
saml:sub（文字列）。* これはクレームの件名です。組織内の個々のユーザーを一意に識別する値が含まれます（例: _cbb88bf52c2510eabe00c1642d4643f41430fe25e3）。
saml:sub_type（文字列）。このキーは、persistent、transient、または SAML アサーションで使用されている Format および Subject 要素の完全な NameID URI とすることができます。persistent の値は、すべてのセッションでユーザーの saml:sub 値が同じことを意味します。値が transient の場合、ユーザーの saml:sub 値はセッションごとに異なります。NameID 要素の Format 属性の詳細については、「認証レスポンス用の SAML アサーションを設定する」を参照してください。

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


{
  "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 アサーションを設定する」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

OIDC フェデレーションに関するその他のリソース

SAML ID プロバイダーを作成する