SAML OpenSearch ダッシュボードの認証

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

Amazon Cognito または内部ユーザーデータベース を介して認証するのではなく、 OpenSearch ダッシュボードの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 ダッシュボードで SP 主導または IdP 主導SAMLの認証で認証を有効にする方法について説明します。両方を有効にするために必要な追加のステップについては、「SP 開始認証と IdP 開始認証の両方を有効にする」を参照してください。

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

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

ドメイン設定内で、SAML OpenSearch ダッシュボード/Kibana の認証で、SAML認証を有効にする を選択します。

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

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

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

新しいドメインの作成中である場合、 OpenSearch Service はサービスプロバイダーエンティティ 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 Service から正しい値を取得し、Okta で更新できます。手順については、ステップ 6: IdP を更新する URLs を参照してください。

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

既存のドメインでSAML認証を有効にする場合は、サービスプロバイダーエンティティ ID と の 1 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 ダッシュボードに移動します。

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

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

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

OpenSearch ダッシュボード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 ダッシュボードの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 ダッシュボードの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 認証の無効化