一般的なSAMLの問題

一般的なSAMLの問題のいくつかを以下に示し、これらの問題を解決するためのヒントを提供します。

  • 1. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=saml1,
    2. assertionConsumerServiceURL=https://my.kibana.url/api/security/saml/callback}]
    解決策:
    SAML認証を開始するには、KibanaはElasticsearchに設定されているSAMLレルムの中からどのSAMLレルムを使用するかを知る必要があります。xpack.security.authc.providers.saml.<provider-name>.realm設定を使用して、KibanaでSAMLレルム名を明示的に設定できます。これは、Elasticsearchに設定されているSAMLレルムの名前と一致する必要があります。
    上記のようなエラーが発生した場合、Kibanaの設定でxpack.security.authc.providers.saml.<provider-name>.realmの値が間違っている可能性があります。Elasticsearchの設定でxpack.security.authc.realms.saml.の後にある文字列が、設定されたレルムの名前と一致することを確認してください。
  • 2. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. Authentication to realm saml1 failed - Provided SAML response is not valid for realm
    2. saml/saml1 (Caused by ElasticsearchSecurityException[Conditions
    3. [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company....ple.com/]
    4. do not match required audience
    5. [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com]])
    解決策:
    別のSAMLサービスプロバイダー宛てのSAMLレスポンスを受信しました。これは通常、elasticsearch.yml（sp.entity_id）に設定されたSAMLサービスプロバイダーエンティティIDが、SAMLアイデンティティプロバイダーのドキュメントに設定されているSAMLサービスプロバイダーエンティティIDと一致しないことを意味します。
    この問題を解決するには、ElasticsearchのsamlレルムとIdPの両方が、サービスプロバイダーのSAMLエンティティIDに同じ文字列を設定されていることを確認してください。
    Elasticsearchのログでは、例外メッセージ（上記）の直前に、bash Audience restriction [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com/] does not match required audience [https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com] (difference starts at character [#68] [/] vs [])の形式の1つ以上のINFOレベルのメッセージが表示されます。
    このログメッセージは、IdPから受信した値とElasticsearchに設定された値の違いを特定するのに役立ちます。2つのオーディエンス識別子の違いを説明する括弧内のテキストは、2つの文字列が類似していると見なされる場合にのみ表示されます。
    これらの文字列は、大文字と小文字を区別する文字列として比較され、URLのような値であっても正規化されたURLとしては比較されません。末尾のスラッシュ、ポート番号などに注意してください。
  • 3. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. Cannot find metadata for entity [your:entity.id] in [metadata.xml]
    解決策:
    設定されたメタデータファイル（metadata.xml）にSAMLエンティティID your:entity.idのメタデータが見つかりませんでした。
    • 3.1. 使用しているmetadata.xmlファイルが、実際にSAMLアイデンティティプロバイダーによって提供されたものであることを確認してください。
    • 3.2. metadata.xmlファイルには、次のように1つの\u003centitydescriptor>要素が含まれていることを確認してください: <EntityDescriptor ID="0597c9aa-e69b-46e7-a1c6-636c7b8a8070" entityID="https://saml.example.com/f174199a-a96e-4201-88f1-0d57a610c522/" ...、ここでentityID属性の値は、elasticsearch.ymlのSAMLレルム設定で設定したidp.entity_idの値と同じである必要があります。
    • 3.3. これらも大文字と小文字を区別する文字列として比較され、URLのような値であっても正規化されたURLとしては比較されないことに注意してください。
  • 4. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. unable to authenticate user [<unauthenticated-saml-user>]
    2. for action [cluster:admin/xpack/security/saml/authenticate]
    解決策:
    このエラーは、Elasticsearchが受信したSAML認証メッセージを処理できなかったことを示しています。メッセージを処理できないため、Elasticsearchは認証されるべきユーザーが誰であるかを認識せず、<unauthenticated-saml-user>プレースホルダーが代わりに使用されます。実際の問題を診断するには、Elasticsearchのログを確認して詳細を確認する必要があります。
  • 5. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. Authentication to realm <saml-realm-name> failed - SAML Attribute [<AttributeName0>] for
    2. [xpack.security.authc.realms.saml.<saml-realm-name>.attributes.principal] not found in saml attributes
    3. [<AttributeName1>=<AttributeValue1>, <AttributeName2>=<AttributeValue2>, ...] or NameID [ NameID(format)=value ]
    解決策:
    このエラーは、Elasticsearchがアイデンティティプロバイダーから送信されたSAMLレスポンスに必要なSAML属性を見つけられなかったことを示しています。この例では、Elasticsearchは次のように設定されています:
    1. xpack.security.authc.realms.saml.<saml-realm-name>.attributes.principal: AttributeName0
    この設定は、ElasticsearchがSAMLレスポンス内でAttributeName0という名前のSAML属性または適切な形式のNameIDを見つけることを期待していることを意味します。それをマッピングできるように、principalユーザープロパティにマッピングします。principalユーザープロパティは必須であるため、このマッピングが行えない場合、認証は失敗します。
    NameIDをマッピングしようとしている場合、期待されるNameID形式が送信されるものと一致することを確認してください。詳細については、特別な属性名を参照してください。
    SAML属性をマッピングしようとしていて、それがエラーメッセージのリストに含まれていない場合、属性名を誤って入力したか、IdPがこの特定の属性を送信していない可能性があります。リスト内の別の属性を使用してprincipalにマッピングするか、IdP管理者に相談して、必要な属性を送信できるかどうかを確認してください。
  • 6. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. Cannot find [{urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor]/[urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect] in descriptor
    解決策:
    このエラーは、アイデンティティプロバイダーのSAMLメタデータにHTTP-Redirect（urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect）バインディングを持つ<SingleSignOnService>エンドポイントが含まれていないことを示しています。Elasticsearchは、SAML認証リクエストに対してHTTP-Redirectバインディングのみをサポートしています（HTTP-POSTバインディングはサポートしていません）。少なくとも1つの<SingleSignOnService>がHTTP-RedirectバインディングをサポートするようにIdP管理者に相談し、IdP SAMLメタデータを更新してください。
  • 7. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. Authentication to realm my-saml-realm failed -
    2. Provided SAML response is not valid for realm saml/my-saml-realm
    3. (Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response:
    4.  The SAML IdP did not grant the request. It indicated that the Elastic Stack side sent
    5.  something invalid (urn:oasis:names:tc:SAML:2.0:status:Requester). Specific status code which might
    6.  indicate what the issue is: [urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy]]
    7. )
    解決策:
    これは、SAMLアイデンティティプロバイダーがユーザーの認証に失敗し、この失敗を示すSAMLレスポンスをサービスプロバイダー（Elastic Stack）に送信したことを意味します。このメッセージは、SAMLアイデンティティプロバイダーが問題がサービスプロバイダー（Elastic Stack）にあると考えているのか、アイデンティティプロバイダー自体にあるのかを伝え、続く特定のステータスコードは、通常、根本的な問題を示すため非常に有用です。特定のエラーコードのリストは、SAML 2.0コア仕様 - セクション3.2.2.2に定義されており、最も一般的に遭遇するものは次のとおりです:
    • 7.1. urn:oasis:names:tc:SAML:2.0:status:AuthnFailed: SAMLアイデンティティプロバイダーがユーザーの認証に失敗しました。このステータスに対してElastic Stack側でトラブルシューティングすることはあまりありません。SAMLアイデンティティプロバイダーのログが、より多くの情報を提供してくれることを期待しています。
    • 7.2. urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy: SAMLアイデンティティプロバイダーは、要求された形式でNameIDをリリースすることをサポートできません。SAML認証リクエストを作成する際、Elasticsearchは認証リクエストのNameIDPolicy要素を適切な値で設定します。これは、elasticsearch.ymlのnameid_format設定パラメータによって制御され、設定されていない場合はurn:oasis:names:tc:SAML:2.0:nameid-format:transientにデフォルト設定されます。これにより、アイデンティティプロバイダーに対して、SAMLレスポンス内でその特定の形式のNameIDを返すよう指示します。SAMLアイデンティティプロバイダーがその要求を承認できない場合、たとえばurn:oasis:names:tc:SAML:2.0:nameid-format:persistent形式のNameIDをリリースするように設定されている場合、無効なNameIDポリシーを示すこのエラーを返します。この問題は、nameid_formatをSAMLアイデンティティプロバイダーが返すことができる形式に一致させるか、urn:oasis:names:tc:SAML:2.0:nameid-format:unspecifiedに設定してアイデンティティプロバイダーが任意の形式を返すことを許可することで解決できます。
  • 8. 症状:
    Kibanaでの認証が失敗し、Elasticsearchのログに次のエラーが表示されます:
    1. The XML Signature of this SAML message cannot be validated. Please verify that the saml
    2. realm uses the correct SAMLmetadata file/URL for this Identity Provider
    解決策:
    これは、Elasticsearchがアイデンティティプロバイダーが送信したSAMLメッセージのデジタル署名を検証できなかったことを意味します。Elasticsearchは、SAMLメタデータに含まれるアイデンティティプロバイダーの公開鍵を使用して、IdPが対応する秘密鍵を使用して作成した署名を検証します。これに失敗すると、いくつかの原因が考えられます:
    • 8.1. エラーメッセージが示すように、最も一般的な原因は、間違ったメタデータファイルが使用されていることであり、そのため、含まれている公開鍵がアイデンティティプロバイダーが使用する秘密鍵に対応していません。
    • 8.2. アイデンティティプロバイダーの設定が変更されたか、鍵がローテーションされ、Elasticsearchが使用しているメタデータファイルが更新されていません。
    • 8.3. SAMLレスポンスが転送中に変更され、正しい鍵が使用されていても署名を検証できません。
      上記で説明したように、SAMLでデジタル署名に使用される秘密鍵と公開鍵、自己署名のX.509証明書は、トランスポート層またはHTTP層で使用される鍵や証明書とは関係ありません。このような失敗は、xpack.ssl関連の設定とは何の関係もありません。
  • 9. 症状:
    ユーザーはSAMLが有効になっているため、Kibanaでローカルのユーザー名とパスワードでログインできません。
    解決策:
    ユーザーがSAMLレルムを使用してシングルサインオンを行うのに加えて、Kibanaにローカルの資格情報を使用して認証できるようにするには、Kibanaでbasic authProviderを有効にする必要があります。このプロセスは、SAMLガイドに文書化されています。
  • 10. 症状:
    KibanaからElasticsearchにSAMLリクエストID値が渡されていません:
    1. Caused by org.elasticsearch.ElasticsearchSecurityException: SAML content is in-response-to [_A1B2C3D4E5F6G8H9I0] but expected one of []
    解決策: このエラーは、Elasticsearchが特定のSAMLリクエストに関連付けられたSAMLレスポンスを受信したが、KibanaがそのリクエストのIDを明示的に指定しなかったことを示しています。これは通常、Kibanaが以前にSAMLリクエストIDを保存していたユーザーセッションを見つけられないことを意味します。
    この問題を解決するには、Kibanaの設定でxpack.security.sameSiteCookiesがStrictに設定されていないことを確認してください。設定によっては、デフォルト値に依存するか、明示的にNoneに設定できる場合があります。
    詳細については、MDN SameSiteクッキーをお読みください。
    複数のKibanaインストールをロードバランサーの背後で提供する場合は、すべてのインストールに対して同じセキュリティ設定を使用してください。
    \u003c/entitydescriptor>

ログ記録:

前述の解決策で問題が解決しない場合は、SAMLレルムの追加ログを有効にしてさらにトラブルシューティングを行ってください。次の永続設定を構成することでデバッグログを有効にできます:

Python

  1. resp = client.cluster.put_settings(
  2.    persistent={
  3.    "logger.org.elasticsearch.xpack.security.authc.saml": "debug"
  4.    },
  5. )
  6. print(resp)

Ruby

  1. response = client.cluster.put_settings(
  2.   body: {
  3.    persistent: {
  4.    'logger.org.elasticsearch.xpack.security.authc.saml' => 'debug'
  5.    }
  6.   }
  7. )
  8. puts response

Js

  1. const response = await client.cluster.putSettings({
  2.   persistent: {
  3.    "logger.org.elasticsearch.xpack.security.authc.saml": "debug",
  4.   },
  5. });
  6. console.log(response);

コンソール

  1. PUT /_cluster/settings
  2. {
  3.   "persistent": {
  4.    "logger.org.elasticsearch.xpack.security.authc.saml": "debug"
  5.   }
  6. }

また、log4j2.properties設定ファイルの最後に次の行を追加できます。ES_PATH_CONF:

プロパティ

  1. logger.saml.name = org.elasticsearch.xpack.security.authc.saml
  2. logger.saml.level = DEBUG

詳細については、ログレベルの設定を参照してください。