ステップ 1: ID プロバイダーアプリケーションを設定する (Okta)ステップ 2: Okta AWS の設定をセットアップするステップ 3: IAM で Amazon OpenSearch Service アクセスポリシーを作成するステップ 4: SAML で ID プロバイダーが開始したシングルサインオンエクスペリエンスを検証する

を使用した SAML フェデレーションの有効化 AWS Identity and Access Management

OpenSearch UI は、多くの ID プロバイダーが使用するオープンスタンダードである Security Assertion Markup Language 2.0 (SAML) をサポートしています。これにより、 AWS Identity and Access Management (IAM) との ID フェデレーションが有効になります。このサポートにより、アカウントまたは組織のユーザーは、IAM ロールを引き受けることで OpenSearch UI に直接アクセスできます。エンドユーザーが外部 ID プロバイダーで認証し、OpenSearch UI の定義されたページに直接ルーティングできる ID プロバイダー主導 (IdP) シングルサインオンエクスペリエンスを作成できます。OpenSearch UI および関連するデータソースにアクセスするためのアクセス許可が異なるさまざまな IAM ロールを引き受けるようにエンドユーザーまたはグループを設定することで、きめ細かなアクセスコントロールを実装することもできます。

このトピックではstep-by-step。 OpenSearch これらの手順では、例として Okta アイデンティティおよびアクセス管理アプリケーションを設定する手順を使用します。Azure Active Directory や Ping など、他の ID プロバイダーの設定手順は似ています。

トピック

ステップ 1: ID プロバイダーアプリケーションを設定する (Okta)
ステップ 2: Okta AWS の設定をセットアップする
ステップ 3: IAM で Amazon OpenSearch Service アクセスポリシーを作成する
ステップ 4: SAML で ID プロバイダーが開始したシングルサインオンエクスペリエンスを検証する

ステップ 1: ID プロバイダーアプリケーションを設定する (Okta)

OpenSearch UI で SAML を使用するには、まず ID プロバイダーを設定します。

タスク 1: Okta ユーザーを作成する

管理者権限を持つユーザーとして、https://login.okta.com/ で Okta 組織にサインインします。
管理者コンソールのナビゲーションペインのディレクトリで、人を選択します。
[Add Person] (ユーザーを追加) を選択します。
名には、ユーザーの名を入力します。
姓には、ユーザーの姓を入力します。
Username には、ユーザーのユーザー名を E メール形式で入力します。
「パスワードを設定してパスワードを入力する」を選択します。
（オプション) ユーザーが初回サインイン時にパスワードを変更しない場合は、最初のログインボックスでパスワードを変更する必要があります。
[保存] を選択します。

タスク 2: グループを作成して割り当てる

管理者権限を持つユーザーとして、https://login.okta.com/ で Okta 組織にサインインします。
管理コンソールのナビゲーションペインのディレクトリで、グループを選択します。
[グループの追加] を選択します。
グループ名を入力し、保存を選択します。
新しく作成したグループを選択し、ユーザーの割り当てを選択します。
プラス記号 (＋) を選択し、完了を選択します。
（オプション) ステップ 1～6 を繰り返して、グループを追加します。

タスク 3: Okta アプリケーションを作成する

管理者権限を持つユーザーとして、https://login.okta.com/ で Okta 組織にサインインします。
管理コンソールのナビゲーションペインのアプリケーションで、アプリケーションを選択します。
[Create App Integration] (アプリの統合の作成) を選択します。
サインイン方法として SAML 2.0 を選択し、次へを選択します。
アプリ統合の名前 (例: OpenSearch_UI) を入力し、次へを選択します。
アプリに次の値を入力します。他の値を変更する必要はありません。
1. 1. シングルサインオン URL の場合は、商用 AWS リージョンhttps://signin.aws.amazon.com/samlにを入力するか、リージョンに固有の URL を入力します。
2. 2. オーディエンス URI (SP エンティティ ID) には、と入力しますurn:amazon:webservices。
3. 3. 名前 ID 形式には、と入力しますEmailAddress。
[次へ] を選択します。
「Okta のお客様が内部アプリを追加している」を選択し、「これは作成した内部アプリです」を選択します。
[Finish] を選択してください。
「割り当て」を選択し、「割り当て」を選択します。
グループに割り当てる を選択し、追加するグループの横にある割り当て を選択します。
[完了] をクリックします。

タスク 4: Okta の詳細設定をセットアップする

カスタム SAML アプリケーションを作成したら、次の手順を実行します。

管理者権限を持つユーザーとして、https://login.okta.com/ で Okta 組織にサインインします。

管理者コンソールの全般エリアで、SAML 設定で編集を選択します。
[次へ] を選択します。
次の形式を使用して、デフォルトのリレー状態を OpenSearch UI エンドポイントに設定します。

https://region.console.aws.amazon.com/aos/home?region=region#opensearch/applications/application-id/redirectToDashboardURL.

以下に例を示します。

https://us-east-2.console.aws.amazon.com/aos/home?region=us-east-2#opensearch/applications/abc123def4567EXAMPLE/redirectToDashboardURL

属性ステートメント (オプション） で、次のプロパティを追加します。

Role 属性を使用して、IAM ロールと ID プロバイダーをカンマ区切り形式で指定します。この同じ IAM ロールと ID プロバイダーは、後のステップで AWS 設定時に使用します。
RoleSessionName の user.login を設定します。これは、ロールが引き受けられたときに発行される一時的な認証情報の識別子として使用されます。

参考：

名前	名前形式	形式	例
`https://aws.amazon.com/SAML/Attributes/Role`	未指定	`arn:aws:iam::aws-account-id:role/role-name,arn:aws:iam::aws-account-id:saml-provider/provider-name`	`arn:aws:iam::111222333444:role/oktarole,arn:aws:iam::111222333444:saml-provider/oktaidp`
`https://aws.amazon.com/SAML/Attributes/RoleSessionName`	未指定	`user.login`	`user.login`

属性プロパティを追加したら、次へを選択し、終了を選択します。

属性は、次の図に示す形式と似ている必要があります。デフォルトのリレーステート値は、Okta からのシングルサインオン検証を完了した後、アカウントまたは組織のエンドユーザーのランディングページを定義する URL です。OpenSearch UI の任意のページに設定し、その URL を目的のエンドユーザーに提供できます。

「SAML 2.0」領域は、アプリケーションのデフォルトのリレーステート URL とメタデータ URL を報告します。

ステップ 2: Okta AWS の設定をセットアップする

Okta AWS の設定を設定するには、次のタスクを実行します。

タスク 1: Okta 情報を収集する

このステップでは、Okta 情報を収集して、後で設定できるようにする必要があります AWS。

管理者権限を持つユーザーとして、https://login.okta.com/ で Okta 組織にサインインします。
サインオンタブのページの右下隅で、SAML セットアップ手順の表示を選択します。
ID プロバイダーのシングルサインオン URL の値を書き留めます。この URL は、SQL Workbench/J などのサードパーティー SQL クライアントに接続するときに使用できます。
ブロック 4 で ID プロバイダーメタデータを使用し、メタデータファイルを .xml 形式 (例: metadata.xml) で保存します。

タスク 2: IAM プロバイダーを作成する

IAM プロバイダーを作成するには、次の手順を実行します。

にサインイン AWS Management Console し、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
ナビゲーションペインのアクセス管理 で、ID プロバイダーを選択します。
[プロバイダーを追加] をクリックします。
プロバイダータイプ で SAML を選択します。
プロバイダー名 に名前を入力します。
メタデータドキュメントで、ファイルの選択を選択し、前にダウンロードしたメタデータファイル (.xml) をアップロードします。
[プロバイダーを追加] をクリックします。

タスク 3: IAM ロールを作成する

AWS Identity and Access Management ロールを作成するには、次の手順を実行します。

にサインイン AWS Management Console し、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
ナビゲーションペインのアクセス管理 で、ロールを選択します。
[ロールの作成] を選択してください。
信頼できるエンティティタイプで、SAML 2.0 フェデレーションを選択します。
SAML 2.0 ベースのプロバイダーの場合は、前に作成した ID プロバイダーを選択します。
プログラムによるアクセスと AWS Management Console アクセスを許可するを選択します。
[次へ] を選択します。
アクセス許可ポリシーリストで、前に作成したポリシーと OpenSearchFullAccess のチェックボックスをオンにします。
[次へ] を選択します。
レビューエリアのロール名に、ロールの名前を入力します。たとえば、ですoktarole。
（オプション) 説明に、ロールの目的の簡単な説明を入力します。
[ロールの作成] を選択してください。
作成したロールに移動し、信頼関係タブを選択し、信頼ポリシーの編集を選択します。
ステートメントの編集ペインの「STS のアクションを追加する」で、TagSession のボックスを選択します。
[ポリシーの更新] を選択してください。

ステップ 3: IAM で Amazon OpenSearch Service アクセスポリシーを作成する

このトピックでは、OpenSearch サービスにアクセスできる IAM ロールを設定する方法について説明します。Okta からユーザーグループにきめ細かなアクセスコントロールを実現する方法を示すためにBob、 Aliceとの 2 つのグループの例を示します。

次の例に示すように、バックエンドロールマッピングを使用して Amazon OpenSearch Service ドメインロールを IAM ロールにマッピングできます。


{
  "bob-group": {
    "hosts": [],
    "users": [],
    "reserved": false,
    "hidden": false,
    "backend_roles": [
      "arn:aws:iam::111222333444:role/bob-group"
    ],
    "and_backend_roles": []
  },
  "alice-group": {
    "hosts": [],
    "users": [],
    "reserved": false,
    "hidden": false,
    "backend_roles": [
      "arn:aws:iam::111222333444:role/alice-group"
    ],
    "and_backend_roles": []
  }
}

ステップ 4: SAML で ID プロバイダーが開始したシングルサインオンエクスペリエンスを検証する

デフォルトのリレー状態の URL を開き、Okta 認証ページを開きます。エンドユーザーの認証情報を入力します。OpenSearch UI に自動的にリダイレクトされます。

次の図に示すように、ナビゲーションパネルの下部にあるユーザーアイコンを選択すると、現在の認証情報を確認できます。

ナビゲーションパネルの下部にある開発者ツールにアクセスし、コンソールでクエリを実行することで、ユーザーのきめ細かなアクセスコントロールのアクセス許可を確認することもできます。以下は、サンプルクエリです。

Example 1: Displays information about the current user

リクエスト:


GET _plugins/_security/api/account

結果:


{
  "user_name": "arn:aws:iam::XXXXXXXXXXXX:role/bob-group",
  "is_reserved": false,
  "is_hidden": false,
  "is_internal_user": false,
  "user_requested_tenant": null,
  "backend_roles": [
    "arn:aws:iam::XXXXXXXXXXXX:role/bob-group"
  ],
  "custom_attribute_names": [],
  "tenants": {
    "global_tenant": true,
    "arn:aws:iam::XXXXXXXXXXXX:role/bob-group": true
  },
  "roles": [
    "bob-group"
  ]
}

Example 2: Displays actions permitted for a user

リクエスト:


GET bob-test/_search

結果:


{
  "took": 390,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "bob-test",
        "_id": "ui01N5UBCIHpjO8Jlvfy",
        "_score": 1,
        "_source": {
          "title": "Your Name",
          "year": "2016"
        }
      }
    ]
  }
}

Example 3: Displays actions not permitted for a user

リクエスト:


GET alice-test

結果:


{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
      }
    ],
    "type": "security_exception",
    "reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
  },
  "status": 403
}

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

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

ドキュメントの表記規則

入門

データソースの関連付けと VPC アクセス許可の管理