OpenSearch Dashboards の SAML 認証 - Amazon OpenSearch Service

OpenSearch Dashboards の SAML 認証

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

Amazon Cognito または内部ユーザーデータベースを介して認証するのではなく、OpenSearch Dashboards の SAML 認証により、サードパーティーの ID プロバイダーを使用して Dashboards へのログイン、詳細なアクセスコントロールの管理、データの検索、視覚化の構築を行うことができます。OpenSearch Service は、Okta、Keycloak、Active Directory Federation Services (ADFS)、Auth0 など、SAML 2.0 標準を使用するプロバイダーをサポートします。

注記

OpenSearch Service からサードパーティープロバイダーへのリクエストは、サービスプロバイダー証明書で明示的に暗号化されません。

Dashboards の SAML 認証は、ウェブブラウザから OpenSearch Dashboards にアクセスするためのものです。お客様のSAML認証情報では、OpenSearch または Dashboards API への直接 HTTP リクエストを行うことはできません

SAML 設定の概要

このドキュメントでは、既存の ID プロバイダーがあり、そのプロバイダーに精通していることを前提としています。OpenSearch Service ドメインについてのみ、お客様のプロバイダーの詳細な設定手順は提供できません。

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

  • サービスプロバイダー (SP) が開始されている: Dashboards に移動します (例えば、https://my-domain.us-east-1.es.amazonaws.com/_dashboards)。これにより、ログイン画面にリダイレクトされます。ログイン後、ID プロバイダーはお客様を Dashboards にリダイレクトします。

  • ID プロバイダー (IdP) が開始されている: ID プロバイダーに移動してログインし、アプリケーションディレクトリから Dashboards を選択します。

OpenSearch Service には、SP 開始と IdP 開始の 2 つの Single Sign-On URL が用意されていますが、目的の Dashboards ログインフローに一致するもののみが必要です。SP 開始認証と IdP 開始認証の両方を設定する場合は、ID プロバイダーを通じて設定する必要があります。例えば、Oktaでは、[このアプリが他の SSO URL をリクエストすることを許可する] を有効にして、1 つ以上の IdP 開始の SSO URL を追加することができます。

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

注記

SSO URL をサービス提供された値から変更することはできません。そのため、Dashboards の SAML 認証はプロキシサーバーをサポートしません。

VPC で実行されているドメインの SAML 認証

SAML は、アイデンティティプロバイダーとサービスプロバイダー間の直接的な通信を必要としません。したがって、OpenSearch ドメインがプライベート VPC 内でホストされている場合でも、ブラウザが OpenSearch クラスターとアイデンティティプロバイダーの両方と通信できる限り、SAML を使用できます。ブラウザは、基本的にアイデンティティプロバイダーとサービスプロバイダーの仲介として機能します。SAML 認証フローを説明する便利な図表については、Okta のドキュメントを参照してください。

IAM 認証の有効化

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

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

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

  1. ドメインを選択し、[アクション] から [セキュリティ設定の編集] を選択します。

  2. [SAML 認証を有効にする] を選択します。

  3. サービスプロバイダーエンティティ ID と 2 つの SSO URL を書き留めます。必要なのは SSO URL のうちの 1 つだけです。ガイダンスについては、「SAML 設定の概要」を参照してください。

    ヒント

    後でドメインの [カスタムエンドポイント] を有効にした場合、これらの URL は変わります。この場合、IdP を更新する必要があります。

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

    例えば、Okta では、「SAML 2.0 ウェブアプリケーション」を作成します。Single Sign On URL では、ステップ 3 で選択した SSO URL を指定します。Audience URI (SP エンティティ ID) では、SP エンティティ ID を指定します。

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

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

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

    IdP メタデータファイルの内容をコピーし、OpenSearch Service コンソールの [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>
  6. メタデータファイルから entityID プロパティの値をコピーし、OpenSearch Service コンソールの [IdP エンティティ ID] フィールドにそれを貼り付けます。多くの ID プロバイダーは、この値も設定後の概要の一部として表示します。一部のプロバイダーは、それを「発行者」と呼んでいます。

  7. SAML マスターユーザーネームおよび/または SAML マスターバックエンドロールを指定します。このユーザーネームおよび/またはバックエンドロールは、クラスターに対する完全な許可を受け取ります。これは、新しいマスターユーザーと同等ですが、Dashboards 内でのみこれらの許可を使用できます。

    例えば、Okta では、グループ admins に属しているユーザー jdoe がある可能性があります。jdoe を [SAML マスターユーザーネーム] フィールドに追加した場合、そのユーザーのみが完全な許可を受け取ります。admins を [SAML マスターバックエンドロール] フィールドに追加した場合、admins グループに属している任意のユーザーが完全な許可を受け取ります。

    SAML アサーションの内容は、SAML マスターユーザーネームおよび/または SAML マスターロールで使用する文字列と正確に一致する必要があります。一部の ID プロバイダーは、ユーザーネームの前にプレフィックスを追加するので、診断が難しいミスマッチを引き起こす可能性があります。ID プロバイダーのユーザーインターフェイスで、jdoe を確認できる場合がありますが、SAML アサーションには auth0|jdoe が含まれている可能性があります。常に SAML アサーションからの文字列を使用します。

    多くの ID プロバイダーでは、設定プロセス中にサンプルのアサーションを表示できます。また、SAML トレーサーは、実際のアサーションの内容を調べてトラブルシューティングするのに役立ちます。アサーションは次のようになります。

    <?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/_plugins/_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>
  8. (オプション)[追加設定] を展開します。

  9. [件名キー] フィールドを空のままにして、ユーザーネームのSAMLアサーションの NameID エレメントを使用します。アサーションでこの標準エレメントを使用せず、代わりにユーザーネームをカスタム属性として含める場合は、ここでその属性を指定します。

    バックエンドロール (推奨) を使用する場合は、アサーションからの属性を、rolegroup など、[ロールキー] フィールドで指定します。これは、SAML トレーサーなど、どのツールが役立つかという別の状況です。

  10. デフォルトでは、OpenSearch Dashboards は 24 時間後にユーザーをログアウトします。[Session time to live] (セッションの有効期限 (TTL)) を指定することで、この値を 60~1,440 (24 時間) の間に設定することができます。

  11. [Save changes] (変更の保存) をクリックします。ドメインが約 1 分間処理状態になり、その間、Dashboards は使用できなくなります。

  12. ドメインの処理が完了したら、Dashboards を開きます。

    • SP 開始の URL を選択した場合は、domain-endpoint/_dashboards/ に移動します。

    • IdP 開始の URL を選択した場合は、ID プロバイダーのアプリケーションディレクトリに移動します。

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

  13. Dashboards が読み込まれたら、[セキュリティ] および [ロール] を選択します。

  14. [ロールのマッピング] を選択して、他のユーザーが Dashboards にアクセスできるようにします。

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

    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": "/kibana_user", "value": { "backend_roles": ["analysts"] } } ]

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 コマンドリファレンス」を参照してください。

設定 API リクエストの例

設定 API への次のリクエストにより、既存のドメイン上の OpenSearch Dashboards の SAML 認証を有効にします。

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 の使用方法の詳細については、「Amazon OpenSearch Service の設定 API リファレンス」を参照してください。

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

エラー 詳細

リクエスト: '/some/path' は許可されていません。

正しい SSO URL (ステップ 3) を ID プロバイダーに提供したことを確認します。

SAML を有効にするには、有効な ID プロバイダーメタデータドキュメントを指定してください。

IdP メタデータファイルは SAML 2.0 標準に準拠していません。検証ツールを使用してエラーをチェックします。

SAML 設定オプションは、コンソールでは表示されません。

最新のサービスソフトウェアに更新します。

SAML 設定エラー: SAML 設定を取得中に問題が発生しました。設定を確認してください。

この一般的なエラーは、さまざまな原因で発生することがあります。

  • ID プロバイダーに正しい SP エンティティ ID と SSO URL が指定されていることを確認します。

  • IdP メタデータファイルを再生成し、IdP エンティティ ID を確認します。更新されたメタデータを AWS コンソールに追加します。

  • ドメインアクセスポリシーで、OpenSearch Dashboards と _plugins/_security/* へのアクセスが許可されていることを確認します。一般的に、きめ細かなアクセスコントロールを使用するドメインではオープンアクセスポリシーを使用することをお勧めします。

  • SAML の設定のステップについては、ID プロバイダーのドキュメントを参照してください。

役割がありません: このユーザーには使用できる役割がありません。システム管理者に連絡してください。

認証に成功しましたが、ユーザーネームおよび SAML アサーションからのバックエンドロールはどのロールにもマッピングされていないため、許可がありません。これらのマッピングでは、大文字と小文字が区別されます。

SAML トレーサーのようなツールを使用して、SAML アサーションの内容を確認し、次の呼び出しを使用してロールマッピングを確認します。

GET _plugins/_security/api/rolesmapping

OpenSearch Dashboards にアクセスしようとすると、ブラウザが HTTP 500 エラーを継続的にリダイレクトまたは受け取ります。

このエラーは、SAML アサーションに合計約 1,500 文字の多数のロールが含まれている場合に発生します。例えば、平均の長さが 20 文字である 80 ロールを渡すと、ウェブブラウザの Cookie のサイズ制限を超える可能性があります。

ADFS からログアウトすることはできません。

ADFS では、OpenSearch Service がサポートしていないすべてのログアウトリクエストに署名する必要があります。IdP メタデータファイルから <SingleLogoutService /> を削除して、OpenSearch Service が独自の内部ログアウトメカニズムを使用するように強制します。

SAML 認証の無効化

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

  1. ドメインを選択し、[アクション] から [セキュリティ設定の編集] を選択します。

  2. [SAML 認証を有効にする] のチェックを外します。

  3. [Save changes] (変更の保存) をクリックします。

  4. ドメインの処理が終了したら、次のリクエストを用いてきめ細かなアクセスコントロールのロールマッピングを確認します。

    GET _plugins/_security/api/rolesmapping

    Dashboards の SAML 認証を無効にしても、SAML マスターユーザーネームおよび/または SAML マスターバックエンドロールのマッピングを削除しません。これらのマッピングを削除する場合は、内部ユーザーデータベース (有効な場合) を使用して Dashboards にログインするか、API を使用してそれらを削除します。

    PUT _plugins/_security/api/rolesmapping/all_access { "users": [ "master-user" ] }