SAML OpenSearch Dashboards の認証

SAML OpenSearch Dashboards の認証を使用すると、既存の 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.

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

SAML 設定の概要

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

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

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

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

考慮事項

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

SAML VPCドメインの認証

SAML は、ID プロバイダーとサービスプロバイダー間の直接通信を必要としません。したがって、 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/*"
    }
  ]
}

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

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

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

ドメインの作成時にSAML認証を有効にするか、アクション 、既存のドメインでセキュリティ設定を編集する を選択します。以下のステップは、どちらを選択するかに応じて若干異なります。

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

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

SAML 認証を設定するタイミングに応じて、次の手順を実行します。

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

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

カスタムエンドポイント を使用している場合は、 URLsがどのようになるかを推測できます。例えば、カスタムエンドポイントが の場合www.custom-endpoint.com、サービスプロバイダーエンティティ ID は www.custom-endpoint.com、IdP 開始SSOURLは www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated、SP 開始は SSOURLになりますwww.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs。ドメインを作成される前に、これらの値を使用して ID プロバイダーを設定できます。例については、次のセクションを参照ください。

カスタムエンドポイントを使用していない場合は、IdP に一時的な値を入力して必要なメタデータを生成し、ドメインがアクティブになった後でそれらを更新することができます。

例えば、Okta 内では、https://temp-endpoint.amazonaws.comシングルサインオンURLフィールドとオーディエンス URI (SP エンティティ ID) フィールドに入力できます。これにより、メタデータを生成できます。その後、ドメインがアクティブになったら、 OpenSearch サービスから正しい値を取得し、Okta で更新できます。手順については、ステップ 6: IdP を更新する URLs を参照してください。

既存のドメインを編集している場合

既存のドメインでSAML認証を有効にする場合は、サービスプロバイダーエンティティ ID と SSO のいずれかをコピーしますURLs。使用するガイダンスについてはURL、「」を参照してくださいSAML 設定の概要。

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

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

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

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

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

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

ID プロバイダーを設定すると、IdP メタデータファイルが生成されます。このXMLファイルには、TLS証明書、シングルサインオンエンドポイント、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 サービスコンソールで次の追加フィールドを設定します。

多くの 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/_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] (その他の設定) で、次のオプションフィールドを設定します。

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

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

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

を取得するにはURLs、ドメインを選択し、アクション、セキュリティ設定の編集 を選択します。SAML OpenSearch Dashboards/Kibana の認証では、正しいサービスプロバイダーエンティティ ID と SSO を見つけることができますURLs。値をコピーし、それらを使用して ID プロバイダーを設定し、ステップ 2 でURLs指定した一時 を置き換えます。

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

ドメインのステータスがアクティブで、IdP が正しく設定されると、 OpenSearch Dashboards に移動します。

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

OpenSearch Dashboards がロードされたら、セキュリティ、ロール を選択します。次に、ロールをマッピングして、他のユーザーが OpenSearch Dashboards にアクセスできるようにします。

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

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

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

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）

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

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 トラブルシューティング

GET _plugins/_security/api/rolesmapping

SAML 認証の無効化