SAML 設定の概要 SAML 認証の有効化 SAML のトラブルシューティング SAML 認証の無効化

Kibana の SAML 認証

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

またはAmazon Cognito内部ユーザーデータベースで認証するのではなく、Kibana の SAML 認証を使用すると、サードパーティーの ID プロバイダーを使用して Kibana へのログイン、きめ細かなアクセスコントロールの管理、データの検索および可視化の構築を行うことができます。は、Okta、Keyclokak、Active Federation Services、Auth0 などの SAML 2.0 標準を使用するプロバイダーをサポートしています。Amazon Elasticsearch Service

Kibana の SAML 認証は、ウェブブラウザを介した Kibana へのアクセスにのみ使用されます。SAML 認証情報により、 または Kibana に対して直接 HTTP リクエストを行うことはElasticsearchできませんAPIs。

SAML 設定の概要

このページでは、既存の ID プロバイダーがあり、ある程度理解していることを前提としています。正確なプロバイダーの詳細な設定ステップは、Amazon ES ドメインに対してのみ提供できません。

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

サービスプロバイダー (SP) の開始: Kibana (https://my-domain.us-east-1.es.amazonaws.com/_plugin/kibana など) に移動すると、ログイン画面にリダイレクトされます。ログインすると、ID プロバイダーによって Kibana にリダイレクトされます。
ID プロバイダー (IdP) 開始: ID プロバイダーに移動し、ログインして、アプリケーションディレクトリから Kibana を選択します。

Amazon ES は、2 つのシングルサインオン URLs、SP 開始および IdP 開始を提供しますが、必要なのは必要な Kibana ログインフローに一致するもののみです。

どちらの場合も、ID プロバイダーを通じてログインし、ユーザー名 (必須) と任意のバックエンドロール (オプション、ただし推奨) を含む SAML アサーションを受け取ることが目的です。この情報により、きめ細かなアクセスコントロールで SAML ユーザーにアクセス許可を割り当てることができます。外部 ID プロバイダーでは、バックエンドロールは通常、「ロール」または「グループ」と呼ばれます。

注記

SSO URL を変更することはできないため、Kibana の SAML 認証ではプロキシサーバーがサポートされていません。

SAML 認証の有効化

Kibana の SAML 認証は、新しいドメインの作成時ではなく、既存のドメインでのみ有効にすることができます。メタデータファイルのサイズのため、AWS コンソールを使用することを強くお勧めします。IdP

ヒント

ドメインは、一度に 1 つの Kibana 認証方法のみをサポートします。Kibana の認証Amazon Cognitoが有効になっている場合は、SAML を有効にする前に無効にする必要があります。

Kibana の SAML 認証を有効にするには (コンソール)

ドメイン、[Actions]、および [Modify authentication] を選択します。
[Enable SAML authentication] を選択します。
サービスプロバイダーのエンティティ ID と 2 つの SSO URLs を書き留めます。 SSO URLs の 1 つのみ必要です。ガイダンスについては、「SAML 設定の概要」を参照してください。

ヒント

これらの URLs は、後でドメインのカスタムエンドポイントを有効にすると変更されます。その場合、IdP を更新する必要があります。
これらの値を使用して ID プロバイダーを設定します。これはプロセスで最も複雑な部分です。ただし、用語やステップはプロバイダーによって大きく異なります。プロバイダのドキュメントを参照してください。

Okta では、たとえば「SAML 2.0 ウェブアプリケーション」を作成します。[Single sign on URL (シングルサインオン URL)] で、ステップ 3 で選択した SSO URL を指定します。[Audience URI (SP Entity ID) (対象者 URI (SP エンティティ ID))] に、SP エンティティ ID を指定します。

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

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

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

メタデータファイルの内容をコピーして、AWS コンソールの [IdPIDP のメタデータ] フィールドに貼り付けます。または、[Import from XML file (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>

メタデータファイルから entityID プロパティの内容をコピーして、AWS コンソールの [IDP entity ID (IDP エンティティ ID)] フィールドに貼り付けます。多くの ID プロバイダーでは、この値を設定後の要約の一部として表示します。プロバイダーによっては、それを「発行者」と呼びます。
[SAML マスターユーザー名] や [SAML マスターバックエンドロール] を指定します。このユーザー名またはバックエンドロールは、新しいマスターユーザーと同等のクラスターへの完全なアクセス権限を受け取りますが、Kibana 内でのみそれらのアクセス権限を使用できます。

たとえば、Okta では、グループ jdoe に属するユーザー admins がいる場合があります。 [jdoeSAML マスターユーザー名] フィールドに を追加すると、そのユーザーだけが完全なアクセス許可を受け取ります。[adminsSAML マスターバックエンドロール] フィールドに を追加すると、admins グループに属するすべてのユーザーが完全なアクセス許可を受け取ります。

SAML アサーションの内容は、SAML マスターユーザー名あるいは SAML マスターロールに使用する文字列と完全に一致する必要があります。一部の ID プロバイダーはユーザー名の前にプレフィックスを追加するため、診断が困難な不一致の原因となる場合があります。ID プロバイダーのユーザーインターフェイスで、jdoe が表示されることがありますが、SAML アサーションに auth0|jdoe が含まれている可能性があります。常に SAML アサーションの文字列を使用します。

多くの ID プロバイダーでは、設定プロセス中にサンプルのアサーションを表示できます。また、SAML-tracer などのツールを使用すると、実際のアサーションの内容を検証およびトラブルシューティングするのに役立ちます。アサーションは次のようになります。
```
<?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/_plugin/kibana/_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>
```
[Optional SAML settings] セクションを展開します。
ユーザー名に SAML アサーションの 要素を使用するには、[Subject keyNameID] フィールドを空白のままにします。アサーションがこの標準要素を使用せず、代わりにユーザー名をカスタム属性として含める場合は、ここでその属性を指定します。

バックエンドロールを使用する場合 (推奨) は、[ロールキー] フィールドでアサーションからの属性 (role や group など) を指定します。これは、SAML-tracer などのツールが役に立つ可能性があるもう 1 つの状況です。
デフォルトでは、Kibana は 60 分後にユーザーをログアウトします。[Session time to live] フィールドを使用して、この値を 1,440 (24 時間) まで増やすことができます。
[Submit] を選択します。ドメインは約 1 分間処理状態になり、その間 Kibana は使用できなくなります。
ドメインの処理が終了したら、Kibana を開きます。
- SP によって開始された URL を選択した場合は、domain-endpoint/_plugin/kibana/ に移動します。
- によって開始された URL を選択した場合は、ID プロバイダーのアプリケーションディレクトリに移動します。IdP
どちらの場合も、SAML マスターユーザーとしてログインするか、SAML マスターバックエンドロールに属するユーザーとしてログインします。ステップ 7 の例を続行するには、jdoe または admins グループのメンバーとしてログインします。
Kibana がロードされたら、[Security] と [Roles] を選択します。

他のユーザーが Kibana にアクセスできるようにする [ Map roles (ロールのマップ)]。

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

Kibana の代わりに API を使用する場合は、次のサンプルリクエストを参照してください。


PATCH _opendistro/_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": "/kibanauser", "value": { "backend_roles": ["analysts"] }
  }
]

CLI コマンドの例

次の AWS CLI コマンドは、既存のドメインで Kibana の SAML 認証を有効にします。


aws es update-elasticsearch-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\">\n や改行ではなく、<KeyDescriptor use="signing"> を使用します。の使用方法の詳細については、「AWS CLI」を参照してください。AWS CLI Command Reference

設定 API リクエストの例

次の設定 API に対するリクエストは、既存のドメインで Kibana の SAML 認証を有効にします。


POST https://es.us-east-1.amazonaws.com/2015-01-01/es/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\">\n や改行ではなく、<KeyDescriptor use="signing"> を使用します。設定 API の使用の詳細については、「Amazon Elasticsearch Service 設定 API リファレンス」を参照してください。

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

エラー	詳細
`Your request: '/some/path' is not allowed.`	ID プロバイダーに正しい SSO URL (ステップ 3) を指定したことを確認します。
`Please provide valid identity provider metadata document to enable SAML.`	メタデータファイルは SAML 2.0 規格に適合していません。IdP検証ツールを使用してエラーを確認します。
SAML 設定オプションはコンソールに表示されません。	最新のサービスソフトウェアに更新します。
`SAML configuration error: Something went wrong while retrieving the SAML configuration, please check your settings.`	この一般的なエラーは、多くの原因で発生することがあります。正しい SP エンティティ ID および SSO URL を ID プロバイダーに指定していることを確認します。メタデータファイルを再生成し、IdP エンティティ ID を確認します。IdPAWS コンソールで更新されたメタデータを追加します。ドメインアクセスポリシーで Kibana と `_opendistro/_security/*` へのアクセスが許可されていることを確認します。ドメインのオープンアクセスポリシーは、通常、きめ細かなアクセスコントロールを使用します。 SAML を設定する手順については、ID プロバイダーのドキュメントを参照してください。
`Missing role: No roles available for this user, please contact your system administrator.`	正常に認証されましたが、SAML アサーションからのユーザー名とバックエンドロールはどのロールにもマッピングされないため、アクセス許可がありません。これらのマッピングでは、大文字と小文字が区別されます。 SAML-tracer などのツールを使用して SAML アサーションの内容を確認し、次の呼び出しを使用してロールマッピングを確認します。 `GET _opendistro/_security/api/rolesmapping`
Kibana にアクセスを試みると、ブラウザは継続的に HTTP 500 エラーをリダイレクトまたは受信します。	これらのエラーは、SAML アサーションに約 1,500 文字の大量のロールが含まれている場合に発生することがあります。たとえば、80 個のロールを渡した場合、その平均長は 20 文字となり、ウェブブラウザの Cookie のサイズ制限を超える可能性があります。

SAML 認証の無効化

Kibana の SAML 認証を無効にするには (コンソール)

ドメイン、[Actions]、および [Modify authentication] を選択します。
[Enable SAML authentication] をオフにします。
[Submit] を選択します。
ドメインの処理が終了したら、次の呼び出しを使用してきめ細かなアクセスコントロールのロールマッピングを確認します。
```
GET _opendistro/_security/api/rolesmapping
```
Kibana の SAML 認証を無効にしても、SAML マスターユーザー名または SAML マスターバックエンドロールのマッピングは削除されません。これらのマッピングを削除する場合は、内部ユーザーデータベース (有効になっている場合) を使用して Kibana にログインするか、API を使用して削除します。
```
PUT _opendistro/_security/api/rolesmapping/all_access
{
  "users": [
    "master-user"
  ]
}
```

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

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

ドキュメントの表記規則

インフラストラクチャセキュリティ

Amazon CognitoKibana の認証