CXoneにおける認証と認可

このページでは、CXoneにおける認証と認可の仕組みについて、具体的な情報を提供します。初めてこれらの概念を扱う場合は、まず認証と認可の考え方と用語の基本的な理解を得てください。

この資料を確認すると、以下の準備が整います。

ユーザーが、CXoneを含め、アプリケーションスイートにログインするときは、通常、次の2つのステップを順番に実行します。

認証 -ユーザーは本人か
認可 -認証されたユーザーが要求するアクセスは正当か

すべてのユーザーは、CXoneにアクセスする前に、認証され認可される必要があります。

ユーザーは人である場合もあれば、アプリケーションである場合もあります。たとえば、チャットボットやバーチャルアシスタントは、多くの場合、ユーザーアカウントによって実行されます。ほとんどのアプリケーションスイートは、人とバーチャルユーザーに対して同じプロセスを使用します。認証と認可に関するこのオンラインヘルプのページでは、ユーザーという用語を人とアプリケーションの両方に適用して使用しています。相違がある場合は、明確に説明しています。

認証は、設定が複雑で、テストや検証の難度が高い場合があります。CXoneで認証を設定するには、以下を理解する必要があります。

CXoneその場合、アクセスキーを作成する必要があります。の仕組み
ビルトインCXoneIDプロバイダー
外部IDプロバイダー
人間のユーザーとアプリケーションユーザーの認証の違い

また、CXoneプラットフォームでの認可の仕組みも知っておく必要があります。

この図は、CXoneがユーザーをどのように認証し認可するかを示しています。

ユーザーは、サポートされているウェブブラウザを使用してCXoneにアクセスします。
CXoneは、ユーザーのログイン資格情報を要求します。
ユーザーは資格情報を提供します。
CXoneは、IDプロバイダ(IdP)で資格情報を確認します。CXoneは、ビルトインIdPを備えていますが、外部IdPと連携することもできます。
ユーザーが認証されると、CXone認証サーバーはCXoneプラットフォームへのアクセスを提供します。CXoneは、外部の認可システムをサポートしません。

ビルトインIDプロバイダーを使用した認証の設定

ビルトインCXoneIdPは、ユーザー名とパスワードでユーザーを認証します。各ユーザー名は、お客様の組織で一意である必要があります。オプションで多要素認証(MFA)を追加して、セキュリティレイヤーを追加することができます。

アプリケーションユーザー

アプリケーションからCXone機能にアクセスする必要がある場合があります。CXoneは、ボットや対話型仮想アシスタント(IVA)のようなこれらのアプリケーションを、ユーザーとして扱います。アプリケーションユーザーは、ビルトイン認証でのみサポートされています。また、アプリケーションユーザーは、ログイン認証コードを使用しません。代わりに、アクセスキーを使用します。

ビルトイン認証によるユーザーログイン

ユーザーにはまず、ユーザー名を尋ねる画面が表示されます。CXoneがユーザー名を取得するまでは、追加の資格情報を要求することはありません。CXoneがパスワードやMFAトークンを要求するのは、ログインするユーザーが分かってからです。

ユーザーがユーザー名を入力し、次へをクリックすると、新しいウィンドウでパスワードの入力が要求されます。ユーザーが正しいパスワードを入力してサインインをクリックすると、CXoneはユーザーを認証し、システムへのアクセスを許可します。

このウィンドウは、MFAを使用するように構成されているの従業員の場合、若干異なって表示されます。ユーザーがユーザー名を入力し、次へをクリックすると、新しいウィンドウでパスワードとMFAトークンの入力が要求されます。ユーザーが正しいパスワードと有効なトークンを入力したら、サインインをクリックします。場所に基づいてログイン要件を設定した場合、CXoneは、ユーザーのIPアドレスが許可されたIPアドレスに一致するかどうかを確認します。CXoneはユーザーを認証し、システムへのアクセスを許可します。

ビルトイン認証でのパスワード管理

パスワードの基準は、ログイン認証でカスタマイズすることができます。ログイン認証コードを使用すると、以下の制御が可能です。

パスワードに必要な文字数
パスワードに必要な文字の種類
ユーザーがパスワードの変更を求められるまでの日数
アカウントがロックされるまでに許可されるパスワードの試行回数
ユーザーがパスワードを再利用できない、CXoneが記憶するパスワードの数

パスワードはCXoneで見ることはできません。プライバシーとセキュリティのため、パスワードは内部で管理され、パスワード忘れのフロー、またはパスワード再送信のフローを使用してのみ変更することができます。パスワードログイン画面に表示されるリンクを使用し、画面上の指示に従ってください。パスワードが変更された場合は、ユーザーにその旨を知らせるメールが届きます。

CXoneには、カスタムログイン認証コードが不要な場合に使用できるデフォルトのログイン認証コードが付属しています。ただし、このデフォルトの認証機能は、使用するのロールに割り当てる必要があります。

カスタムログイン認証コードは、必要な数だけ設定できます。たとえば、重要な情報にアクセスするユーザーには、より複雑なパスワードを要求することができます。ユーザーアカウントに対して異なる認証要件を設定したい場合は、新しいログイン認証コードを作成する必要があります。認証機能の変更は、割り当てられたユーザーが次にログインしたときに適用されます。

また、カスタムログイン認証機能を使用して、多要素認証(MFA)を設定することができます。MFAは、認証のレイヤーをもう1つ追加することで、セキュリティを向上させます。たとえば、ユーザーにユーザー名とパスワードで認証してもらうとします。次に、ユーザーのモバイルデバイスに送信されるコードで再度認証を行うことができます。このようなコードは、物理的なトークンを使用しない場合でも、一般的にMFAトークンと呼ばれます。

CXoneは、以下の二つの主要なタイプのMFAをサポートしています。

タイムベース-通常、Googleのようなソフトウェア認証システムで使用されます。
カウンターベース-通常、ハードウェアトークンで使用されます。

ログイン認証コードのMFAは、1つのチェックボックスで有効にすることができます。しかし、ユーザーに関する特定の情報、MFA設定、ID情報は、個々の従業員アカウントで管理されます。

ログイン認証コードは、ロールに割り当てられます。つまり、従業員の認証方法は、割り当てられたロールに依存します。

外部IDプロバイダーを使用する認証

他のサイトのアカウントでシステムにサインインする場合、外部認証を使用することになります。たとえば、携帯電話のアプリにGoogleアカウントでログインするような場合です。

外部認証は、フェデレーションと呼ばれることもあり、外部IDプロバイダー(IdP)を使用して、ユーザーの認証を支援します。外部IdPは、CXoneIdPと連動してユーザーを認証します。連携するために、両方のIdPは、認証プロトコルに依存します。

外部IdP

CXoneは、ホスト型とクラウドサービスの両方のIDプロバイダーをサポートしています。

IDプロバイダーについては、ご存知でしょう。そうでない場合は、社内で認証を管理しているチームと連携してください。フェデレーションの設定は、適切な担当者が関与しないと難しい場合があります。組織によっては、IDプロバイダと共にCXoneなどのシステムを統合するためのプロセスを確立している場合があります。それらのプロセスに従い、お客様固有のセキュリティニーズを満たすことはお客様の責任となります。その面でも、NICE CXoneチームはお客様をサポートします。

認証プロトコル

IdP主導のフローは、CXoneスイート全体ではなく、単一のアプリケーションに適用されます。たとえば、このフローを使って、メインのユーザーインターフェイスのアプリケーションを起動することはできますが、Studioのような他のアプリケーションを起動することはできません。スイート全体をシームレスに機能させるためには、SP主導のフローが必要です。

認証プロトコルは、異なるIdP間の通信と信頼を確立します。CXoneは、SAML 2.0と呼ばれる認証プロトコルをサポートしています。

SAML 2.0は確立された技術であり、OpenID Connectのような新しい技術よりも広く使用されています。またサービスプロバイダー(SP)主導の認証フローをサポートします。これはよく知られたフローであり、多くのアプリやウェブサイトで使用されているモデルです。ユーザーエクスペリエンスは以下となります。

ユーザーはCXoneに自分の資格情報を入力します(つまり、ログインします)。
CXoneは、ビルトインIdPを使用して外部のIdPと通信し、ユーザーIDを検証します。
CXoneは、認証されたユーザーのアクセスレベルを確認するために、ビルトイン認可を使用します。
CXoneは、認証され、認可されたユーザーに適切なアクセスを提供します。

SAML 2.0は、あまり一般的でないIDプロバイダー(IdP)主導のフローもサポートしています。このフローでは、ユーザーがIDプロバイダーに自分の資格情報を入力します。その後、IdPはCXoneを起動します。

SAML 2.0で、CXoneはメッセージ/応答の署名のみがサポートされ、アサーションはサポートされません。

ユーザーは、これらの認証フローのいずれか、または両方を使い慣れているかもしれません。SAML 2.0を使用する場合、各フローが持つ制限に注意してください。この点については、次のセクションで詳しく説明します。

CXoneは、一部の認証プロトコルが提供する追加の暗号化をサポートしません。

組み合わせを評価する

CXoneスイートは、アプリケーション、外部IdP、認証プロトコルの全ての組み合わせをサポートしているわけではありません。ケースによってはサポートされていない場合があります。また、制限があり、回避策が必要な場合もあります。全ての組み合わせとシナリオについての起こり得る問題を示すことは難しいので、IDプロバイダと共にテスト設定を行う必要があります。テストでは、さまざまなユースケースとユーザーフローを考慮する必要があります。次の表は、評価の指針として役立ちます。

CXoneアプリケーション	外部IDP	認証プロトコル	制限と回避策
CXoneプラットフォームと全てのアプリケーション	すべて	すべて	クレームの暗号化には対応していません。
CXoneプラットフォームと全てのアプリケーション	すべて	SAML 2.0	メッセージの署名のみをサポートします。パブリック証明書をレスポンスに含める必要があります。
CXoneプラットホーム	すべて	OpenID Connect	サポートされていません

IdP主導のSAML 2.0フローをサポートするのは、主要なWebアプリケーションのみです。Studioまたはさまざまなエージェントアプリケーションにアクセスする必要があるユーザーは、内蔵の認証またはSP主導のフローを使用する必要があります。

信頼関係の確立

IDプロバイダーは、通信を行う前に互いを信頼する必要があります。各プロバイダーは、相手に関する情報を持っている必要があります。どのような情報が必要かは、認証プロトコルに依存します。情報をどのように取得するかは、IdPに依存します。

SAML 2.0との信頼関係を確立するために使用される構成パラメーターがいくつかあります。CXoneアカウント担当者と協力してこれらのパラメーターを使用し、CXone テナント CXone環境におけるテクニカルサポート、請求、およびグローバル設定を管理するために使用される上位レベルの組織グループと外部IdPの間に信頼関係を作成します。

フィールド	詳細
エンティティID	SAML 2.0プロトコルを使用する際に、外部IdP側で入力するよう外部IdPより求められる可能性がある、事前入力された編集不可のグローバルな一意のID。IdPは、それを発行者のエンティティIDとしてSAML 2.0リクエストメッセージに含めます。OktaやOneLoginなど、一部のIdPでは、エンティティIDを設定する必要はありません。Salesforceを含む他のユーザーが行います。
エンドポイントURL	IdPによって提供されるエンドポイントURL。
アサーションURL	IdPがSAML 2.0フローを設定するために必要な、事前入力された編集不可のURL。これは、認証アサーションを受信して解析するためのエンドポイントURLとして機能します。このIDをIdP構成に入力する必要があります。通常は、ACSのURLフィールドに入力します。一部のIdPはそれをACS以外の名前で呼んでいます。たとえば、Okta SAML 2.0テンプレートでは、このURLをシングルサインオンURLフィールドに入力します。
証明書	IdPはセキュリティ証明書を提供します。

アプリケーションの認証

ユーザーとアプリケーションは、非常によく似た方法で認証されます。主な違いは、アプリケーションはアクセスキーで認証されるのに対し、ユーザーはユーザー名とパスワードで認証されることです。ユーザーと違って、アプリケーションはブラウザーを通してやりとりする必要はありません。アプリケーションは、バックオフィス環境で機能します。

と従業員プロファイルを作成して、ユーザーの代わりにアプリケーションを動作させることができます。そのためには、と従業員プロファイルを作成し、プロファイルにアプリケーションの名前を付け、アクセスキーを作成します。CXoneは、アプリケーションの認証を内部的に管理します。アプリケーションは、外部のIDプロバイダーで認証されることはありません。

CXoneでの認可

認可は、ユーザーがどのリソースへのアクセスを許可されているかを確認するプロセスです。リソースには、アプリケーション、ファイル、データが含まれます。ユーザーのリソースへのアクセスは、のロールで定義できます。CXoneは、ログインプロセス中に認可を自動的に管理します。ユーザーが認証されると、認可されたリソースへのアクセスのみが許可されます。

ユーザーの認証方法は、認可に影響を与えません。CXoneは、全てのユーザーに対して同じ認可プロセスを使用します。アクセスキーで認証されるか、パスワードで認証されるかは問題ではありません。