User authentication - Elastic StackでのSAMLシングルサインオンの設定（Configuring SAML single-sign-on on the Elastic Stack）

Elastic StackでのSAMLシングルサインオンの設定
アイデンティティプロバイダー
SAML認証のためのElasticsearchの設定
SPメタデータの生成
- コンソール
ロールマッピングの設定
ユーザーメタデータ
Kibanaの設定
- Yaml
KibanaでのSAMLおよび基本認証のサポート
- Yaml
複数のKibanaインスタンスの運用
- Yaml
SAMLレルム設定のトラブルシューティング
KibanaなしのSAML

Elastic StackでのSAMLシングルサインオンの設定

Elastic Stackは、Elasticsearchをバックエンドサービスとして使用してKibanaへのSAMLシングルサインオン（SSO）をサポートしています。SAML用語では、Elastic Stackはサービスプロバイダーとして機能しています。

SAMLシングルサインオンを有効にするために必要なもう1つのコンポーネントはアイデンティティプロバイダーであり、これはあなたの資格情報を処理し、ユーザーの実際の認証を行うサービスです。

KibanaへのSSOの設定に興味がある場合は、Elasticsearchにアイデンティティプロバイダーに関する情報を提供し、Elastic Stackをそのアイデンティティプロバイダー内で既知のサービスプロバイダーとして登録する必要があります。また、KibanaでSAML認証プロバイダーを有効にするために必要な設定変更もいくつかあります。

KibanaのSAMLサポートは、そのKibanaインスタンスのユーザーにとって主要（または唯一）の認証方法になることを前提に設計されています。KibanaでSAML認証を有効にすると、ログインを試みるすべてのユーザーに影響します。Kibanaの設定セクションでは、これがどのように機能するかについての詳細が提供されています。

アイデンティティプロバイダー

Elastic Stackは、SAML 2.0 WebブラウザSSOおよびSAML 2.0 シングルログアウトプロファイルをサポートし、少なくともSAML 2.0 WebブラウザSSOプロファイルをサポートする任意のアイデンティティプロバイダー（IdP）と統合できます。Microsoft Active Directory Federation Services（ADFS）[https://www.elastic.co/blog/how-to-configure-elasticsearch-saml-authentication-with-adfs]、Azure Active Directory（AAD）[https://www.elastic.co/blog/saml-based-single-sign-on-with-elasticsearch-and-azure-active-directory]、およびOkta[https://www.elastic.co/blog/how-to-set-up-okta-saml-login-kibana-elastic-cloud]など、いくつかの人気のあるIdP実装でテストされています。

このガイドは、既存のIdPがあり、Kibanaをサービスプロバイダーとして追加したいと仮定しています。

Elastic Stackは、IdPの機能と特徴を定義するXML形式の標準SAML メタデータドキュメントを使用します。このドキュメントは、IdP管理インターフェース内でダウンロードまたは生成できるはずです。

IdPメタデータドキュメントをダウンロードし、各Elasticsearchノードのconfigディレクトリに保存します。このガイドの目的のために、config/saml/idp-metadata.xmlとして保存していると仮定します。

IdPには、最も一般的にエンティティID（SAML用語）として表現される識別子が割り当てられています。管理インターフェースでこれが何であるかを確認できるか、メタデータドキュメントを読んで見つける必要があるかもしれません - EntityDescriptor要素のentityID属性を探してください。

ほとんどのIdPは、Elastic Stackが必要とするすべての機能を備えた適切なメタデータファイルを提供し、以下に記載された設定手順のみが必要です。完全性のために、Elastic StackがIdPのメタデータに対して持つ最小要件は次のとおりです：

Elasticsearchの設定に一致するentityIDを持つ<EntityDescriptor>
SAML 2.0プロトコルをサポートする<IDPSSODescriptor>（urn:oasis:names:tc:SAML:2.0:protocol）。
署名用に設定された少なくとも1つの<KeyDescriptor>（つまり、use="signing"を持つか、useが指定されていない）
HTTP-Redirectのバインディングを持つ<SingleSignOnService>（urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect）
シングルログアウトをサポートする場合、HTTP-Redirectのバインディングを持つ<SingleLogoutService>（urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect）

Elastic Stackは、IdPからのすべてのメッセージが署名されていることを要求します。認証<Response>メッセージの場合、署名は応答自体または個々のアサーションに適用できます。<LogoutRequest>メッセージの場合、メッセージ自体は署名されている必要があり、署名はHTTP-Redirectバインディングで要求されるようにURLパラメータとして提供される必要があります。

SAML認証のためのElasticsearchの設定

ElasticsearchでSAML認証を有効にするための設定手順は5つあります：

1. HTTP用のSSL/TLSを有効にする
2. トークンサービスを有効にする
3. 1つ以上のSAMLレルムを作成する
4. ロールマッピングを設定する
5. アイデンティティプロバイダーで使用するためのSAMLメタデータファイルを生成する（オプション）

HTTP用のTLSを有効にする

Elasticsearchクラスターが本番モードで動作している場合、SAML認証を有効にする前にHTTPインターフェースをSSL/TLSを使用するように設定する必要があります。

詳細については、ElasticsearchのHTTPクライアント通信を暗号化するを参照してください。

トークンサービスを有効にする

ElasticsearchのSAML実装は、Elasticsearchトークンサービスを利用します。このサービスは、HTTPインターフェースでTLSを設定すると自動的に有効になり、次の内容をelasticsearch.ymlファイルに含めることで明示的に設定できます：

Yaml

xpack.security.authc.token.enabled: true

SAMLレルムを作成する

SAML認証は、Elasticsearchの認証チェーン内にSAMLレルムを設定することで有効になります。

このレルムにはいくつかの必須設定と多数のオプション設定があります。利用可能な設定は、セキュリティ設定で詳細に説明されています。たとえば、SAMLレルム設定、SAMLレルム署名設定、SAMLレルム暗号化設定、SAMLレルムSSL設定。このガイドでは、最も一般的な設定を説明します。

次の内容をelasticsearch.yml設定ファイルに追加してレルムを作成します。各設定値については以下で説明します。

Yaml

xpack.security.authc.realms.saml.saml1:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.example.com/"
  sp.acs: "https://kibana.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."

SAMLはKibanaを介して認証する際に使用されますが、Elasticsearch REST APIに直接認証するための効果的な手段ではありません。このため、APIクライアント用に認証チェーンにネイティブレルムなどの少なくとも1つの追加レルムを含めることをお勧めします。

上記の例で使用されている設定値は次のとおりです：

xpack.security.authc.realms.saml.saml1
これは、
“saml1”という名前の新しいsaml認証レルムを定義します。レルムについての詳細はレルムを参照してください。
order
レルムチェーン内のレルムの順序。順序が低いレルムは優先度が高く、最初に参照されます。ファイル、ネイティブ、LDAP、Active Directoryなどのパスワードベースのレルムには最低の順序（最高の優先度）を付与し、次にSAMLやOpenID ConnectなどのSSOレルムを続けることをお勧めします。同じタイプの複数のレルムがある場合、最も頻繁にアクセスされるレルムに最低の順序を付与して最初に参照されるようにします。
idp.metadata.path
これは、アイデンティティプロバイダーのために保存したメタデータファイルへのパスです。ここに入力するパスは、config/ディレクトリに対して相対的です。Elasticsearchはこのファイルの変更を自動的に監視し、更新されるたびに設定を再読み込みします。
idp.entity_id
これは、IdPが使用する識別子（SAMLエンティティID）です。メタデータファイル内のentityID属性と一致する必要があります。
sp.entity_id
これは、URIとして表現されたKibanaインスタンスの一意の識別子です。IdP内でKibanaをサービスプロバイダーとして追加する際にこの値を使用します。KibanaインスタンスのベースURLをエンティティIDとして使用することをお勧めします。
sp.acs
アサーションコンシューマサービス（ACS）エンドポイントは、IdPからの認証メッセージを受け入れるKibana内のURLです。このACSエンドポイントは、SAML HTTP-POSTバインディングのみをサポートします。これは、KibanaにログインしようとしているユーザーのWebブラウザからアクセス可能なURLである必要があり、ElasticsearchやIdPから直接アクセス可能である必要はありません。正しい値は、Kibanaをどのようにインストールしたかやプロキシが関与しているかによって異なる場合がありますが、通常は${kibana-url}/api/security/saml/callbackで、${kibana-url}はKibanaインスタンスのベースURLです。
sp.logout
これは、IdPからのログアウトメッセージを受け入れるKibana内のURLです。sp.acs URLと同様に、Webブラウザからアクセス可能である必要がありますが、ElasticsearchやIdPから直接アクセス可能である必要はありません。正しい値は、Kibanaをどのようにインストールしたかやプロキシが関与しているかによって異なる場合がありますが、通常は${kibana-url}/logoutで、${kibana-url}はKibanaインスタンスのベースURLです。
attributes.principal
属性マッピングを参照してください。
attributes.groups
属性マッピングを参照してください。

属性マッピング

ユーザーがアイデンティティプロバイダーを介してKibanaに接続すると、アイデンティティプロバイダーはユーザーに関するSAMLアサーションを提供します。このアサーションには、ユーザーがIdPに正常に認証されたことを示す認証ステートメントと、ユーザーの属性を含む1つ以上の属性ステートメントが含まれます。

これらの属性には、次のようなものが含まれる場合があります：

ユーザーのユーザー名
ユーザーのメールアドレス
ユーザーのグループまたはロール

SAMLの属性は、urn:oid:0.9.2342.19200300.100.1.1やhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/upnのようなURIを使用して名前付けされ、1つ以上の値が関連付けられています。

これらの属性識別子はIdPによって異なり、ほとんどのIdPはURIとその関連値をカスタマイズする方法を提供しています。

Elasticsearchは、これらの属性を使用してログインしたユーザーに関する情報を推測し、ロールマッピング（以下）に使用できます。

これらの属性が有用であるためには、ElasticsearchとIdPが属性の名前に共通の値を持つ必要があります。これは手動で行われ、IdPとSAMLレルムを設定して、各論理ユーザー属性に対して同じURI名を使用します。

これらのSAML属性を設定するための推奨手順は次のとおりです：

1. IdPに相談して、どのユーザー属性を提供できるかを確認します。これはプロバイダーによって大きく異なりますが、ドキュメントやローカル管理者からリストを取得できるはずです。
2. Elasticsearchがサポートするユーザー属性のリストを読み、どれが有用であり、IdPによって提供できるかを決定します。最低限、principal属性が必要です。
3. IdPを設定して、これらの属性をKibana SAMLサービスプロバイダーに「リリース」するようにします。このプロセスはプロバイダーによって異なります - 一部はこれに対するユーザーインターフェースを提供し、他のプロバイダーは設定ファイルを編集する必要があるかもしれません。通常、IdP（またはローカル管理者）は、各属性に使用するURIについての提案を持っています。これらの提案をそのまま受け入れることができます。Elasticsearchサービスは完全に設定可能であり、特定のURIを使用する必要はありません。
4. ElasticsearchのSAMLレルムを設定して、Elasticsearchユーザー属性（以下のリストを参照）を、IdPで設定したURIに関連付けます。上記の例では、principalおよびgroups属性を設定しました。

特別な属性名

一般的に、Elasticsearchは属性の設定値がurn:oid:0.9.2342.19200300.100.1.1のようなURIであることを期待していますが、使用できる追加の名前もいくつかあります：

nameid
これは、SAML NameID値（すべての先頭および末尾の空白が削除される）をSAML属性の代わりに使用します。SAML NameID要素は、IdPがそのアサーションの主題を特定するために使用できるオプションのフィールドですが、頻繁に提供されます。場合によっては、NameIDはIdP内でのユーザーのログイン識別子（ユーザー名）に関連することがありますが、多くの場合、IdPの外部では明らかに意味を持たない内部生成識別子になります。
nameid:persistent
これは、SAML NameID値（すべての先頭および末尾の空白が削除される）を使用しますが、NameID形式がurn:oasis:names:tc:SAML:2.0:nameid-format:persistentの場合のみです。SAML NameID要素には、提供された名前の意味を示すオプションのFormat属性があります。IdPは、各セッションに対して新しい識別子を提示する「一時的」NameIDで構成されることが一般的です。一時的NameIDを属性マッピングの一部として使用することはあまり有用ではないため、「nameid:persistent」属性名を安全メカニズムとして使用して、永続的な値を持たないNameIDからマッピングを試みるとエラーが発生します。

アイデンティティプロバイダーは、特定の形式のNameIDをリリースするように静的に構成されるか、SPの要件に準拠しようとするように構成されることがあります。SPは、NameIDPolicyと呼ばれる要素を使用して、認証リクエストの一部としてその要件を宣言します。これが必要な場合、IdPが特定の形式のNameIDをリリースするように要求するために、nameid_formatという名前の関連する設定を設定できます。

friendlyName
SAML属性には、URIベースの名前に加えてfriendlyNameがある場合があります。たとえば、urn:oid:0.9.2342.19200300.100.1.1という名前の属性には、uidというfriendlyNameがあるかもしれません。これらのfriendlyNameを属性マッピング内で使用できますが、URIベースの名前を使用することをお勧めします。friendlyNameは標準化されておらず、必須ではありません。

以下の例では、principalに対して永続的なnameidを使用し、ユーザーのグループに対してfriendlyName「roles」を持つ属性を設定します。

Yaml

xpack.security.authc.realms.saml.saml1:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.example.com/"
  sp.acs: "https://kibana.example.com/api/security/saml/callback"
  attributes.principal: "nameid:persistent"
  attributes.groups: "roles"
  nameid_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"

Elasticsearchユーザー属性

ElasticsearchのSAMLレルムは、認証されたユーザーの次の属性にSAML attributesをマッピングするように設定できます：

principal
（必須）これは、このレルムに対して認証されたユーザーに適用されるユーザー名です。principalは、Elasticsearchの監査ログなどの場所に表示されます。
groups
（推奨）IdPのグループまたはロールの概念をユーザーのElasticsearch権限の基礎として使用したい場合は、この属性でマッピングする必要があります。groupsは、ロールマッピングルールに直接渡されます。
一部のIdPは、groupsリストを単一の値、カンマ区切りの文字列として送信するように構成されています。このSAML属性をElasticsearchレルムのattributes.groups設定にマッピングするには、attribute_delimiters.group設定を使用して文字列区切り文字を設定できます。
たとえば、SAML属性値engineering,elasticsearch-admins,employeesを,の区切り文字で分割すると、engineering、elasticsearch-admins、employeesがユーザーのグループのリストとして得られます。
name
（オプション）ユーザーのフルネーム。
mail
（オプション）ユーザーのメールアドレス。
dn
（オプション）ユーザーのX.500識別名。

SAML属性からの部分値の抽出

IdPの属性にElasticsearch内で使用したい情報が含まれている場合があります。一般的な例は、IdPがメールアドレスのみを扱う場合ですが、ユーザーのprincipalにはメールアドレスのローカル名部分を使用したい場合です。たとえば、メールアドレスが[email protected]の場合、principalはjames.wongにしたいと考えています。

これは、以下のレルム設定で示されるように、Elasticsearchレルム内のattribute_patterns設定を使用して実現できます：

Yaml

xpack.security.authc.realms.saml.saml1:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.example.com/"
  sp.acs: "https://kibana.example.com/api/security/saml/callback"
  attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  attribute_patterns.principal: "^([^@]+)@staff\\.example\\.com$"

この場合、ユーザーのprincipalはメール属性からマッピングされますが、値がユーザーに割り当てられる前に正規表現が適用されます。正規表現が一致する場合、最初のグループの結果が有効な値として使用されます。正規表現が一致しない場合、属性マッピングは失敗します。

この例では、メールアドレスはstaff.example.comドメインに属する必要があり、その後ローカル部分（@の前の部分）がprincipalとして使用されます。異なるメールドメインを使用してログインしようとするユーザーは、正規表現がそのメールアドレスに対して一致しないため、失敗し、必須のprincipal属性が設定されません。

これらの正規表現の小さなミスは、重大なセキュリティ上の結果をもたらす可能性があります。たとえば、上記の例から末尾の$を誤って省略した場合、staff.example.comで始まるドメインのメールアドレスに一致し、[email protected]のようなメールアドレスを受け入れることになります。正規表現ができるだけ正確であることを確認し、ユーザーのなりすまし攻撃の道を誤って開かないようにすることが重要です。

特定の認証方法の要求

SAML SPがIdPで行われる認証に関して特定の制限を課す必要がある場合があります。これは、対応する認証応答に対して信頼度を評価するためです。制限は、認証方法（パスワード、クライアント証明書など）、登録時のユーザー識別方法、その他の詳細に関するものである可能性があります。Elasticsearchは、SAML 2.0コア仕様で定義されている SAML 2.0認証コンテキストを実装しています。

要するに、SAML SPは、IdPに課す制限を説明する一連の認証コンテキストクラス参照値を定義し、これを認証リクエストに送信します。IdPはこれらの制限を付与しようとします。付与できない場合、認証試行は失敗します。ユーザーが正常に認証されると、SAML応答の認証ステートメントには、満たされた制限の指示が含まれます。

認証コンテキストクラス参照値は、SAMLレルム設定でreq_authn_context_class_refオプションを使用して定義できます。SAMLレルム設定を参照してください。

Elasticsearchは、認証コンテキストに対してexact比較方法のみをサポートします。IdPからの認証応答を受信すると、ElasticsearchはSAMLアサーションの認証ステートメントの一部である認証コンテキストクラス参照の値を調べます。これが要求された値の1つと一致する場合、認証は成功と見なされます。それ以外の場合、認証試行は失敗します。

SAMLログアウト

SAMLプロトコルはシングルログアウト（SLO）の概念をサポートしています。SLOのサポートレベルはアイデンティティプロバイダーによって異なります。IdPが提供するログアウトサービスを確認するには、IdPのドキュメントを参照してください。

デフォルトでは、Elastic Stackは次の条件が満たされている場合にSAML SLOをサポートします：

IdPメタデータがIdPがSLOサービスを提供することを指定している
IdPがユーザーのために発行するSAMLアサーションの主題にNameIDをリリースする
sp.logoutを設定する
設定idp.use_single_logoutがfalseでない

IdP SLOサービス

ElasticsearchがIdPのSAMLメタデータから読み取る値の1つは<SingleLogoutService>です。Elastic Stackでシングルログアウトが機能するためには、Elasticsearchはこれが存在し、urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirectのバインディングをサポートする必要があります。

Elastic Stackは、適切に<LogoutRequest>および<LogoutResponse>メッセージをこのサービスに送信します。

sp.logout設定

Elasticsearchレルム設定sp.logoutは、IdPが<LogoutRequest>および<LogoutResponse>メッセージを送信できるKibana内のURLを指定します。このサービスはSAML HTTP-Redirectバインディングを使用します。

Elasticsearchは<LogoutRequest>メッセージを処理し、提供されたSAMLセッションに関連付けられた既存のElasticsearchセキュリティトークンを無効にするグローバルサインアウトを実行します。


IdPは`````LogoutRequest`````メッセージが署名されることを要求することが一般的であるため、[署名資格情報](dd149fcc111aa209.md#saml-enc-sign)を設定する必要があるかもしれません。
#### idp.use_single_logout設定
IdPが`````<SingleLogoutService>`````を提供しているが使用したくない場合、SAMLレルムで`````idp.use_single_logout: false`````を設定すると、ElasticsearchはIdPが提供するSLOサービスを無視します。この場合、ユーザーがKibanaからログアウトすると、Elasticsearchセッション（セキュリティトークン）が無効になりますが、IdPでのログアウトは行われません。
#### シングルログアウトなしでKibanaを使用する
IdPがシングルログアウトをサポートしていない場合、または使用しないことを選択した場合、Kibanaは「ローカルログアウト」のみを実行します。  
これは、KibanaがElasticsearchとの通信に使用しているセッショントークンを無効にしますが、アイデンティティプロバイダーセッションの無効化はできません。ほとんどの場合、これはKibanaユーザーがIdPにログインしていると見なされ続けることを意味します。したがって、ユーザーがKibanaのランディングページに移動すると、自動的に再認証され、新しいKibanaセッションが開始され、資格情報を入力する必要がありません。  
この問題に対する可能な解決策は次のとおりです：  
-  IdP管理者またはベンダーにシングルログアウトサービスを提供するように依頼する  
-  IdPがシングルログアウトサービスを提供している場合、それがIdPメタデータファイルに含まれていることを確認し、`````idp.use_single_logout`````を`````false`````に設定しないでください。  
-  ユーザーにKibanaからログアウトした後にブラウザを閉じるように指示する  
-  SAMLレルムで`````force_authn`````設定を有効にする。この設定により、Elastic StackはユーザーがKibanaにログインしようとするたびにIdPから新しい認証を要求します。この設定は`````false`````にデフォルト設定されており、ユーザーエクスペリエンスが煩雑になる可能性がありますが、既存のIdPセッションにユーザーが乗っかるのを防ぐための効果的な保護にもなります。
### 暗号化と署名
Elastic Stackは、署名されたSAMLメッセージ（認証および/またはログアウト用）の生成、IdPからの署名されたSAMLメッセージの検証（認証およびログアウトの両方）、および暗号化されたコンテンツの処理をサポートしています。  
Elasticsearchは、署名、暗号化、またはその両方のために、同じまたは異なるキーを使用して設定できます。  
Elastic Stackは、SAML暗号化のためにRSA秘密鍵を持つX.509証明書を使用します。これらのキーは、`````elasticsearch-certutil`````ツールを含む任意の標準SSLツールを使用して生成できます。  
IdPは、Elastic StackがSAMLメッセージに署名するための暗号鍵を持ち、サービスプロバイダー設定内で対応する署名証明書を提供することを要求する場合があります（Elastic Stack SAMLメタデータファイル内またはIdP管理インターフェース内で手動で設定）。ほとんどのIdPは、認証リクエストが署名されることを期待していませんが、ログアウトリクエストには署名が必要な場合が一般的です。IdPは、Elastic Stackサービスプロバイダーに設定された署名証明書に対してこれらの署名を検証します。  
暗号化証明書はほとんど必要ありませんが、IdPまたはローカルポリシーがその使用を義務付ける場合に備えて、Elastic Stackはそれをサポートしています。
#### 証明書とキーの生成
Elasticsearchは、PEM、PKCS#12、またはJKS形式の証明書とキーをサポートしています。一部のアイデンティティプロバイダーは、サポートする形式に制限があり、特定の形式のファイルとして証明書を提供する必要があります。IdPがサポートする形式を確認するには、IdPのドキュメントを参照してください。PEM形式が最も一般的にサポートされている形式であるため、以下の例ではその形式で証明書を生成します。  
[`````elasticsearch-certutil`````ツール](/read/elasticsearch-8-15/19b62c6c0f109bfd.md)を使用して、次のコマンドで署名証明書を生成できます：  
``````sh
bin/elasticsearch-certutil cert --self-signed --pem --days 1100 --name saml-sign --out saml-sign.zip
`

これにより、

証明書とキーのペアを生成します（certサブコマンド）
PEM形式でファイルを作成します（-pemオプション）
3年間有効な証明書を生成します（-days 1100）
証明書にsaml-signという名前を付けます（-nameオプション）
証明書とキーをsaml-sign.zipファイルに保存します（-outオプション）

生成されたzipアーカイブには、次の3つのファイルが含まれます：

saml-sign.crt、署名に使用される公開証明書
saml-sign.key、証明書の秘密鍵
ca.crt、必要ないCA証明書で、無視できます。

暗号化証明書は、同じプロセスで生成できます。

署名のためのElasticsearchの設定

デフォルトでは、署名キーが設定されている場合、Elasticsearchはすべての送信SAMLメッセージに署名します。

署名のためにPEM形式のキーと証明書を使用する場合、SAMLレルムで次の設定を構成する必要があります：

signing.certificate
PEM形式の証明書ファイルへのパス。例：saml/saml-sign.crt
signing.key
PEM形式のキーファイルへのパス。例：saml/saml-sign.key
signing.secure_key_passphrase
ファイルが暗号化されている場合のキーのパスフレーズ。これは、elasticsearch-keystoreツールで設定する必要があるセキュア設定です。

署名のためにPKCS#12形式のファイルまたはJavaキーストアを使用する場合、SAMLレルムで次の設定を構成する必要があります：

signing.keystore.path
PKCS#12またはJKSキーストアへのパス。例：saml/saml-sign.p12
signing.keystore.alias
キーストア内のキーのエイリアス。例：signing-key
signing.keystore.secure_password
ファイルが暗号化されている場合のキーストアのパスフレーズ。これは、elasticsearch-keystoreツールで設定する必要があるセキュア設定です。

すべての送信SAMLメッセージに署名するのではなく、一部のメッセージに署名したい場合は、SAMLレルムで次の設定を構成する必要があります：

signing.saml_messages
署名するメッセージタイプのリスト。メッセージタイプは、メッセージに使用されるXML要素のローカル名によって識別されます。サポートされている値は、AuthnRequest、LogoutRequest、およびLogoutResponseです。

暗号化メッセージのためのElasticsearchの設定

Elasticsearchのセキュリティ機能は、メッセージの復号化のために単一のキーをサポートしています。キーが設定されている場合、Elasticsearchはそれを使用して、認証応答のEncryptedAssertionおよびEncryptedAttribute要素、ログアウト要求のEncryptedID要素を復号化しようとします。

Elasticsearchは、復号化できないEncryptedAssertionを含むSAMLメッセージを拒否します。


SAML暗号化に**PEM形式**のキーと証明書を使用したい場合は、SAMLレルムに次の設定を構成する必要があります：  
-   `````encryption.certificate

PEM形式の証明書ファイルへのパス。例：saml/saml-crypt.crt
encryption.key
PEM形式のキーファイルへのパス。例：saml/saml-crypt.key
encryption.secure_key_passphrase
ファイルが暗号化されている場合のキーのパスフレーズ。これは、elasticsearch-keystoreツールで設定する必要があるセキュア設定です。

SAML暗号化にPKCS#12形式のファイルまたはJavaキーストアを使用したい場合は、SAMLレルムに次の設定を構成する必要があります：

encryption.keystore.path
PKCS#12またはJKSキーストアへのパス。例：saml/saml-crypt.p12
encryption.keystore.alias
キーストア内のキーのエイリアス。例：encryption-key
encryption.keystore.secure_password
ファイルが暗号化されている場合のキーストアのパスフレーズ。これは、elasticsearch-keystoreツールで設定する必要があるセキュア設定です。

SPメタデータの生成

一部のアイデンティティプロバイダーは、サービスプロバイダーからメタデータファイルをインポートすることをサポートしています。これにより、IdPとSP間の多くの統合オプションが自動的に構成されます。

Elastic Stackは、bin/elasticsearch-saml-metadataコマンドまたはSAMLサービスプロバイダーメタデータAPIを使用して、そのようなメタデータファイルを生成することをサポートしています。

APIリクエストをElasticsearchに発行してSAMLメタデータを生成し、jqのようなツールを使用してXMLファイルとして保存できます。たとえば、次のコマンドはSAMLレルムrealm1のメタデータを生成し、metadata.xmlファイルに保存します：

コンソール

curl -u user_name:password  -X GET http://localhost:9200/_security/saml/metadata/saml1 -H 'Content-Type: application/json' | jq -r '.[]' > metadata.xml

ロールマッピングの設定

ユーザーがSAMLを使用して認証すると、彼らはElastic Stackに識別されますが、これにより自動的にアクションを実行したりデータにアクセスしたりする権限が与えられるわけではありません。

SAMLユーザーは、ロールが割り当てられるまで何もできません。これは、ロールマッピング追加APIまたは認可レルムを通じて行うことができます。

ロールマッピングファイルを使用して、SAMLを介して認証されるユーザーにロールを付与することはできません。

これは、example_roleロールをsaml1レルムに対して認証する任意のユーザーに付与するシンプルなロールマッピングの例です：

Python

resp = client.security.put_role_mapping(
   name="saml-example",
   roles=[
   "example_role"
   ],
   enabled=True,
   rules={
   "field": {
   "realm.name": "saml1"
   }
   },
)
print(resp)

Js

const response = await client.security.putRoleMapping({
  name: "saml-example",
  roles: ["example_role"],
  enabled: true,
  rules: {
   field: {
   "realm.name": "saml1",
   },
  },
});
console.log(response);

コンソール

PUT /_security/role_mapping/saml-example
{
  "roles": [ "example_role" ],
  "enabled": true,
  "rules": {
   "field": { "realm.name": "saml1" }
  }
}


	`example_role`ロールは**組み込みのElasticsearchロールではありません。この例では、適切なアクセス権を持つ独自のカスタムロールを作成したと仮定しています。データストリーム、インデックス、および Kibana機能。

レルム設定を介してマッピングされた属性は、ロールマッピングルールを処理するために使用され、これらのルールはユーザーに付与されるロールを決定します。

ロールマッピングに提供されるユーザーフィールドは、次のようにSAML属性から派生します：

username: principal属性
dn: dn属性
groups: groups属性
metadata: ユーザーメタデータを参照してください。

詳細については、ユーザーとグループをロールにマッピングするおよびロールマッピングを参照してください。

IdPがサービスプロバイダーにグループまたはロールを提供する能力を持っている場合は、このSAML属性をElasticsearchレルムのattributes.groups設定にマッピングし、以下の例に従ってロールマッピングで使用する必要があります。

このマッピングは、saml1レルムを介してfinance_dataロールを認証する任意のユーザーに付与します。

Python

resp = client.security.put_role_mapping(
   name="saml-finance",
   roles=[
   "finance_data"
   ],
   enabled=True,
   rules={
   "all": [
   {
   "field": {
   "realm.name": "saml1"
   }
   },
   {
   "field": {
   "groups": "finance-team"
   }
   }
   ]
   },
)
print(resp)

Js

const response = await client.security.putRoleMapping({
  name: "saml-finance",
  roles: ["finance_data"],
  enabled: true,
  rules: {
   all: [
   {
   field: {
   "realm.name": "saml1",
   },
   },
   {
   field: {
   groups: "finance-team",
   },
   },
   ],
  },
});
console.log(response);

コンソール

PUT /_security/role_mapping/saml-finance
{
  "roles": [ "finance_data" ],
  "enabled": true,
  "rules": { "all": [
   { "field": { "realm.name": "saml1" } },
   { "field": { "groups": "finance-team" } }
  ] }
}


	`groups`属性はワイルドカード（`*`）の使用をサポートしています。詳細については、ロールマッピングAPIの作成または更新を参照してください。

ユーザーがElasticsearchに直接アクセスできるリポジトリ（LDAPディレクトリなど）にも存在する場合、認可領域をロールマッピングの代わりに使用できます。

この場合、次の手順を実行します： 1. SAMLレルムで、attributes.principal設定を構成して、ルックアップユーザーIDとして機能するSAML属性を割り当てます。 2. ローカルリポジトリからユーザーをルックアップできる新しいレルムを作成します（例：ldapレルム） 3. SAMLレルムで、authorization_realmsをステップ2で作成したレルムの名前に設定します。

ユーザーメタデータ

デフォルトでは、SAMLを介して認証されたユーザーには、いくつかの追加メタデータフィールドがあります。

saml_nameidは、SAML認証応答のNameID要素の値に設定されます
saml_nameid_formatは、NameIDのformat属性の完全なURIに設定されます
認証応答に提供されるすべてのSAML属性（Elasticsearchユーザープロパティにマッピングされているかどうかに関係なく）は、メタデータフィールドsaml(name)として追加されます。ここで「name」は属性の完全なURI名です。たとえばsaml(urn:oid:0.9.2342.19200300.100.1.3)。
フレンドリーネームを持つすべてのSAML属性も、メタデータフィールドsaml_friendlyNameとして追加されます。ここで「name」は属性の完全なURI名です。たとえばsaml_mail。

この動作は、SAMLレルムの設定としてpopulate_user_metadata: falseを追加することで無効にできます。

Kibanaの設定

KibanaでのSAML認証には、標準のKibanaセキュリティ設定に加えて、少数の追加設定が必要です。Kibanaセキュリティドキュメントには、適用可能な設定オプションの詳細が記載されています。

特に、ElasticsearchノードがHTTPインターフェースでTLSを使用するように設定されているため、KibanaをElasticsearchに接続するためにhttps URLを使用するように設定する必要があり、Elasticsearchが使用するように設定された証明書を信頼するためにelasticsearch.ssl.certificateAuthoritiesを設定する必要がある場合があります。

KibanaでのSAML認証は、kibana.ymlの次のタイムアウト設定の影響を受けます：

これらのタイムアウトは、セキュリティ要件に基づいて調整することをお勧めします。

SAMLサポートに必要な3つの追加設定は、以下に示します：

Yaml

xpack.security.authc.providers:
  saml.saml1:
   order: 0
   realm: "saml1"

上記の例で使用される設定値は次のとおりです：

xpack.security.authc.providers
KibanaにSAML SSOを認証方法として使用するよう指示するためにsamlプロバイダーを追加します。
xpack.security.authc.providers.saml.<provider-name>.realm
Elasticsearchレルム設定で使用したSAMLレルムの名前に設定します。たとえば：saml1

KibanaでのSAMLおよび基本認証のサポート

KibanaでのSAMLサポートは、そのKibanaインスタンスのユーザーにとって主要（または唯一の）認証方法になることを期待して設計されています。ただし、xpack.security.authc.providersを以下の例のように設定することで、単一のKibanaインスタンス内でSAMLと基本認証の両方をサポートすることが可能です。

Yaml

xpack.security.authc.providers:
  saml.saml1:
   order: 0
   realm: "saml1"
  basic.basic1:
   order: 1

このようにKibanaが設定されている場合、ユーザーはログインセレクタUIで選択肢が提示されます。彼らはSAMLでログインするか、ユーザー名とパスワードを提供し、Elasticsearch内の他のセキュリティレルムのいずれかに依存します。構成されたElasticsearch認証レルムのユーザー名とパスワードを持つユーザーのみがKibanaログインフォームを介してログインできます。

また、basic認証プロバイダーが有効になっている場合、Kibanaの前にリバースプロキシを配置し、各リクエストに基本認証ヘッダー（Authorization: Basic ....）を送信するように構成できます。このヘッダーが存在し、有効である場合、KibanaはSAML認証プロセスを開始しません。

複数のKibanaインスタンスの運用

同じElasticsearchクラスターに対して認証する複数のKibanaインスタンスを持ちたい場合、SAML認証用に構成された各Kibanaインスタンスには独自のSAMLレルムが必要です。

各SAMLレルムは、独自のユニークなエンティティID（sp.entity_id）と独自のアサーションコンシューマサービス（sp.acs）を持っている必要があります。各Kibanaインスタンスは、対応するsp.acs値をルックアップすることによって正しいレルムにマッピングされます。

これらのレルムは同じアイデンティティプロバイダーを使用することができますが、必ずしもそうである必要はありません。

以下は、3つの異なるKibanaインスタンスを持つ例であり、そのうちの2つは同じ内部IdPを使用し、もう1つは異なるIdPを使用しています。

Yaml

xpack.security.authc.realms.saml.saml_finance:
  order: 2
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.finance.example.com/"
  sp.acs: "https://kibana.finance.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.finance.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_sales:
  order: 3
  idp.metadata.path: saml/idp-metadata.xml
  idp.entity_id: "https://sso.example.com/"
  sp.entity_id:  "https://kibana.sales.example.com/"
  sp.acs: "https://kibana.sales.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.sales.example.com/logout"
  attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
  attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."
xpack.security.authc.realms.saml.saml_eng:
  order: 4
  idp.metadata.path: saml/idp-external.xml
  idp.entity_id: "https://engineering.sso.example.net/"
  sp.entity_id:  "https://kibana.engineering.example.com/"
  sp.acs: "https://kibana.engineering.example.com/api/security/saml/callback"
  sp.logout: "https://kibana.engineering.example.com/logout"
  attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

SAMLを使用する1つ以上のKibanaインスタンスを持ちながら、他のインスタンスが別のレルムタイプ（例：NativeまたはLDAP）に対して基本認証を使用することは可能です。

SAMLレルム設定のトラブルシューティング

SAML 2.0仕様は、標準の実装者に多くのオプションと柔軟性を提供し、それが結果としてサービスプロバイダー（Elastic Stack）およびアイデンティティプロバイダーの両方で利用可能な設定オプションの複雑さと数を増加させます。さらに、異なるセキュリティドメインは、特定の設定を満たす必要がある異なるセキュリティ要件を持っています。この複雑さを合理的なデフォルトと上記の詳細なドキュメントでマスクするために意識的な努力がなされていますが、SAMLレルムの設定中に問題が発生した場合は、一般的な問題に対する提案と解決策が含まれている SAMLトラブルシューティングドキュメントを参照できます。

KibanaなしのSAML

ElasticsearchのSAMLレルムは、ユーザーがKibanaに認証できるように設計されており、そのため、上記のガイドのほとんどの部分はKibanaが使用されることを前提としています。このセクションでは、カスタムWebアプリケーションが関連するSAML REST APIを使用して、ユーザーをSAMLでElasticsearchに認証する方法を説明します。

このセクションでは、読者がSAML 2.0標準、特にSAML 2.0 Webブラウザシングルサインオンプロファイルに精通していることを前提としています。

OpenID ConnectやSAMLのようなシングルサインオンレルムは、Elasticsearchのトークンサービスを利用し、原則としてSAMLまたはOpenID Connect認証応答をElasticsearchアクセス・トークンおよびリフレッシュ・トークンと交換します。アクセス・トークンは、Elasticsearchへのその後の呼び出しのための資格情報として使用されます。リフレッシュ・トークンは、現在のトークンが期限切れになった後に新しいElasticsearchアクセス・トークンを取得するためにユーザーを可能にします。

SAMLレルム

SAMLレルムを作成し、それに応じてElasticsearchで構成する必要があります。SAML認証のためのElasticsearchの設定を参照してください。

APIにアクセスするためのサービスアカウントユーザー

このレルムは、特権エンティティが認証プロキシとして機能する必要があるという前提で設計されています。この場合、カスタムWebアプリケーションは、エンドユーザーの認証を処理する認証プロキシです（より正確には、SAMLアイデンティティプロバイダーへの認証を「委任」しています）。SAML関連のAPIは認証を必要とし、認証されたユーザーに必要な承認レベルが必要です。このため、サービスアカウントユーザーを作成し、manage_samlクラスター特権を付与するロールを割り当てる必要があります。認証が行われた後、サービスアカウントユーザーが認証されたユーザーに代わってアクセス・トークンを更新したり、後でログアウトさせたりするために、manage_tokenクラスター特権の使用が必要になります。

Python

resp = client.security.put_role(
   name="saml-service-role",
   cluster=[
   "manage_saml",
   "manage_token"
   ],
)
print(resp)

Js

const response = await client.security.putRole({
  name: "saml-service-role",
  cluster: ["manage_saml", "manage_token"],
});
console.log(response);

コンソール

POST /_security/role/saml-service-role
{
  "cluster" : ["manage_saml", "manage_token"]
}

Python

resp = client.security.put_user(
   username="saml-service-user",
   password="<somePasswordHere>",
   roles=[
   "saml-service-role"
   ],
)
print(resp)

Js

const response = await client.security.putUser({
  username: "saml-service-user",
  password: "<somePasswordHere>",
  roles: ["saml-service-role"],
});
console.log(response);

コンソール

POST /_security/user/saml-service-user
{
  "password" : "<somePasswordHere>",
  "roles"    : ["saml-service-role"]
}

SP起動の認証フローの処理

高レベルでは、カスタムWebアプリケーションは、ユーザーをElasticsearchに対してSAMLで認証するために次の手順を実行する必要があります：

1. _security/saml/prepareにHTTP POSTリクエストを行い、saml-service-userユーザーとして認証します。Elasticsearch設定のSAMLレルムの名前またはリクエストボディ内のアサーションコンシューマサービスURLの値を使用します。詳細については、SAML認証準備APIを参照してください。

Python

resp = client.security.saml_prepare_authentication(
   realm="saml1",
  )
  print(resp)

Js

const response = await client.security.samlPrepareAuthentication({
   realm: "saml1",
  });
  console.log(response);

コンソール

POST /_security/saml/prepare
  {
   "realm" : "saml1"
  }

2. /_security/saml/prepareからの応答を処理します。Elasticsearchからの応答には、redirect、realm、idの3つのパラメータが含まれます。カスタムWebアプリケーションは、idの値をユーザーのセッションに保存する必要があります（クライアント側のクッキーまたはセッション情報がこの方法で永続化されている場合はサーバー側）。また、ユーザーのブラウザをredirectパラメータで返されたURLにリダイレクトする必要があります。idの値は、リプレイ攻撃を軽減するためにSAMLでノンスとして使用されるため、無視しないでください。
3. SAML IdPからの後続の応答を処理します。ユーザーがアイデンティティプロバイダーで正常に認証されると、アサーションコンシューマサービスURLにリダイレクトされます。このsp.acsは、カスタムWebアプリケーションが処理するURLとして定義する必要があります。このHTTP POSTリクエストを受信したとき、カスタムWebアプリケーションはそれを解析し、_security/saml/authenticate APIにHTTP POSTリクエストを行う必要があります。saml-service-userユーザーとして認証し、リクエストの本文として送信されたBase64エンコードされたSAML応答を渡す必要があります。また、以前にユーザーのセッションに保存したidの値も渡す必要があります。詳細については、SAML認証APIを参照してください。

Python

resp = client.security.saml_authenticate(
   content="PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
   ids=[
   "4fee3b046395c4e751011e97f8900b5273d56685"
   ],
  )
  print(resp)

Js

const response = await client.security.samlAuthenticate({
   content:
   "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
   ids: ["4fee3b046395c4e751011e97f8900b5273d56685"],
  });
  console.log(response);

コンソール

POST /_security/saml/authenticate
  {
   "content" : "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
   "ids" : ["4fee3b046395c4e751011e97f8900b5273d56685"]
  }

Elasticsearchはこれを検証し、すべてが正しい場合、後続のリクエストに使用できるBearerトークンとして使用できるアクセストークンを返します。また、トークン取得APIで説明されているように、与えられたアクセストークンを更新するために後で使用できるリフレッシュトークンも提供します。

4. /_security/saml/authenticateを呼び出す応答には、認証されたユーザーのユーザー名のみが含まれます。SAML応答に含まれていたSAML属性の値を取得する必要がある場合は、アクセストークンをBearerトークンとして使用して認証API/_security/_authenticate/を呼び出すことができ、SAML属性値はユーザーメタデータの一部として応答に含まれます。

IdP起動の認証フローの処理

Elasticsearchは、SAML 2 WebブラウザSSOプロファイルのIdP起動のシングルサインオンフローも処理できます。この場合、認証はSAMLアイデンティティプロバイダーからの未請求の認証応答から始まります。SP起動SSOとの違いは、Webアプリケーションがsp.acsへのリクエストを処理する必要があることであり、これは以前のリダイレクションへの応答としては来ません。そのため、ユーザーのセッションはすでに存在せず、idパラメータの保存された値もありません。この場合、_security/saml/authenticate APIへのリクエストは以下のようになります：

Python

resp = client.security.saml_authenticate(
   content="PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
   ids=[],
)
print(resp)

Js

const response = await client.security.samlAuthenticate({
  content:
   "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
  ids: [],
});
console.log(response);

コンソール

POST /_security/saml/authenticate
{
  "content" : "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMD.....",
  "ids" : []
}

ログアウトフローの処理

1. 必要に応じて、カスタムWebアプリケーションはSAMLログアウトAPIを使用してユーザーをログアウトさせ、アクセストークンとリフレッシュトークンをパラメータとして渡すことができます。たとえば：

Python

resp = client.security.saml_logout(
   token="46ToAxZVaXVVZTVKOVF5YU04ZFJVUDVSZlV3",
   refresh_token="mJdXLtmvTUSpoLwMvdBt_w",
  )
  print(resp)

Js

const response = await client.security.samlLogout({
   token: "46ToAxZVaXVVZTVKOVF5YU04ZFJVUDVSZlV3",
   refresh_token: "mJdXLtmvTUSpoLwMvdBt_w",
  });
  console.log(response);

コンソール

POST /_security/saml/logout
  {
   "token" : "46ToAxZVaXVVZTVKOVF5YU04ZFJVUDVSZlV3",
   "refresh_token": "mJdXLtmvTUSpoLwMvdBt_w"
  }

SAMLレルムが適切に設定され、IdPがそれをサポートしている場合（SAMLログアウトを参照）、このリクエストはSAML SP起動のシングルログアウトをトリガーします。この場合、応答には、ユーザーがログアウトを完了するためにIdPでリダイレクトされる必要がある場所を示すredirectパラメータが含まれます。

2. あるいは、IdPがある時点でシングルログアウトフローを開始することがあります。これを処理するために、カスタムWebアプリケーションはログアウトURL（sp.logout）を処理する必要があります。ユーザーがリダイレクトされるURLのクエリ部分にはSAMLログアウトリクエストが含まれており、このクエリ部分はSAML無効化APIを使用してElasticsearchに中継する必要があります。

Python

resp = client.security.saml_invalidate(
   query="SAMLRequest=nZFda4MwFIb%2FiuS%2BmviRpqFaClKQdbvo2g12M2KMraCJ9cRR9utnW4Wyi13sMie873MeznJ1aWrnS3VQGR0j4mLkKC1NUeljjA77zYyhVbIE0dR%2By7fmaHq7U%2BdegXWGpAZ%2B%2F4pR32luBFTAtWgUcCv56%2Fp5y30X87Yz1khTIycdgpUW9kY7WdsC9zxoXTvMvWuVV98YyMnSGH2SYE5pwALBIr9QKiwDGpW0oGVUznGeMyJZKFkQ4jBf5HnhUymjIhzCAL3KNFihbYx8TBYzzGaY7EnIyZwHzCWMfiDnbRIftkSjJr%2BFu0e9v%2B0EgOquRiiZjKpiVFp6j50T4WXoyNJ%2FEWC9fdqc1t%2F1%2B2F3aUpjzhPiXpqMz1%2FHSn4A&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=MsAYz2NFdovMG2mXf6TSpu5vlQQyEJAg%2B4KCwBqJTmrb3yGXKUtIgvjqf88eCAK32v3eN8vupjPC8LglYmke1ZnjK0%2FKxzkvSjTVA7mMQe2AQdKbkyC038zzRq%2FYHcjFDE%2Bz0qISwSHZY2NyLePmwU7SexEXnIz37jKC6NMEhus%3D",
   realm="saml1",
  )
  print(resp)

Js

const response = await client.security.samlInvalidate({
   query:
   "SAMLRequest=nZFda4MwFIb%2FiuS%2BmviRpqFaClKQdbvo2g12M2KMraCJ9cRR9utnW4Wyi13sMie873MeznJ1aWrnS3VQGR0j4mLkKC1NUeljjA77zYyhVbIE0dR%2By7fmaHq7U%2BdegXWGpAZ%2B%2F4pR32luBFTAtWgUcCv56%2Fp5y30X87Yz1khTIycdgpUW9kY7WdsC9zxoXTvMvWuVV98YyMnSGH2SYE5pwALBIr9QKiwDGpW0oGVUznGeMyJZKFkQ4jBf5HnhUymjIhzCAL3KNFihbYx8TBYzzGaY7EnIyZwHzCWMfiDnbRIftkSjJr%2BFu0e9v%2B0EgOquRiiZjKpiVFp6j50T4WXoyNJ%2FEWC9fdqc1t%2F1%2B2F3aUpjzhPiXpqMz1%2FHSn4A&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=MsAYz2NFdovMG2mXf6TSpu5vlQQyEJAg%2B4KCwBqJTmrb3yGXKUtIgvjqf88eCAK32v3eN8vupjPC8LglYmke1ZnjK0%2FKxzkvSjTVA7mMQe2AQdKbkyC038zzRq%2FYHcjFDE%2Bz0qISwSHZY2NyLePmwU7SexEXnIz37jKC6NMEhus%3D",
   realm: "saml1",
  });
  console.log(response);

コンソール

POST /_security/saml/invalidate
  {
   "query" : "SAMLRequest=nZFda4MwFIb%2FiuS%2BmviRpqFaClKQdbvo2g12M2KMraCJ9cRR9utnW4Wyi13sMie873MeznJ1aWrnS3VQGR0j4mLkKC1NUeljjA77zYyhVbIE0dR%2By7fmaHq7U%2BdegXWGpAZ%2B%2F4pR32luBFTAtWgUcCv56%2Fp5y30X87Yz1khTIycdgpUW9kY7WdsC9zxoXTvMvWuVV98YyMnSGH2SYE5pwALBIr9QKiwDGpW0oGVUznGeMyJZKFkQ4jBf5HnhUymjIhzCAL3KNFihbYx8TBYzzGaY7EnIyZwHzCWMfiDnbRIftkSjJr%2BFu0e9v%2B0EgOquRiiZjKpiVFp6j50T4WXoyNJ%2FEWC9fdqc1t%2F1%2B2F3aUpjzhPiXpqMz1%2FHSn4A&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=MsAYz2NFdovMG2mXf6TSpu5vlQQyEJAg%2B4KCwBqJTmrb3yGXKUtIgvjqf88eCAK32v3eN8vupjPC8LglYmke1ZnjK0%2FKxzkvSjTVA7mMQe2AQdKbkyC038zzRq%2FYHcjFDE%2Bz0qISwSHZY2NyLePmwU7SexEXnIz37jKC6NMEhus%3D",
   "realm" : "saml1"
  }

カスタムWebアプリケーションは、SAMLログアウト応答を含むredirectパラメータを持つIdPからの応答も処理する必要があります。アプリケーションは、ログアウトを完了するためにユーザーをそこにリダイレクトする必要があります。

SP起動のシングルログアウトの場合、IdPはElasticsearchがSAML完全ログアウトAPIを使用して検証できるログアウト応答を返すことがあります。