SAML 設定の概要考慮事項 VPC ドメインの SAML 認証ドメインアクセスポリシーの変更 SP 開始認証または IdP 開始認証の設定 SP 開始認証と IdP 開始認証両方の設定 SAML 認証の設定 (AWS CLI)SAML 認証の設定 (設定 API)SAML のトラブルシューティング SAML 認証の無効化

ダッシュボードの OpenSearch SAML 認証

OpenSearch ダッシュボードの SAML 認証では、既存の ID プロバイダーを使用して、Elasticsearch 6.7 OpenSearch 以降を実行している Amazon OpenSearch Service ドメイン上のダッシュボードにシングルサインオン (SSO) を提供できます。SAML 認証を使用するには、きめ細かなアクセスコントロールを有効にする必要があります。

ダッシュボードの SAML 認証では、Amazon Cognito や内部ユーザーデータベースを介して認証するのではなく、サードパーティーの ID OpenSearch プロバイダーを使用してダッシュボードへのログイン、きめ細かなアクセス制御の管理、データの検索、視覚化の構築を行うことができます。 OpenSearch サービスは、Okta、Keycloak、アクティブディレクトリフェデレーションサービス (ADFS)、Auth0、などの SAML 2.0 標準を使用するプロバイダーをサポートします。 AWS IAM Identity Center

ダッシュボードの SAML 認証は、Web ブラウザーからダッシュボードにアクセスする場合のみです。 OpenSearch SAML 認証情報では、またはダッシュボード API に直接 HTTP リクエストを送信することはできません。 OpenSearch

SAML 設定の概要

このドキュメントは、ユーザーに既存の ID プロバイダーがあり、そのプロバイダーについてある程度の知識があることを前提としています。プロバイダの詳細な設定手順は提供できません。 OpenSearch ご使用のサービスドメインについてのみ提供できます。

OpenSearch ダッシュボードのログインフローには、次の 2 つの形式があります。

サービスプロバイダー (SP) が開始されている: Dashboards に移動します (例えば、https://my-domain.us-east-1.es.amazonaws.com/_dashboards)。これにより、ログイン画面にリダイレクトされます。ログイン後、ID プロバイダーはお客様を Dashboards にリダイレクトします。
ID プロバイダー (IdP) 開始:ID プロバイダーに移動してログインし、アプリケーションディレクトリから [ OpenSearch ダッシュボード] を選択します。

OpenSearch サービスには SP 起動と IdP 起動の 2 つのシングルサインオン URL がありますが、必要なのは、希望する Dashboards ログインフローと一致する URL だけです。 OpenSearch

どの認証タイプを使用するかにかかわらず、目的は ID プロバイダーを介してログインし、ユーザーネーム（必須）とバックエンドロール (オプションですが、推奨されます) を含む SAML アサーションを受け取ることです。この情報により、きめ細かなアクセスコントロールが、SAML ユーザーに許可を割り当てることができます。外部 ID プロバイダーでは、バックエンドロールは通常「ロール」または「グループ」と呼ばれます。

考慮事項

SAML 認証を設定するときは、以下を考慮してください。

IdP メタデータファイルのサイズにより、SAML 認証の設定には AWS コンソールを使用することを強くお勧めします。
ドメインは、一度に 1 つの Dashboards 認証方法のみをサポートします。 OpenSearch ダッシュボードの Amazon Cognito 認証が有効になっている場合は、SAML 認証を有効にする前に無効にする必要があります。
SAML で Network Load Balancer を使用する場合は、最初にカスタムエンドポイントを作成します。詳細については、「Amazon OpenSearch Service 用のカスタムエンドポイントの作成」を参照してください。

VPC ドメインの SAML 認証

SAML は、アイデンティティプロバイダーとサービスプロバイダー間の直接的な通信を必要としません。そのため、 OpenSearch ドメインがプライベート VPC 内でホストされている場合でも、 OpenSearch ブラウザがクラスターと ID プロバイダーの両方と通信できる限り、SAML を使用できます。ブラウザは、基本的にアイデンティティプロバイダーとサービスプロバイダーの仲介として機能します。SAML 認証フローを説明する便利な図表については、Okta のドキュメントを参照してください。

ドメインアクセスポリシーの変更

SAML 認証を設定する前に、ドメインアクセスポリシーを更新して SAML ユーザーがドメインにアクセスできるようにする必要があります。これを実行しない場合は、アクセス拒否エラーが表示されます。

次のドメインアクセスポリシーをお勧めします。これにより、ドメイン上のサブリソース (/*) にフルアクセスが付与されます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

ポリシーの制限を強化するには、IP アドレス条件をポリシーに追加します。この条件では、指定した IP アドレス範囲またはサブネットのみにアクセスを制限します。たとえば、次のポリシーでは 192.0.2.0/24 サブネットからのアクセスのみが許可されます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24"
          ]
        }
      },
      "Resource": "domain-arn/*"
    }
  ]
}

注記

オープンドメインのアクセスポリシーでは、ドメインできめ細かいアクセス制御を有効にする必要があります。有効にしないと、次のエラーが表示されます。

To protect domains with public access, a restrictive policy or fine-grained access control is required.

マスターユーザーまたは内部ユーザーに強固なパスワードが設定されている場合は、ポリシーを開いたままにしてきめ細かなアクセス制御を行うことは、セキュリティの観点から許容できる場合があります。詳細については、「Amazon OpenSearch Service でのきめ細かなアクセスコントロール」を参照してください。

SP 開始認証または IdP 開始認証の設定

以下の手順では、ダッシュボードの SP 開始認証または IdP 起動認証による SAML 認証を有効にする方法について説明します。 OpenSearch 両方を有効にするために必要な追加のステップについては、「SP 開始認証と IdP 開始認証の両方を有効にする」を参照してください。

ステップ 1: SAML 認証を有効にする

SAML 認証は、ドメインの作成中に有効化、または既存のドメインで [Actions] (アクション)、[Edit security configuration] (セキュリティ設定の編集) の順に選択することで有効化できます。以下のステップは、どちらを選択するかに応じて若干異なります。

ドメイン設定の [ダッシュボード/Kibana の SAML 認証] で [SAML 認証を有効にする] を選択します。 OpenSearch

ステップ 2: アイデンティティプロバイダーを設定する

SAML 認証をいつ設定しているかに応じて、以下のステップを実行します。

新しいドメインを作成している場合

新しいドメインを作成中の場合、 OpenSearch Service はまだサービスプロバイダーのエンティティ ID や SSO URL を生成できません。アイデンティティプロバイダーは、SAML 認証を適切に有効化するためにこれらの値を必要としますが、これらの値はドメインの作成後しか生成できません。ドメインの作成中にこの相互依存性を回避するには、IdP 設定に一時的な値を指定して必要なメタデータを生成し、ドメインがアクティブになった後でそれらを更新することができます。

カスタムエンドポイントを使用している場合は、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 プロバイダーを設定できます。例については、次のセクションを参照ください。

カスタムエンドポイントを使用していない場合は、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 認証を有効化している場合は、サービスプロバイダーのエンティティ ID と SSO URL の 1 つをコピーします。使用する URL のガイダンスについては、「SAML 設定の概要」を参照してください。

これらの値を使用して、アイデンティティプロバイダーを設定します。これはプロセスの最も複雑な部分ですが、残念ながら、用語とステップはプロバイダーによって大きく異なります。プロバイダーのドキュメントを参照してください。

例えば Okta では、SAML 2.0 ウェブアプリケーションを作成します。[Single sign on URL] (シングルサインオン URL) には、SSO URL を指定します。Audience URI (SP エンティティ ID) では、SP エンティティ ID を指定します。

Okta には、ユーザーおよびバックエンドロールではなく、ユーザーとグループがあります。[Group Attribute Statements] (グループ属性ステートメント) では、role を [Name] (名前) フィールドに、正規表現 .+ を [Filter] (フィルター) フィールドに追加することをお勧めします。このステートメントは、Okta の ID プロバイダーに、ユーザーの認証後に SAML アサーションの role フィールドの下に、すべてのユーザーグループを含めるよう指示します。

IAM アイデンティティセンターで、SP エンティティ ID をアプリケーション SAML オーディエンスとして指定します。また、次の属性マッピングも指定する必要があります: Subject=${user:name} と Role=${user:groups}

Auth0 では、通常のウェブアプリケーションを作成し、SAML 2.0 アドオンを有効にします。Keycloak では、クライアントを作成します。

ステップ 3: IdP メタデータをインポートする

ID プロバイダーを設定すると、IdP メタデータファイルが生成されます。この XML ファイルには、TLS 証明書、Single Sign-On エンドポイント、ID プロバイダーのエンティティ ID など、プロバイダーに関する情報が含まれています。

IdP メタデータファイルの内容をコピーし、 OpenSearch サービスコンソールの [IdP からのメタデータ] フィールドに貼り付けます。または、[XML ファイルからインポート] を選択し、ファイルをアップロードします。メタデータファイルは、次のように表示されます。


<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="entity-id" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>tls-certificate</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="idp-sso-url"/>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="idp-sso-url"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

ステップ 4: SAML フィールドを設定する

IdP メタデータを入力したら、 OpenSearch サービスコンソールで以下の追加フィールドを設定します。

[IdP entity ID] (IdP エンティティ ID) – メタデータファイルから entityID プロパティの値をコピーし、このフィールドにそれを貼り付けます。多くの ID プロバイダーは、この値も設定後の概要の一部として表示します。一部のプロバイダーは、それを「発行者」と呼んでいます。
SAML マスターユーザー名と SAML マスターバックエンドロール — 指定したユーザーまたはバックエンドロールには、クラスターへのフル権限 (新規マスターユーザーと同等) が付与されますが、これらの権限はダッシュボード内でのみ使用できます。 OpenSearch

例えば、Okta では、グループ admins に属しているユーザー jdoe がある可能性があります。jdoe を [SAML マスターユーザーネーム] フィールドに追加した場合、そのユーザーのみが完全な許可を受け取ります。admins を SAML マスターバックエンドロールフィールドに追加する場合は、admins グループに属するすべてのユーザーに完全な許可が付与されます。

注記
SAML アサーションの内容は、SAML マスターユーザーネームおよび SAML マスターロールに使用する文字列と正確に一致する必要があります。ID プロバイダーの中には、ユーザー名の前にプレフィックスを追加するものがあり、これが不一致の原因となることがあります。 hard-to-diagnose ID プロバイダーのユーザーインターフェイスで、jdoe を確認できる場合がありますが、SAML アサーションには auth0|jdoe が含まれている可能性があります。常に SAML アサーションからの文字列を使用します。

多くの ID プロバイダーでは、設定プロセス中にサンプルのアサーションを表示できます。また、SAML トレーサーは、実際のアサーションの内容を調べてトラブルシューティングするのに役立ちます。アサーションは次のようになります。


<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion ID="id67229299299259351343340162" IssueInstant="2020-09-22T22:03:08.633Z" Version="2.0"
  xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">idp-issuer</saml2:Issuer>
  <saml2:Subject>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData NotOnOrAfter="2020-09-22T22:08:08.816Z" Recipient="domain-endpoint/_dashboards/_opendistro/_security/saml/acs"/>
    </saml2:SubjectConfirmation>
  </saml2:Subject>
  <saml2:Conditions NotBefore="2020-09-22T21:58:08.816Z" NotOnOrAfter="2020-09-22T22:08:08.816Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>domain-endpoint</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>
  <saml2:AuthnStatement AuthnInstant="2020-09-22T19:54:37.274Z">
    <saml2:AuthnContext>
      <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
    </saml2:AuthnContext>
  </saml2:AuthnStatement>
  <saml2:AttributeStatement>
    <saml2:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
      <saml2:AttributeValue
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">GroupName Match Matches regex ".+" (case-sensitive)
      </saml2:AttributeValue>
    </saml2:Attribute>
  </saml2:AttributeStatement>
</saml2:Assertion>

ステップ 5: (オプション) 追加設定を実行する

[Additional settings] (その他の設定) で、次のオプションフィールドを設定します。

[Subject key] (件名キー) – このフィールドを空のままにしておいて、ユーザーネームの SAML アサーションの NameID エレメントを使用することができます。アサーションでこの標準エレメントを使用せず、代わりにユーザーネームをカスタム属性として含める場合は、ここでその属性を指定します。
[Roles key] (ロールキー) – バックエンドロール (推奨) を使用する場合は、このフィールドでアサーションからの属性 (role または group など) を指定します。これは、SAML トレーサーなど、どのツールが役立つかという別の状況です。
セッションの有効期間 — デフォルトでは、 OpenSearch ダッシュボードは 24 時間後にユーザーをログアウトさせます。この値は、新しい値を指定することで、60 から 1,440 (24 時間) までの任意の数値に設定できます。

設定に問題がなければ、ドメインを保存します。

ステップ 6: IdP URL を更新する

ドメインの作成中に SAML 認証を有効化した場合は、XML メタデータファイルを生成するために IdP 内で一時的な URL を指定する必要がありました。ドメインステータスが Active に変わったら、正しい URL を取得して IdP を変更できます。

URL を取得するには、ドメインを選択してから、[Actions] (アクション)、[Edit security configuration] (セキュリティ設定の編集) の順に選択します。 OpenSearch ダッシュボード/Kibana の SAML 認証では、正しいサービスプロバイダーのエンティティ ID と SSO URL を確認できます。値をコピーし、それらを使用してアイデンティティプロバイダーを設定することで、ステップ 2 で指定した一時的な URL を置き換えます。

ステップ 7: SAML ユーザーをロールにマップする

ドメインのステータスが [アクティブ] になり、IdP が正しく設定されたら、[ OpenSearch ダッシュボード] に移動します。

SP 開始の URL を選択した場合は、domain-endpoint/_dashboards に移動します。特定のテナントに直接ログインするには、URL に ?security_tenant=tenant-name を追加できます。
IdP 開始の URL を選択した場合は、ID プロバイダーのアプリケーションディレクトリに移動します。

どちらの場合も、SAML マスターユーザーまたは SAML マスターバックエンドロールに属しているユーザーとしてログインします。ステップ 7 からの例を続けるには、jdoe、または admins グループのメンバーとしてログインします。

OpenSearch ダッシュボードが読み込まれたら、[セキュリティ]、[ロール] を選択します。次に、ロールをマップして、 OpenSearch 他のユーザーがダッシュボードにアクセスできるようにします。

例えば、信頼できる同僚 jroe を all_access および security_manager ロールにマッピングします。また、バックエンドロール analysts を readall および opensearch_dashboards_user ロールにマッピングすることもできます。

OpenSearch ダッシュボードではなく 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 では、次のステップを実行できます。

SAML アプリケーション内で、[General] (全般)、[SAML settings] (SAML 設定) に移動します。
[Single sign on URL] (シングルサインオン URL) で、IdP 開始 SSO URL を指定します。例えば https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated です。
[Allow this app to request other SSO URLs] (このアプリが他の SSO URL をリクエストすることを許可) を有効にします。
[Requestable SSO URLs] (リクエスト可能な SSO URL) で、1 つ以上の SP 開始 SSO URL を追加します。例えば https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs です。

SAML 認証の設定 (AWS CLI)

AWS CLI 以下のコマンドは、 OpenSearch 既存のドメイン上のダッシュボードの 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 では、すべての引用符と改行文字をエスケープする必要があります。例えば、<KeyDescriptor use="signing"> および改行の代わりに <KeyDescriptor use=\"signing\">\n を使用します。の使用方法の詳細については AWS CLI、『AWS CLI コマンドリファレンス』を参照してください。

SAML 認証の設定 (設定 API)

設定 API への次のリクエストにより、 OpenSearch 既存のドメイン上のダッシュボードの 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 では、すべての引用符と改行文字をエスケープする必要があります。例えば、<KeyDescriptor use="signing"> および改行の代わりに <KeyDescriptor use=\"signing\">\n を使用します。設定 API の使用方法の詳細については、OpenSearch サービス API リファレンスをご覧ください。

SAML のトラブルシューティング

エラー	詳細
`リクエスト: '/some/path' は許可されていません。`	正しい SSO URL (ステップ 3) を ID プロバイダーに提供したことを確認します。
`SAML を有効にするには、有効な ID プロバイダーメタデータドキュメントを指定してください。`	IdP メタデータファイルは SAML 2.0 標準に準拠していません。検証ツールを使用してエラーをチェックします。
SAML 設定オプションは、コンソールでは表示されません。	最新のサービスソフトウェアに更新します。
`SAML 設定エラー: SAML 設定を取得中に問題が発生しました。設定を確認してください。`	この一般的なエラーは、さまざまな原因で発生することがあります。 ID プロバイダーに正しい SP エンティティ ID と SSO URL が指定されていることを確認します。 IdP メタデータファイルを再生成し、IdP エンティティ ID を確認します。更新されたメタデータを AWS コンソールに追加します。 OpenSearch `_plugins/_security/*`ドメインアクセスポリシーでダッシュボードとへのアクセスが許可されていることを確認してください。一般的に、きめ細かなアクセスコントロールを使用するドメインではオープンアクセスポリシーを使用することをお勧めします。 SAML の設定のステップについては、ID プロバイダーのドキュメントを参照してください。
`ロールがありません: このユーザーには使用できるロールがありません。システム管理者に連絡してください。`	認証に成功しましたが、ユーザーネームおよび SAML アサーションからのバックエンドロールはどのロールにもマッピングされていないため、許可がありません。これらのマッピングでは、大文字と小文字が区別されます。システム管理者は SAML-TRACER などのツールを使用して SAML アサーションの内容を検証し、次のリクエストを使用してロールマッピングを確認できます。 `GET _plugins/_security/api/rolesmapping`
ブラウザがダッシュボードにアクセスしようとすると、HTTP 500 エラーが継続的にリダイレクトされるか、受信されます。 OpenSearch	このエラーは、SAML アサーションに合計約 1,500 文字の多数のロールが含まれている場合に発生します。例えば、平均の長さが 20 文字である 80 ロールを渡すと、ウェブブラウザの Cookie のサイズ制限を超える可能性があります。 OpenSearch バージョン 2.7 以降、SAML アサーションは最大 5000 文字のロールをサポートします。
ADFS からログアウトすることはできません。	ADFS ではすべてのログアウトリクエストに署名が必要ですが、Service ではサポートされていません。 OpenSearch IdP `<SingleLogoutService />` メタデータファイルから削除して、 OpenSearch Service に独自の内部ログアウトメカニズムを強制的に使用させます。
`Could not find entity descriptor for __PATH__.`	OpenSearch サービスへのメタデータ XML で提供される IdP のエンティティ ID は、SAML 応答のエンティティ ID とは異なります。これを修正するには、それらが一致していることを確認してください。ドメインで [CW アプリケーションエラーログ] を有効にして、SAML 統合の問題をデバッグするためのエラーメッセージを見つけます。
`Signature validation failed. SAML response rejected.`	OpenSearch サービスは、メタデータ XML で提供された IdP の証明書を使用して SAML 応答の署名を検証できません。これは手動エラーであるか、または IdP が証明書をローテーションした可能性があります。 OpenSearch を通じてサービスに提供されたメタデータ XML 内の IdP からの最新の証明書を更新します AWS Management Console。
`__PATH__ is not a valid audience for this response.`	SAML レスポンスのオーディエンスフィールドがドメインエンドポイントと一致しません。このエラーを修正するには、ドメインエンドポイントと一致するように SP オーディエンスフィールドを更新します。カスタムエンドポイントを有効にしている場合は、オーディエンスフィールドがカスタムエンドポイントと一致する必要があります。ドメインで [CW アプリケーションエラーログ] を有効にして、SAML 統合の問題をデバッグするためのエラーメッセージを見つけます。
ブラウザは、レスポンスで `Invalid Request Id` ともに HTTP 400 エラーを受け取ります。	このエラーは通常、IdP 開始 URL を形式 `<DashboardsURL>/_opendistro/_security/saml/acs` で設定した場合に発生します。代わりに、URL を形式 `<DashboardsURL>/_opendistro/_security/saml/acs/idpinitiated` で設定します。
レスポンスは `__PATH__` の代わりに `__PATH__` で受信されました。	SAML レスポンスの宛先フィールドが次の URL 形式のいずれかと一致しません。 `<DashboardsURL>/_opendistro/_security/saml/acs` `<DashboardsURL>/_opendistro/_security/saml/acs/idpinitiated`. 使用するログインフロー (SP 開始または IdP 起動) に応じて、URL のいずれかに一致する宛先フィールドに入力します。 OpenSearch
レスポンスには `InResponseTo` 属性がありますが、`InResponseTo` 属性は想定されていません。	SP 開始ログインフローで IdP 開始 URL を使用しています。代わりに、SP 開始 URL を使用してください。

SAML 認証の無効化

ダッシュボード (コンソール) の SAML 認証を無効にするには OpenSearch

ドメインを選択し、[アクション] から [セキュリティ設定の編集] を選択します。
[SAML 認証を有効にする] のチェックを外します。
[変更の保存] を選択します。
ドメインの処理が終了したら、次のリクエストを用いてきめ細かなアクセスコントロールのロールマッピングを確認します。
```
GET _plugins/_security/api/rolesmapping
```
Dashboards の SAML 認証を無効にしても、SAML マスターユーザーネームおよび/または SAML マスターバックエンドロールのマッピングを削除しません。これらのマッピングを削除する場合は、内部ユーザーデータベース (有効な場合) を使用して Dashboards にログインするか、API を使用してそれらを削除します。
```
PUT _plugins/_security/api/rolesmapping/all_access
{
  "users": [
    "master-user"
  ]
}
```

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

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

ドキュメントの表記規則

OpenSearch サービスマネージド VPC エンドポイントの使用

OpenSearch Dashboards の Amazon Cognito 認証