# SAML 2.0 フェデレーション
AWS は [SAML 2.0 (Security Assertion Markup Language)](https://wiki.oasis-open.org/security) を使用した ID フェデレーションをサポートします。これは、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。この機能はフェデレーションシングルサインオン (SSO) を有効にします。したがって、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS マネジメントコンソール にログインしたり、AWS API オペレーションを呼び出したりできるようになります。SAML を使用すると、[カスタム ID プロキシコードの書き込み](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html)の代わりに IdP のサービスを使用できるため、AWS を使用してフェデレーションを構成するプロセスを簡素化できます。
**注記**
IAM SAML ID フェデレーションは、SAML ベースのフェデレーション ID プロバイダー (IdP) からの暗号化された SAML レスポンスをサポートします。IAM Identity Center と Amazon Cognito は、IAM SAML ID プロバイダーからの暗号化された SAML アサーションをサポートしていません。
Amazon Cognito ユーザープールとの Amazon Cognito アイデンティティプールフェデレーションに、暗号化された SAML アサーションのサポートを間接的に追加できます。ユーザープールには、IAM SAML フェデレーションとは無関係で、[SAML 署名と暗号化](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html)をサポートしている SAML フェデレーションがあります。この機能は ID プールに直接拡張されませんが、ユーザープールはアイデンティティプールへの IdP にすることができます。アイデンティティプールで SAML 暗号化を使用するには、アイデンティティプールへの IdP であるユーザープールに暗号化付きの SAML プロバイダーを追加します。
SAML プロバイダーは、ユーザープールが提供するキーを使用して SAML アサーションを暗号化できる必要があります。ユーザープールは、IAM が提供した証明書で暗号化されたアサーションを受け入れません。
IAM フェデレーションは次のユースケースをサポートします。
+ [**組織のユーザーまたはアプリケーションが AWS API オペレーションを呼び出すことを許可するフェデレーティッドアクセス**](#CreatingSAML-configuring)。このユースケースについては、次のセクションで説明します。組織で生成した SAML アサーションを (認証レスポンスの一部として) 使用して、一時的セキュリティ認証情報を取得します。このシナリオは、「[一時的なセキュリティ認証情報をリクエストする](id_credentials_temp_request.md)」および「[OIDC フェデレーション](id_roles_providers_oidc.md)」で説明されているような、IAM でサポートされている他のフェデレーションのシナリオに似ています。ただし、認証と認可のチェックの実行時は、組織の SAML 2.0 ベースの IdP によってその詳細の多くが処理されます。
+ [**組織から AWS マネジメントコンソール へのウェブベースのシングルサインオン (SSO)**](id_roles_providers_enable-console-saml.md)。ユーザーが SAML 2.0 互換 IdP でホストされる組織のポータルにサインインして、AWS に移動するオプションを選択すると、追加でサインインの情報を入力しなくてもコンソールにリダイレクトされます。サードパーティーの SAML IdP を使用してコンソールへの SSO アクセスを確立するか、外部ユーザーのコンソールアクセスを有効にするカスタム IdP を作成することができます。カスタム IdP の構築の詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
**Topics**
+ [SAML ベースのフェデレーションを使用した AWS への API アクセス](#CreatingSAML-configuring)
+ [SAML 2.0 ベースのフェデレーション設定の概要](#CreatingSAML-configuring-IdP)
+ [AWS リソースへの SAML フェデレーションアクセスを許可するロールの概要](#CreatingSAML-configuring-role)
+ [SAML ベースのフェデレーションでユーザーを一意に識別する](#CreatingSAML-userid)
+ [IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)
+ [証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する](id_roles_providers_create_saml_relying-party.md)
+ [サードパーティーの SAML ソリューションプロバイダーを AWS に統合する](id_roles_providers_saml_3rd-party.md)
+ [認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)
+ [SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)
+ [ブラウザに SAML レスポンスを表示する](troubleshoot_saml_view-saml-response.md)
## SAML ベースのフェデレーションを使用した AWS への API アクセス
自分のコンピューターからバックアップフォルダにデータをコピーする方法を従業員に提供すると仮定します。ユーザーが、自分のコンピューターで実行できるアプリケーションを構築します。バックエンドで、アプリケーションは Amazon S3 バケットのオブジェクトを読み書きします。ユーザーは AWS に直接アクセスできません。代わりに、次のプロセスを使用します。
1. 組織のユーザーが、クライアントアプリを使用して、組織の IdP に認証を要求します。
1. IdP がユーザーを組織の ID ストアに対して認証します。
1. IdP はユーザーに関する情報を使用して SAML アサーションを構築し、クライアントアプリにアサーションを送信します。IAM SAML IdP の SAML 暗号化を有効にすると、このアサーションは外部 IdP によって暗号化されます。
1. クライアントアプリが、AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API を呼び出して、SAML プロバイダーの ARN、引き受けるロールの ARN、および IdP からの SAML アサーションを渡します。暗号化が有効になっている場合、クライアントアプリケーションを介して渡されたアサーションは転送中に暗号化されたままになります。
1. (オプション) AWS STS は、外部 IdP からアップロードされたプライベートキーを使用して、暗号化された SAML アサーションを復号します。
1. API は一時的なセキュリティ認証情報を含むレスポンスをクライアントアプリに返します。
1. クライアントアプリでは、一時的なセキュリティ証明書を使用して Amazon S3 API オペレーションを呼び出します。
## SAML 2.0 ベースのフェデレーション設定の概要
前述のシナリオと図に示すように SAML 2.0 ベースのフェデレーションを使用するには、事前に組織の IdP と AWS アカウント を設定して相互に信頼する必要があります。この信頼を設定するための一般的なプロセスを次の手順で説明します。組織内に、Microsoft Active Directory フェデレーションサービス (AD FS、Windows Server の一部)、Shibboleth など、[SAML 2.0 をサポートする IdP](id_roles_providers_saml_3rd-party.md)、または互換性のある他の SAML 2.0 プロバイダーを用意する必要があります。
**注記**
フェデレーションの耐障害性を高めるには、IdP と AWS フェデレーションを、複数の SAML サインインエンドポイントをサポートするように設定することをお勧めします。詳細については、AWS セキュリティブログの記事「[フェイルオーバーにリージョン SAML エンドポイントを使用する方法](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)」を参照してください。
**組織の IdP と AWS が互いを信頼するように設定する**
1. 組織の IdP を使用し、サービスプロバイダー (SP) として AWS を登録します。`https://{{region-code}}.signin.aws.amazon.com/static/saml-metadata.xml` から SAML メタデータドキュメントを使用する
実行可能な {{region-code}} 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[Region]** (リージョン) 列を参照します。
任意で、`https://signin.aws.amazon.com/static/saml-metadata.xml` から SAML メタデータドキュメントが使用できます。
1. 組織の IdP を使用して、AWS の IAM ID プロバイダーとして IdP を記述できる同等の SAML メタデータ XML ファイルを生成します。これには、発行元名、作成日、失効日、AWS が組織からの認証応答 (アサーション) を検証するために使用するキーを含める必要があります。
暗号化された SAML アサーションを外部 IdP から送信することを許可する場合は、組織の IdP を使用してプライベートキーファイルを生成し、このファイルを .pem ファイル形式 AWS STS で IAM SAML 設定にアップロードする必要があります。IdP にアップロードされたパブリックキーに対応する SAML 応答を復号化するには、このパブリックキーが必要です。
**注記**
[SAML V2.0 メタデータ相互運用性プロファイルバージョン 1.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html) で定義されているように、IAM は SAML メタデータドキュメントの X.509 証明書の有効期限で評価したりアクションを実行したりすることはできません。期限切れの X.509 証明書について懸念がある場合は、組織のガバナンスとセキュリティポリシーに従って証明書の有効期限をモニタリングし、証明書をローテーションすることをお勧めします。
1. IAM コンソールで、SAML ID プロバイダーを作成します。このプロセスの一環として、組織の IdP によって生成された SAML メタデータドキュメントとプライベート複合キーを [Step 2](#createxml) でアップロードします。詳細については、「[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)」を参照してください。
1. IAM で、 1 つ以上の ロールを作成します。ロールの信頼ポリシーで SAML プロバイダーを、組織と AWS 間の信頼関係を確立するプリンシパルとして設定します。ロールのアクセス許可ポリシーは、AWS で組織のユーザーが実行できることを設定します。詳細については、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」を参照してください。
**注記**
ロール信頼ポリシーで使用される SAML IDP は、そのロールと同じアカウントにある必要があります。
1. 組織の IdP で、組織のユーザーまたはグループを IAM ロールにマッピングするアサーションを定義します。組織内の異なるユーザーとグループは、異なる IAM ロールにマップされている場合があることに注意してください。マッピングを実行するための正確な手順は、使用している IdP によって異なります。ユーザーのフォルダに関する Amazon S3 の[前述のシナリオ](#CreatingSAML-configuring)では、すべてのユーザーを Amazon S3 アクセス許可を提供する同じロールにマッピングすることができます。詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。
IdP が AWS コンソールに SSO を有効にすると、コンソールセッションの最大継続時間を設定できます。詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。
1. 作成中のアプリケーションで、AWS Security Token Service`AssumeRoleWithSAML` API を呼び出し、ステップ「[Step 3](#samlovrcreateentity)」で作成した SAML プロバイダーの ARN に渡します。ロールの ARN はステップ「[Step 4](#samlovrcreaterole)」で作成したものとし、現在のユーザーに関する SAML アサーションは IdP から取得したものとします。AWS では、ロールを引き受けるリクエストは SAML プロバイダーで参照される IdP からのリクエストであることを確認します。
詳細については、[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API リファレンス* の「AWS Security Token ServiceAssumeRoleWithSAML*」を参照してください。
1. リクエストが成功すると、API から一時的セキュリティ認証情報一式が返され、アプリケーションではこれを利用して AWS に対して署名付きリクエストを作成します。前のシナリオで説明したように、アプリケーションは、現在のユーザーの情報を取得し、Amazon S3 のユーザー固有のフォルダにアクセスできます。
## AWS リソースへの SAML フェデレーションアクセスを許可するロールの概要
IAMで作成するロールは、組織の SAML フェデレーションプリンシパルが AWS で許可されたアクションを定義します。ロールの信頼ポリシーを作成するときは、前に `Principal` として作成した SAML プロバイダーを指定します。さらに、特定の SAML 属性に一致するユーザーにのみロールへのアクセスを許可するように、`Condition` 付きの信頼ポリシーのスコープを設定できます。たとえば、次のサンプルポリシーに示されているように、 (https://openidp.feide.no によってアサートされるように) SAML の所属が `staff` であるユーザーのみロールにアクセスできるように指定できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Federated": "arn:aws:iam::{{111122223333}}:saml-provider/ExampleOrgSSOProvider"},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"saml:aud": "https://{{us-east-1}}.signin.aws.amazon.com/saml",
"saml:iss": "https://openidp.feide.no"
},
"ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
}
}]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws-cn:iam::{{111122223333}}:saml-provider/ExampleOrgSSOProvider"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"saml:aud": "https://{{ap-east-1}}.signin.amazonaws.cn/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 サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[リージョン]** 列を参照します。
次の例は、オプションの `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 フェデレーションに利用可能なキー](reference_policies_iam-condition-keys.md#condition-keys-saml)」を参照してください。
## 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 で作成できます。ただし、ユーザー固有のフォルダ ({{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 フェデレーションに利用可能なキー](reference_policies_iam-condition-keys.md#condition-keys-saml) キーを参照してください。
`NameQualifier` および `Subject` の組み合わせは、SAML フェデレーティッドプリンシパルを一意に識別するために使用できます。次の擬似コードは、この値の計算方法を示します。この擬似コードで `+` は連結を表し、`SHA1` は SHA-1 を使用してメッセージダイジェストを生成する関数を、`Base64` は Base-64 でエンコードされたバージョンのハッシュ出力を生成する関数を示します。
`Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )`
SAML ベースのフェデレーションで利用可能なポリシーキーの詳細については、「[SAML ベースの AWS STS フェデレーションに利用可能なキー](reference_policies_iam-condition-keys.md#condition-keys-saml)」を参照してください。
+ `saml:sub`（文字列）。\* これはクレームの件名です。組織内の個々のユーザーを一意に識別する値が含まれます（例: `_cbb88bf52c2510eabe00c1642d4643f41430fe25e3`）。
+ `saml:sub_type`（文字列）。このキーは、`persistent`、`transient`、または SAML アサーションで使用されている `Format` および `Subject` 要素の完全な `NameID` URI とすることができます。`persistent` の値は、すべてのセッションでユーザーの `saml:sub` 値が同じことを意味します。値が `transient` の場合、ユーザーの `saml:sub` 値はセッションごとに異なります。`NameID` 要素の `Format` 属性の詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。
以下の例は前述のキーを使用して Amazon S3 のユーザー固有のフォルダにアクセス許可を付与するためのアクセスポリシーを示します。ポリシーは、Amazon S3 オブジェクトが `saml:namequalifier` と `saml:sub` の両方を含むプレフィックスを使用して特定されていることを前提としていまします。`Condition` 要素には、`saml:sub_type` が `persistent` に設定されていることを確認するテストが含まれることに注意してください。`transient`" に設定されている場合、ユーザーの `saml:sub` 値はセッションごとに異なる可能性があるため、値の組み合わせを使用してユーザー固有のフォルダを識別することはできません。
------
#### [ JSON ]
****
```
{
"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"}}
}
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
"arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
],
"Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
}
}
```
------
IdP からポリシーキーにアサーションをマッピングする方法については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。