OpenSearch Dashboards の SAML 認証 - Amazon OpenSearch サービス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

OpenSearch Dashboards の SAML 認証

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

Amazon Cognito または内部ユーザーデータベース を介して認証するのではなく、 OpenSearch Dashboards の SAML 認証を使用すると、サードパーティーの ID プロバイダーを使用して Dashboards にログインし、きめ細かなアクセスコントロールを管理し、データを検索して、可視化を構築できます。 OpenSearch サービスは、Okta、Keycloak、Active Directory フェデレーションサービス (ADFS)、Auth0、 などの SAML 2.0 標準を使用するプロバイダーをサポートしますAWS IAM Identity Center。

Dashboards の SAML 認証は、ウェブブラウザから OpenSearch Dashboards にアクセスするためだけに使用されます。SAML 認証情報では、 OpenSearch または APIs に直接 HTTP リクエストを行うことはできません

SAML 設定の概要

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

OpenSearch Dashboards のログインフローは、次の 2 つの形式のいずれかになります。

  • サービスプロバイダー (SP) が開始されている: Dashboards に移動します (例えば、https://my-domain.us-east-1.es.amazonaws.com/_dashboards)。これにより、ログイン画面にリダイレクトされます。ログイン後、ID プロバイダーはお客様を Dashboards にリダイレクトします。

  • ID プロバイダー (IdP ) によって開始された : ID プロバイダーに移動し、ログインして、アプリケーションディレクトリから OpenSearch Dashboards を選択します。

OpenSearch サービスは、SP 開始と IdP 開始の 2 つのシングルサインオン URLs を提供しますが、必要なのは目的の OpenSearch Dashboards ログインフローに一致するものだけです。

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

考慮事項

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

  • IdP メタデータファイルのサイズにより、SAML 認証の設定には AWS コンソールを使用することを強くお勧めします。

  • ドメインは、一度に 1 つの Dashboards 認証方法のみをサポートします。 OpenSearch Dashboards の 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/*" } ] }

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

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

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

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

ドメイン設定内の OpenSearch Dashboards/Kibana の SAML 認証で、SAML 認証を有効にするを選択します。

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

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

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

新しいドメインを作成中の場合、 OpenSearch サービスはまだサービスプロバイダーエンティティ ID または SSO URLs を生成できません。アイデンティティプロバイダーは、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 サービスから正しい値を取得し、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 Dashboards 内でのみ使用できます。

    例えば、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 Dashboards は 24 時間後にユーザーをログアウトします。この値は、新しい値を指定することで、60 から 1,440 (24 時間) までの任意の数値に設定できます。

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

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

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

URL を取得するには、ドメインを選択してから、[Actions] (アクション)、[Edit security configuration] (セキュリティ設定の編集) の順に選択します。 OpenSearch Dashboards/Kibana の SAML 認証では、正しいサービスプロバイダーエンティティ ID と SSO URLsを見つけることができます。値をコピーし、それらを使用してアイデンティティプロバイダーを設定することで、ステップ 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 がロードされたら、セキュリティ、ロール を選択します。次に、ロールをマッピングして、他のユーザーが OpenSearch Dashboards にアクセスできるようにします。

例えば、信頼できる同僚 jroeall_access および security_manager ロールにマッピングします。また、バックエンドロール analystsreadall および kibana_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": "/dashboards_user", "value": { "backend_roles": ["analysts"] } } ]

SP 開始認証と IdP 開始認証両方の設定

SP 開始認証と IdP 開始認証の両方を設定する場合は、ID プロバイダーを通じて設定する必要があります。例えば、Okta では、次のステップを実行できます。

  1. SAML アプリケーション内で、[General] (全般)、[SAML settings] (SAML 設定) に移動します。

  2. [Single sign on URL] (シングルサインオン URL) で、IdP 開始 SSO URL を指定します。例えば、「https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated」と入力します。

  3. [Allow this app to request other SSO URLs] (このアプリが他の SSO URL をリクエストすることを許可) を有効にします。

  4. [Requestable SSO URLs] (リクエスト可能な 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 では、すべての引用符と改行文字をエスケープする必要があります。例えば、<KeyDescriptor use="signing"> および改行の代わりに <KeyDescriptor use=\"signing\">\n を使用します。AWS CLI の使用方法の詳細については、「AWS CLI コマンドリファレンス」を参照してください。

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 では、すべての引用符と改行文字をエスケープする必要があります。例えば、<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 Dashboards と へのアクセスが許可されていることを確認します_plugins/_security/*。一般的に、きめ細かなアクセスコントロールを使用するドメインではオープンアクセスポリシーを使用することをお勧めします。

  • SAML の設定のステップについては、ID プロバイダーのドキュメントを参照してください。

ロールがありません: このユーザーには使用できるロールがありません。システム管理者に連絡してください。

認証に成功しましたが、ユーザーネームおよび SAML アサーションからのバックエンドロールはどのロールにもマッピングされていないため、許可がありません。これらのマッピングでは、大文字と小文字が区別されます。

SAML トレーサーのようなツールを使用して、SAML アサーションの内容を確認し、次の呼び出しを使用してロールマッピングを確認します。

GET _plugins/_security/api/rolesmapping

OpenSearch Dashboards にアクセスしようとすると、ブラウザは HTTP 500 エラーを継続的にリダイレクトまたは受信します。

このエラーは、SAML アサーションに合計約 1,500 文字の多数のロールが含まれている場合に発生します。例えば、平均の長さが 20 文字である 80 ロールを渡すと、ウェブブラウザの Cookie のサイズ制限を超える可能性があります。 OpenSearch バージョン 2.7 以降、SAML アサーションは最大 5000 文字のロールをサポートします。

ADFS からログアウトすることはできません。

ADFS では、 OpenSearch サービスがサポートしていないすべてのログアウトリクエストに署名する必要があります。IdP メタデータファイル<SingleLogoutService />から を削除して、 OpenSearch サービスが独自の内部ログアウトメカニズムを使用するように強制します。

Could not find entity descriptor for __PATH__.

Service へのメタデータ XML で提供される IdP のエンティティ ID OpenSearch は、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 を形式 <Kibana/OSDURL>/_opendistro/_security/saml/acs で設定した場合に発生します。代わりに、URL を形式 <Kibana/OSDURL>/_opendistro/_security/saml/acs/idpinitiated で設定します。

レスポンスは __PATH__ の代わりに __PATH__ で受信されました。

SAML レスポンスの宛先フィールドが次の URL 形式のいずれかと一致しません。

  • <Kibana/OSDURL>/_opendistro/_security/saml/acs

  • <Kibana/OSDURL>/_opendistro/_security/saml/acs/idpinitiated.

使用するログインフロー (SP 開始または IdP 開始) に応じて、 OpenSearch URLs の 1 つに一致する送信先フィールドに を入力します。

レスポンスには InResponseTo 属性がありますが、InResponseTo 属性は想定されていません。

SP 開始ログインフローで IdP 開始 URL を使用しています。代わりに、SP 開始 URL を使用してください。

SAML 認証の無効化

OpenSearch Dashboards の SAML 認証を無効にするには (コンソール)
  1. ドメインを選択し、[アクション] から [セキュリティ設定の編集] を選択します。

  2. [SAML 認証を有効にする] のチェックを外します。

  3. [変更の保存] をクリックします。

  4. ドメインの処理が終了したら、次のリクエストを用いてきめ細かなアクセスコントロールのロールマッピングを確認します。

    GET _plugins/_security/api/rolesmapping

    Dashboards の SAML 認証を無効にしても、SAML マスターユーザーネームおよび/または SAML マスターバックエンドロールのマッピングを削除しません。これらのマッピングを削除する場合は、内部ユーザーデータベース (有効な場合) を使用して Dashboards にログインするか、API を使用してそれらを削除します。

    PUT _plugins/_security/api/rolesmapping/all_access { "users": [ "master-user" ] }