翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # OpenSearch Dashboards の SAML 認証 OpenSearch Dashboards の SAML 認証を使用すると、既存の ID プロバイダーを使用して、OpenSearch または Elasticsearch 6.7 以降を実行している Amazon OpenSearch Service ドメインの Dashboards Single Sign-On (SSO) を提供できます。SAML 認証を使用するには、[きめ細かなアクセスコントロール](fgac.md)を有効にする必要があります。 [Amazon Cognito](cognito-auth.md) または[内部ユーザーデータベース](fgac.md#fgac-dashboards)を介して認証するのではなく、OpenSearch Dashboards の SAML 認証により、サードパーティーの ID プロバイダーを使用して Dashboards へのログイン、詳細なアクセスコントロールの管理、データの検索、視覚化の構築を行うことができます。OpenSearch Service は、Okta、Keycloak、Active Directory フェデレーションサービス (ADFS)、Auth0、 などの SAML 2.0 標準を使用するプロバイダーをサポートしています AWS IAM アイデンティティセンター。 Dashboards の SAML 認証は、ウェブブラウザから OpenSearch Dashboards にアクセスするためのものです。お客様のSAML認証情報では、OpenSearch または Dashboards API への直接 HTTP リクエストを行うことは*できません*。 ## SAML 設定の概要 このドキュメントは、ユーザーに既存の ID プロバイダーがあり、そのプロバイダーについてある程度の知識があることを前提としています。OpenSearch Service ドメインについてのみ、お客様のプロバイダーの詳細な設定手順は提供できません。 OpenSearch Dashboards のログインフローは、次の 2 つの形式のいずれかになります。 + **サービスプロバイダー (SP) が開始されている**: Dashboards に移動します (例えば、`https://my-domain.us-east-1.es.amazonaws.com/_dashboards`)。これにより、ログイン画面にリダイレクトされます。ログイン後、ID プロバイダーはお客様を Dashboards にリダイレクトします。 + **ID プロバイダー (IdP) 開始**: ID プロバイダーに移動してログインし、アプリケーションディレクトリから OpenSearch Dashboards を選択します。 OpenSearch Service には、SP 開始と IdP 開始の 2 つの Single Sign-On URL が用意されていますが、目的の OpenSearch Dashboards ログインフローに一致するもののみが必要です。 どの認証タイプを使用するかにかかわらず、目的は ID プロバイダーを介してログインし、ユーザーネーム (必須) と[バックエンドロール](fgac.md#fgac-concepts) (オプションですが、推奨されます) を含む SAML アサーションを受け取ることです。この情報により、[きめ細かなアクセスコントロール](fgac.md)が、SAML ユーザーに許可を割り当てることができます。外部 ID プロバイダーでは、バックエンドロールは通常「ロール」または「グループ」と呼ばれます。 ## 考慮事項 SAML 認証を設定するときは、以下を考慮してください。 + IdP メタデータファイルのサイズにより、SAML 認証の設定には AWS コンソールを使用することを強くお勧めします。 + ドメインは、一度に 1 つの Dashboards 認証方法のみをサポートします。[OpenSearch Dashboards の Amazon Cognito 認証](cognito-auth.md)が有効になっている場合は、SAML 認証を有効にする前に無効化しておく必要があります。 + SAML で Network Load Balancer を使用する場合は、最初にカスタムエンドポイントを作成します。詳細については、「[Amazon OpenSearch Service 用のカスタムエンドポイントの作成](customendpoint.md)」を参照してください。 + サービスコントロールポリシー (SCP) は、IAM 以外の ID (Amazon OpenSearch Serverless & SAML における SAML、あるいは Amazon OpenSearch Service の 基本的な内部ユーザー許可など) の場合には適用または評価されません。 ## VPC ドメインの SAML 認証 SAML は、アイデンティティプロバイダーとサービスプロバイダー間の直接的な通信を必要としません。したがって、OpenSearch ドメインがプライベート VPC 内でホストされている場合でも、ブラウザが OpenSearch クラスターとアイデンティティプロバイダーの両方と通信できる限り、SAML を使用できます。ブラウザは、基本的にアイデンティティプロバイダーとサービスプロバイダーの仲介として機能します。SAML 認証フローを説明する便利な図表については、[Okta のドキュメント](https://developer.okta.com/docs/concepts/saml/#planning-for-saml)を参照してください。 ## ドメインアクセスポリシーの変更 SAML 認証を設定する前に、ドメインアクセスポリシーを更新して SAML ユーザーがドメインにアクセスできるようにする必要があります。これを実行しない場合は、アクセス拒否エラーが表示されます。 次の[ドメインアクセスポリシー](ac.md#ac-types-resource)をお勧めします。これにより、ドメイン上のサブリソース (`/*`) にフルアクセスが付与されます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` ------ ポリシーをより制限的にするには、ポリシーに IP アドレス条件を追加できます。この条件は、指定された IP アドレス範囲またはサブネットにのみアクセスを制限します。例えば、次のポリシーでは、192.0.2.0/24 サブネットからのアクセスのみを許可します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` ------ **注記** オープンドメインアクセスポリシーでは、ドメインできめ細かなアクセスコントロールを有効にする必要があります。有効にしないと、次のエラーが表示されます。 `To protect domains with public access, a restrictive policy or fine-grained access control is required.` マスターユーザーまたは内部ユーザーが堅牢なパスワードで設定されている場合、きめ細かなアクセスコントロールの使用中にポリシーを開いたままにしておいても、セキュリティの観点から許容できることもあります。詳細については、「[Amazon OpenSearch Service のきめ細かなアクセスコントロール](fgac.md)」を参照してください。 ## SP 開始認証または IdP 開始認証の設定 以下のステップでは、OpenSearch Dashboards の SP 開始認証*または* IdP 開始認証を使用して SAML 認証を有効にする方法について説明します。両方を有効にするために必要な追加のステップについては、「[SP 開始認証と IdP 開始認証の両方を有効にする](#saml-idp-with-sp)」を参照してください。 ### ステップ 1: SAML 認証を有効にする SAML 認証は、ドメインの作成中に有効化、または既存のドメインで **[Actions]** (アクション)、**[Edit security configuration]** (セキュリティ設定の編集) の順に選択することで有効化できます。以下のステップは、どちらを選択するかに応じて若干異なります。 ドメイン設定内の **[SAML authentication for OpenSearch Dashboards/Kibana]** (OpenSearch Dashboards/Kibana 用の SAML 認証) で **[Enable SAML authentication]** (SAML 認証を有効化) を選択します。 ### ステップ 2: アイデンティティプロバイダーを設定する SAML 認証をいつ設定しているかに応じて、以下のステップを実行します。 #### 新しいドメインを作成している場合 新しいドメインを作成中の場合、OpenSearch Service はまだサービスプロバイダーのエンティティ ID または SSO URL を生成できません。アイデンティティプロバイダーは、SAML 認証を適切に有効化するためにこれらの値を必要としますが、これらの値はドメインの作成後しか生成できません。ドメインの作成中にこの相互依存性を回避するには、IdP 設定に一時的な値を指定して必要なメタデータを生成し、ドメインがアクティブになった後でそれらを更新することができます。 [カスタムエンドポイント](customendpoint.md)を使用している場合は、URL がどうなるかを推測できます。例えば、カスタムエンドポイントが `www.custom-endpoint.com` の場合、サービスプロバイダーのエンティティ ID は `www.custom-endpoint.com`、IdP 開始の SSO URL は `www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated`、SP 開始の SSO URL は `www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs` になります。ドメインを作成される前に、これらの値を使用して ID プロバイダーを設定できます。例については、次のセクションを参照ください。 **注記** HTTP リクエストの FQDN は SAML リクエストの FQDN とは異なるため、デュアルスタックエンドポイントでサインインすることはできません。OpenSearch 管理者は、デュアルスタックエンドポイントを使用してサインインする場合は、カスタムエンドポイントを設定し、CNAME 値をデュアルスタックエンドポイントに設定する必要があります。 カスタムエンドポイントを使用していない場合は、IdP に*一時的*な値を入力して必要なメタデータを生成し、ドメインがアクティブになった後でそれらを更新することができます。 例えば、Okta では、**[Single sign on URL]** (シングルサインオン URL) と **[Audience URI (SP Entity ID)]** (オーディエンス URI (SP エンティティ ID) フィールドに `https://temp-endpoint.amazonaws.com` を入力できます。そうすることで、メタデータの生成が可能になります。その後、ドメインがアクティブになったら、OpenSearch Service から正しい値を取得して、Okta でそれらを更新できます。手順については、「[ステップ 6: IdP URL を更新する](#saml-update-urls)」を参照してください。 #### 既存のドメインを編集している場合 既存のドメインで SAML 認証を有効化している場合は、サービスプロバイダーのエンティティ ID と SSO URL の 1 つをコピーします。使用する URL のガイダンスについては、「[SAML 設定の概要](#saml-overview)」を参照してください。 ![\[Service provider entity ID and SSO URLs for SAML authentication configuration.\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/SAML.png) これらの値を使用して、アイデンティティプロバイダーを設定します。これはプロセスの最も複雑な部分ですが、残念ながら、用語とステップはプロバイダーによって大きく異なります。プロバイダーのドキュメントを参照してください。 例えば Okta では、SAML 2.0 ウェブアプリケーションを作成します。**[Single sign on URL]** (シングルサインオン URL) には、SSO URL を指定します。**Audience URI (SP エンティティ ID)** では、SP エンティティ ID を指定します。 Okta には、ユーザーおよびバックエンドロールではなく、ユーザーとグループがあります。**[Group Attribute Statements]** (グループ属性ステートメント) では、`role` を **[名前]** フィールドに、正規表現 `.+` を **[フィルター]** フィールドに追加することをお勧めします。このステートメントは、Okta の ID プロバイダーに、ユーザーの認証後に SAML アサーションの `role` フィールドの下に、すべてのユーザーグループを含めるよう指示します。 IAM アイデンティティセンターで、SP エンティティ ID を**アプリケーション SAML オーディエンス**として指定します。また、次の[属性マッピング](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html)も指定する必要があります: `Subject=${user:subject}:format=unspecified` と `Role=${user:groups}:format=uri` Auth0 では、通常のウェブアプリケーションを作成し、SAML 2.0 アドオンを有効にします。Keycloak では、クライアントを作成します。 ### ステップ 3: IdP メタデータをインポートする ID プロバイダーを設定すると、IdP メタデータファイルが生成されます。この XML ファイルには、TLS 証明書、Single Sign-On エンドポイント、ID プロバイダーのエンティティ ID など、プロバイダーに関する情報が含まれています。 IdP メタデータファイルの内容をコピーし、OpenSearch Service コンソールの [**IdP からのメタデータ**] フィールドにそれを貼り付けます。または、[**XML ファイルからインポート**] を選択し、ファイルをアップロードします。メタデータファイルは、次のように表示されます。 ``` tls-certificate urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ``` ### ステップ 4: SAML フィールドを設定する IdP メタデータを入力したら、OpenSearch Service コンソールで以下の追加フィールドを設定します。 + **[IdP entity ID]** (IdP エンティティ ID) – メタデータファイルから `entityID` プロパティの値をコピーし、このフィールドにそれを貼り付けます。多くの ID プロバイダーは、この値も設定後の概要の一部として表示します。一部のプロバイダーは、それを「発行者」と呼んでいます。 + **[SAML master username]** (SAML マスターユーザー名) と **[SAML master backend role]** (SAML マスターバックエンドロール) – 指定するユーザーおよび/またはロールには、クラスターに対する完全な許可が付与されます。これは[新しいマスターユーザー](fgac.md#fgac-more-masters)と同等ですが、これらの許可を OpenSearch Dashboards 外で使用することはできません。 例えば、Okta では、グループ `admins` に属しているユーザー `jdoe` がある可能性があります。`jdoe` を [**SAML マスターユーザーネーム**] フィールドに追加した場合、そのユーザーのみが完全な許可を受け取ります。`admins` を SAML マスターバックエンドロールフィールドに追加する場合は、`admins` グループに属するすべてのユーザーに完全な許可が付与されます。 **注記** SAML アサーションの内容は、SAML マスターユーザーネームおよび SAML マスターロールに使用する文字列と正確に一致する必要があります。一部の ID プロバイダーは、ユーザーネームの前にプレフィックスを追加するので、診断が難しいミスマッチを引き起こす可能性があります。ID プロバイダーのユーザーインターフェイスで、`jdoe` を確認できる場合がありますが、SAML アサーションには `auth0|jdoe` が含まれている可能性があります。常に SAML アサーションからの文字列を使用します。 多くの ID プロバイダーでは、設定プロセス中にサンプルのアサーションを表示できます。また、[SAML トレーサー](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)は、実際のアサーションの内容を調べてトラブルシューティングするのに役立ちます。アサーションは次のようになります。 ``` idp-issuer username domain-endpoint urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport GroupName Match Matches regex ".+" (case-sensitive) ``` ### ステップ 5: (オプション) 追加設定を実行する **[Additional settings]** (その他の設定) で、次のオプションフィールドを設定します。 + **[Subject key]** (件名キー) – このフィールドを空のままにしておいて、ユーザーネームの SAML アサーションの `NameID` エレメントを使用することができます。アサーションでこの標準エレメントを使用せず、代わりにユーザーネームをカスタム属性として含める場合は、ここでその属性を指定します。 + **[Roles key]** (ロールキー) – バックエンドロール (推奨) を使用する場合は、このフィールドでアサーションからの属性 (`role` または `group` など) を指定します。これは、[SAML トレーサー](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)など、どのツールが役立つかという別の状況です。 + **[Session time to live]** (セッションの有効時間) – デフォルトで、OpenSearch Dashboards は 24 時間後にユーザーをログアウトします。この値は、新しい値を指定することで、60 から 1,440 (24 時間) までの任意の数値に設定できます。 設定に問題がなければ、ドメインを保存します。 ### ステップ 6: IdP URL を更新する [ドメインの作成中に SAML 認証を有効化](#saml-configure-new)した場合は、XML メタデータファイルを生成するために IdP 内で一時的な URL を指定する必要がありました。ドメインステータスが `Active` に変わったら、正しい URL を取得して IdP を変更できます。 URL を取得するには、ドメインを選択してから、**[Actions]** (アクション)、**[Edit security configuration]** (セキュリティ設定の編集) の順に選択します。**[SAML authentication for OpenSearch Dashboards/Kibana]** (OpenSearch Dashboards/Kibana 用の SAML 認証) で、正しいサービスプロバイダーのエンティティ ID と SSO URL を見つけることができます。値をコピーし、それらを使用してアイデンティティプロバイダーを設定することで、ステップ 2 で指定した一時的な URL を置き換えます。 ### ステップ 7: SAML ユーザーをロールにマップする ドメインのステータスがアクティブになり、IdP が正しく設定されたら、OpenSearch Dashboards に移動します。 + SP 開始の URL を選択した場合は、`domain-endpoint/_dashboards` に移動します。特定のテナントに直接ログインするには、URL に `?security_tenant=tenant-name` を追加できます。 + IdP 開始の URL を選択した場合は、ID プロバイダーのアプリケーションディレクトリに移動します。 どちらの場合も、SAML マスターユーザーまたは SAML マスターバックエンドロールに属しているユーザーとしてログインします。ステップ 7 からの例を続けるには、`jdoe`、または `admins` グループのメンバーとしてログインします。 OpenSearch Dashboards がロードされたら、**[Security]** (セキュリティ)、**[Roles]** (ロール) の順に選択します。次に、[ロールをマップ](fgac.md#fgac-mapping)して、他のユーザーが OpenSearch Dashboards にアクセスできるようにします。 例えば、信頼できる同僚 `jroe` を `all_access` および `security_manager` ロールにマッピングします。また、バックエンドロール `analysts` を `readall` および `opensearch_dashboards_user` ロールにマッピングすることもできます。 OpenSearch Dashboards の代わりに API を使用したい場合は、以下のサンプルリクエストを参照してください。 ``` PATCH _plugins/_security/api/rolesmapping [ { "op": "add", "path": "/security_manager", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/all_access", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/readall", "value": { "backend_roles": ["analysts"] } }, { "op": "add", "path": "/opensearch_dashboards_user", "value": { "backend_roles": ["analysts"] } } ] ``` ## SP 開始認証と IdP 開始認証両方の設定 SP 開始認証と IdP 開始認証の両方を設定する場合は、ID プロバイダーを通じて設定する必要があります。例えば、Okta では、次のステップを実行できます。 1. SAML アプリケーション内で、**[General]** (全般)、**[SAML settings]** (SAML 設定) に移動します。 1. **[シングルサインオン URL]** で、*IdP* 開始 SSO URL を指定します。例えば、`https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated`。 1. **[Allow this app to request other SSO URLs]** (このアプリが他の SSO URL をリクエストすることを許可) を有効にします。 1. **[リクエスト可能な SSO URL]** で、1 つ以上の *SP 開始* SSO URL を追加します。例えば、`https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs`。 ## SAML 認証の設定 (AWS CLI) 次の AWS CLI コマンドは、既存のドメインで OpenSearch Dashboards の SAML 認証を有効にします。 ``` aws opensearch update-domain-config \ --domain-name my-domain \ --advanced-security-options '{"SAMLOptions":{"Enabled":true,"MasterUserName":"my-idp-user","MasterBackendRole":"my-idp-group-or-role","Idp":{"EntityId":"entity-id","MetadataContent":"metadata-content-with-quotes-escaped"},"RolesKey":"optional-roles-key","SessionTimeoutMinutes":180,"SubjectKey":"optional-subject-key"}}' ``` メタデータ XML では、すべての引用符と改行文字をエスケープする必要があります。例えば、`` および改行の代わりに `\n` を使用します。 AWS CLIの使用方法の詳細については、「[AWS CLI コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/)」を参照してください。 ## SAML 認証の設定 (設定 API) 設定 API への次のリクエストにより、既存のドメイン上の OpenSearch Dashboards の SAML 認証を有効にします。 ``` POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config { "AdvancedSecurityOptions": { "SAMLOptions": { "Enabled": true, "MasterUserName": "my-idp-user", "MasterBackendRole": "my-idp-group-or-role", "Idp": { "EntityId": "entity-id", "MetadataContent": "metadata-content-with-quotes-escaped" }, "RolesKey": "optional-roles-key", "SessionTimeoutMinutes": 180, "SubjectKey": "optional-subject-key" } } } ``` メタデータ XML では、すべての引用符と改行文字をエスケープする必要があります。例えば、`` および改行の代わりに `\n` を使用します。設定 API の使用方法の詳細については、「[OpenSearch Service API Reference](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_Welcome.html)」(OpenSearch Service API リファレンス) を参照してください。 ## SAML のトラブルシューティング | エラー | 詳細 | | --- | --- | | リクエスト: '*/some/path*' は許可されていません。 | 正しい [SSO URL](#saml-enable) (ステップ 3) を ID プロバイダーに提供したことを確認します。 | | SAML を有効にするには、有効な ID プロバイダーメタデータドキュメントを指定してください。 | IdP メタデータファイルは SAML 2.0 標準に準拠していません。検証ツールを使用してエラーをチェックします。 | | SAML 設定オプションは、コンソールでは表示されません。 | 最新の[サービスソフトウェア](service-software.md)に更新します。 | | SAML 設定エラー: SAML 設定を取得中に問題が発生しました。設定を確認してください。 | この一般的なエラーは、さまざまな原因で発生することがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/saml.html) | | ロールがありません: このユーザーには使用できるロールがありません。システム管理者に連絡してください。 | 認証に成功しましたが、ユーザーネームおよび SAML アサーションからのバックエンドロールはどのロールにもマッピングされていないため、許可がありません。これらのマッピングでは、大文字と小文字が区別されます。 システム管理者は、[SAML トレーサー](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)のようなツールを使用して、SAML アサーションの内容を確認し、次のリクエストを使用してロールマッピングを確認します。 
GET _plugins/_security/api/rolesmapping
| | OpenSearch Dashboards にアクセスしようとすると、ブラウザが HTTP 500 エラーを継続的にリダイレクトまたは受け取ります。 | このエラーは、SAML アサーションに合計約 1,500 文字の多数のロールが含まれている場合に発生します。例えば、平均の長さが 20 文字である 80 ロールを渡すと、ウェブブラウザの Cookie のサイズ制限を超える可能性があります。OpenSearch バージョン 2.7 以降、SAML アサーションは最大 5,000 文字のロールをサポートします。 | | ADFS からログアウトすることはできません。 | ADFS では、OpenSearch Service がサポートしていないすべてのログアウトリクエストに署名する必要があります。IdP メタデータファイルから `` を削除して、OpenSearch Service が独自の内部ログアウトメカニズムを使用するように強制します。 | | `Could not find entity descriptor for __PATH__.` | OpenSearch Service へのメタデータ XML で提供される IdP のエンティティ ID が、SAML レスポンスのエンティティ ID とは異なります。これを修正するには、それらが一致していることを確認してください。ドメインで **[CW アプリケーションエラーログ]** を有効にして、SAML 統合の問題をデバッグするためのエラーメッセージを見つけます。 | | `Signature validation failed. SAML response rejected.` | OpenSearch Service は、メタデータ XML で提供された IdP の証明書を使用して SAML レスポンスの署名を検証できません。これは手動エラーであるか、または IdP が証明書をローテーションした可能性があります。 AWS マネジメントコンソール を通じて OpenSearch Service に提供されるメタデータ XML 内の IdP からの最新の証明書を更新します。 | | `__PATH__ is not a valid audience for this response.` | SAML レスポンスのオーディエンスフィールドがドメインエンドポイントと一致しません。このエラーを修正するには、ドメインエンドポイントと一致するように SP オーディエンスフィールドを更新します。カスタムエンドポイントを有効にしている場合は、オーディエンスフィールドがカスタムエンドポイントと一致する必要があります。ドメインで **[CW アプリケーションエラーログ]** を有効にして、SAML 統合の問題をデバッグするためのエラーメッセージを見つけます。 | | ブラウザは、レスポンスで `Invalid Request Id` ともに HTTP 400 エラーを受け取ります。 | このエラーは通常、IdP 開始 URL を形式 `/_opendistro/_security/saml/acs` で設定した場合に発生します。代わりに、URL を形式 `/_opendistro/_security/saml/acs/idpinitiated` で設定します。 | | レスポンスは `__PATH__` の代わりに `__PATH__` で受信されました。 | SAML レスポンスの宛先フィールドが次の URL 形式のいずれかと一致しません。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/saml.html) 使用するログインフロー (SP 開始または IdP 開始) に応じて、OpenSearch URL のいずれかと一致する宛先フィールドに入力します。 | | レスポンスには `InResponseTo` 属性がありますが、`InResponseTo` 属性は想定されていません。 | SP 開始ログインフローで IdP 開始 URL を使用しています。代わりに、SP 開始 URL を使用してください。 | ## SAML 認証の無効化 **OpenSearch Dashboards の SAML 認証を無効にするには (コンソール)** 1. ドメインを選択し、[**アクション**] から [**セキュリティ設定の編集**] を選択します。 1. [**SAML 認証を有効にする**] のチェックを外します。 1. **[Save changes]** (変更の保存) をクリックします。 1. ドメインの処理が終了したら、次のリクエストを用いてきめ細かなアクセスコントロールのロールマッピングを確認します。 ``` GET _plugins/_security/api/rolesmapping ``` Dashboards の SAML 認証を無効にしても、SAML マスターユーザーネームおよび/または SAML マスターバックエンドロールのマッピングを削除*しません*。これらのマッピングを削除する場合は、内部ユーザーデータベース (有効な場合) を使用して Dashboards にログインするか、API を使用してそれらを削除します。 ``` PUT _plugins/_security/api/rolesmapping/all_access { "users": [ "master-user" ] } ```