Okta を使用した Amazon Connect のシングルサインオン設定

IT リソースへのアクセスを保護することは非常に重要です。従業員が使用するウェブベースのアプリケーションの数が増えるにつれて、ログイン認証情報を記憶しておくことは困難になります。多くの企業では、リソースへのアクセスを合理化し、従業員のルーチンを簡素化するために、さまざまな ID プロバイダーによるシングルサインオンを採用しています。Amazon Connectは、SAML 2.0準拠のIDプロバイダーを使用したコンタクトセンターへの認証を提供可能です。このBlogでは、OktaをAmazon ConnectのIDプロバイダーとして使用するために必要な手順についてご説明します。

Oktaは、SAML 2.0認証を使用したSingle Single-Onサービスとして、最も一般的に使用されているプロバイダーの1つです。Oktaのセットアップ方法は他のSAML プロバイダーの設定とほとんど同じですが、本投稿ではOktaを使用するためのステップを具体的にご説明します。これは、一般的なガイダンスであるAmazon ConnectでのID管理用にSAMLを設定するを簡略化したものになっています。

本投稿で行う設定では、以下を使用します。

このステップを完了するには、以下が必要です。

アクティブなAWSアカウント。
新しいIAM ロール、ポリシー、およびユーザーを作成できるIAM権限。
新しいAmazon Connectインスタンスを作成できるIAM権限。
Oktaアカウント。
本投稿では、Okta 開発者アカウントを使用したステップを示します。これは機能的には標準のアカウントと変わりません。

Amazon Connect インスタンスを作成する

Amazon Connect ではインスタンスの作成時に、使用するID管理システムを選択します。一度選択すると、後で変更することはできません。そのため、Oktaと統合するために、新しいAmazon Connectインスタンスを作成する必要があります。このブログでは、Amazon Connect設定の詳細については説明いたしません。Amazon Connectインスタンスの設定方法の詳細については、Amazon Connect 管理者ガイドの Amazon Connect の使用開始セクションを参照してください。

SAML 2.0 ベースの認証を使用するAmazon Connectインスタンスを新規作成するには:

AWS マネジメントコンソールでAmazon Connectコンソールを開きます。
使用するリージョンを確認します。
以下のいずれかを実行します。
- 選択したリージョンで Amazon Connect インスタンスをまだ作成していない場合は、”今すぐ始める”を選択します。
- 選択したリージョンで Amazon Connect インスタンスを以前に作成している場合は、”インスタンスを追加する”を選択します。
“ステップ 1: ID管理” で、”SAML 2.0ベースの認証” を選択します。
“アクセスURL” に、インスタンスのインスタンスエイリアスを入力し、”次のステップ” を選択します。
注意:入力した名前は、AWSマネジメントコンソールにインスタンスエイリアスとして表示され、Okta を設定するときのアクセスURLのドメイン名として使用されます。エイリアスはグローバルに一意である必要があり、インスタンスの作成後に変更することはできません。
“ステップ 2:管理者” で、インスタンスの管理者として使用するアカウントの名、姓、ユーザー名を入力し、”次のステップ” を選択します。これは、Oktaに既に存在するユーザー名である必要があります。
- 注意:入力するユーザー名は、大文字小文字を含めてOktaのユーザー名と正確に一致することが重要です。
“ステップ 3:テレフォニーオプション”はデフォルトのままで、次のステップを選択します（後で変更できます）。
“ステップ 4: データストレージ” はデフォルトのままで、次のステップを選択します（後で変更できます）。
“ステップ 5:レビューと作成”で、設定を確認し、”インスタンスの作成”を選択します。
インスタンスが作成された後は、コンタクトセンターのセットアップを行う事ができます(Amazon Connectのドキュメントを参照してください)。

Amazon Connectインスタンスが作成されましたので、OktaがリソースにアクセスするためのAWS Identity and Access Management(IAM) ポリシーを作成します。

IAMポリシーを作成する

SAML統合のために、特定のリソースへのアクセスを許可する適切なポリシー作成が必要です。ここでは必須となる2つのポリシーを作成します。1つ目のポリシーでは、このAmazon Connectインスタンスのすべてのユーザーに対してフェデレーションを許可します。2つ目のポリシーでは、OktaがIAM ロールとアカウントエイリアスを一覧表示することを許可します。

Amazon Connectのフェデレーションポリシーを作成するには :

IAM コンソールを開きます。
ナビゲーションペインで、 “ポリシー”を選択します。
“ポリシーの作成”を選択します。
JSONタブを選択します。

次のポリシーをエディタに貼り付けて、既存のコンテンツを置き換えます。

{
   "Version": "2012-10-17",
   "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": "connect:GetFederationToken",
            "Resource": [
                "**YOUR ARN**/user/${aws:userid}"
            ]
        }
    ]
}

**YOUR ARN**の部分をAmazon ConnectインスタンスのARNに変更します。ARNを参照するには :
a. 新しいタブを開き、Amazon Connectコンソールに移動します。
b. インスタンスエイリアスを選択します。
c. インスタンス ARN の値をコピーします。
**YOUR ARN**の変更を確認し、 “ポリシーの確認”を選択します。
ポリシーに okta_federation_policy など名前を付けます。
オプションで、ポリシーの説明を入力します。
“ポリシーの作成”を選択します。

Oktaのアクセスポリシーを作成するには :

IAM コンソールを開きます。
ナビゲーションペインで、 “ポリシー”を選択します。
“ポリシーの作成”を選択します。
JSONタブを選択します。

次のポリシーをエディタに貼り付けて、既存のコンテンツを置き換えます。

{
   "Version": "2012-10-17",
   "Statement": [
        {
          "Effect": "Allow",
          "Action": [
              "iam:ListRoles",
              "iam:ListAccountAliases"
          ],
          "Resource": "*"
        }
    ]
}

置き換えを確認し、”ポリシーの確認”を選択します。
ポリシーに okta_cli_policy など名前を付けます。
オプションで、ポリシーの説明を入力します。
ポリシーの作成を選択します。

ポリシーが作成できたら、AWSリソースへプログラムからアクセスするIAM ユーザーを作成します。これにより、OktaはAWSアカウントから適切なリソースを取得できるようになります。

ユーザーを作成するには :

IAM コンソールを開きます。
ナビゲーションペインで、 “ユーザー”を選択します。
“ユーザーを追加”を選択します。
“ユーザー詳細の設定”セクションで、ユーザー名（okta_cli_user など）を入力します。
“AWSアクセスの種類を選択”セクションで、”プログラムによるアクセス”を選択します。
“次のステップ：アクセス権限”を選択します。
“アクセス許可の設定”セクションで、 “既存のポリシーを直接アタッチ”を選択します。
検索フィールドに”okta”と入力します。使用可能なポリシーが以下のようにフィルタリングされ表示されます。
前に作成したポリシーを選択します。
“次のステップ：タグ”を選択します。
必要に応じて、タグを追加し、”次のステップ：確認”を選択します。
“ユーザーの作成”を選択します。
成功ページで、ユーザー認証情報を含む credentials.csv ファイルをダウンロードします。

ユーザーが作成されたので、Amazon Web ServicesアプリケーションをOktaに追加し、IAM IDプロバイダーをあわせて構築します。これは、それぞれがお互いの情報に依存するため必須になります。OktaのAmazon Web Services アプリから始めます。

Amazon Web ServicesアプリケーションをOktaに追加し、IDプロバイダーを作成するには :

Okta 管理者アカウントにログインします。
開発者ダッシュボードを使用している場合は、左上隅のドロップダウンから “Classic UI”を選択してClassic UI に切り替えます。
“Applications”を選択します。
“Add Application”を選択します。
検索バーに、”AWS Account Federation”と入力します。
“AWS Account Federation”アプリケーションの横にある”Add”を選択します。
“Application label”に、”Amazon Connect Administrator”と入力します。
“Your AWS Login URL”に、”https://console.thinkwithwp.com/”と入力します。
他のすべてのボックスはデフォルトのままにして、”Next”を選択します。
“Sign-On Options”ページの”Sign On Methods”セクションで、”SAML 2.0″を選択します。
“SAML 2.0″セクションの”Default Relay State” に、次のように URL を入力します。
https://[region-id].console.thinkwithwp.com/connect/federate/[instance-id]
[region-id]を、Amazon Connect インスタンスを作成したリージョン名に置き換えます(東京リージョンの場合はap-northeast-1 など）。
[instance-id]をインスタンスのインスタンス ID に置き換えます。
インスタンス ID を確認するには :
1. a. 新しいタブを開き、Amazon Connectコンソールに移動します。
2. b. インスタンスエイリアスを選択します。
3. c. インスタンス ID は、インスタンス ARN の最後の “/” の後の文字列全てです。
4. 例: arn:aws:connect:us-west-2:123456789:instance/00aa11b2-c333-4d55-e6f7-888g9999hh0
“Identity Provider metadata”を右クリックし、リンク先のファイルを”metadata.xml”としてコンピュータに保存します。
このタブを閉じないでください。すぐ後でセットアップを続行する必要があります。
新しいタブを開き、 IAM コンソールに移動します。
ナビゲーションペインで、”ID プロバイダー”を選択します。
“プロバイダの作成”を選択します。
“プロバイダーのタイプ”として、”SAML”を選択します。
“プロバイダ名”に、Okta_Connect_Adminと入力します。
“メタデータドキュメント”セクションで、ステップ12 で保存した “metadata.xml”ドキュメントを選択します。
“次のステップ”を選択します。
プロバイダー情報を検証し、”作成”を選択します。
作成が完了したら、”Okta_Connect_Admin”を選択して詳細を表示します。
“プロバイダARN”をコピーし、今後使用できるようにテキストファイルに貼り付けておきます。
IAM コンソールのナビゲーションペインで、”ロール”を選択します。
“ロールの作成”を選択します。
“SAML 2.0 フェデレーション”を選択します。
“SAMLプロバイダー”セクションで、”Okta_Connect_Admin”を選択します。
“プログラムによるアクセスとAWSマネジメントコンソールによるアクセスを許可する” を選択します。
“次のステップ：アクセス権限”を選択します。
“フィルタポリシー”に、”okta”と入力します。
前に作成した両方のポリシーを選択します。
“次のステップ：タグ”を選択します。
“次のステップ：確認”を選択します。
“ロール名”に”Okta_Role”と入力します。
“ロールの作成”を選択します。
Okta タブに戻ります。
“Advanced Sign-On Settings”セクションで、コピーしたIDプロバイダーARN を “Identity Provider ARN”フィールドに貼り付けます。
“Done”を選択します。

アプリケーションが作成されたので、次にAWSへのアクセスを許可します。これを行うには、先にダウンロードした認証情報ファイルが必要です。

Okta にプログラムによるアクセスを提供するには :

Okta 管理者アカウントにログインして”Applications”を選択します。
“Amazon Connect Administrator”を選択します。
“Provisioning”を選択します。
“Configure API Integration”を選択します。
“Enable API Integration”を選択します。
“Access Key”フィールドに、credentials.csv ファイルのアクセスキーを貼り付けます。
“Secret Key”フィールドに、credentials.csv ファイルからシークレットキーを貼り付けます。
“Test API Credentials”を選択します。
認証情報が正常に検証されたら、 “Save”を選択します。
“To App”を選択します。
“Edit”を選択します。
“Create Users”を有効にします。
Saveをクリックします。
ページが更新されたら、ページの下部までスクロールして”Amazon Connect Administrator Attribute Mappings”セクションまで移動します。属性のリストが表示されます。

Oktaにプログラムによるアクセスを提供すると、アプリケーションをユーザーに割り当てることができます。Okta 管理者でこれを実行します。

新しいアプリケーションを管理者ユーザーに割り当てるには :

OktaにAdministrator にログインして、”Directory”を選択します。
Amazon Connect インスタンスの構築時に設定した管理者ユーザーを選択します。
“Assign Applications”を選択します。
“Amazon Connect Administrator”の横にある、”Assign”を選択します。
“Role”ドロップダウンで、”Okta_Role”を選択します。
“SAML User Role”に、”Okta_Role”を選択します。
“Save and Go Back”を選択します。
“Done”を選択します。

アプリケーションをテストするには :

設定した Amazon Connect 管理者として Okta にログインします。
“Amazon Connect Administrator”を選択します。
新しいタブが開きます。認証を実行し、Amazon Connect にリダイレクトします。
これで、Amazon Connectに管理者としてログインできました。

Okta からの SAML 認証を使用して、Amazon Connectにログインする Amazon Connect管理者アプリができました。Amazon Connect Contact Control Panel(CCP)を起動する2つ目のアプリケーションを構築するには、Amazon Connectインスタンスの作成を除いた、上記の手順を繰り返し実行します。
要約すると、次のようになります。

1. Oktaで新しいアプリケーションを作成します。
2. IAMで新しいIDプロバイダーを作成します。
3. 新しいIDプロバイダーを使用する新しいIAM ロールを作成します。
4. 次の例の様に、CCP を指すRelay State URLに変更して、アプリケーションのセットアップを完了します。
  https://[region-id].console.thinkwithwp.com/connect/federate/[instance-id]?destination=%2Fconnect%2Fccp
  (訳注：新しいCCP version 2を利用される場合は、最後の”ccp”の部分を”ccp-v2”としてください)
5. アプリケーションのAPIアクセスを設定します。
6. プロビジョニングを有効にします。
7. アプリケーションをユーザーに割り当てます。
8. Amazon Connectでエージェントユーザーを作成します。

注意 : 大文字と小文字の区別を含め、入力したユーザー名が Okta のユーザー名と正確に一致することが重要です。

仕組みについて

Okta のようなフェデレーションアプリケーションを使用すると、ユーザーは適切な認証情報、アクセス権限、セキュリティコントロールを使用して Amazon Connect にアクセスしてログインできます。
SAML リクエストは、以下のステップで実行されます。

ユーザーはOktaアプリを起動するか、Oktaが生成するURLにアクセスします。
Oktaは、組織のID ストアから認証をリクエストします。
IDストアはユーザーを認証し、フェデレーションサービスに認証レスポンスを返します。
認証が成功すると、フェデレーションサービスはユーザーのブラウザに SAML アサーションをリターンします。
ユーザーのブラウザは、SAML アサーションを AWSサインインSAMLエンドポイント(https://signin.thinkwithwp.com/saml) にPOSTします。AWS Sign-inは SAML リクエストを受け取り、リクエストを処理し、ユーザーを認証して、認証トークンを Amazon Connect に転送します。
AWSからの認証トークンを使用して、Amazon Connectはユーザーを承認し、ブラウザはAmazon Connect にアクセスできます。

まとめ

本Blogでは、Oktaアプリケーションの作成と設定、AWS IDプロバイダーとAmazon Connectの設定についてご説明しました。これにより、社内のユーザーと管理者は、Oktaインターフェイスを介して、使い慣れた安全なプロセスを使用してAmazon Connect にログインできます。

Okta以外のSSO製品を使用している場合、同じプリンシパルとAWSの設定が利用できますが、SSOアプリケーションの設定はアプリケーションによって異なります。

Amazon Connectシングルサイン設定の詳細については、Amazon ConnectでIdentity Management用のSAMLを設定するを参照してください。Amazon Connectの詳細については、Amazon Connectのドキュメントを参照してください。

翻訳はソリューションアーキテクトの木村雅史が担当しました。原文はこちらです。

Amazon Web Services ブログ