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はユーザーを認証し、システムへのアクセスを許可します。

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

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

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

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

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

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

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

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

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

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

ログイン認証コードとセキュリティプロファイルは完全に分離されています。つまり、従業員の認証方法は、その従業員がCXoneでアクセスできる内容とは関係がありません。

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

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

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

外部IdP

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

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

認証プロトコル

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

OpenID Connect
SAML 2.0

OpenID Connectはより多くの機能を持っており、サポートが容易です。以下のメリットがあります。

業界標準の技術
ユーザーに対して透過的でシームレスなIdP統合が可能
さまざまな多要素認証（MFA）オプションが利用可能
プラットフォームサービスモデルのためのスケーラブルな基盤

OpenID Connectは、JWKSと呼ばれる業界標準を使用したパブリック/プライベート証明書署名で認証を検証します。そのため、パブリック証明書の取得方法はOpenID Connect設定により決定されます。証明書発行者との信頼関係は、クライアント識別子とシークレットを使用して確立されます。

SAML 2.0は、統合に関する問題が発生し得る古いテクノロジーです。しかし、現在、OpenID Connectよりも広く使われています。お客様の組織には、どちらのプロトコルを使用すべきかのガイドラインがあるかもしれません。一般に、両方とも同様のユーザーエクスペリエンスと基本的なレベルのセキュリティを提供します。

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

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

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

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

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

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

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

設定の詳細は、選択するIdPと認証プロトコルによって異なります。 IdPと認証プロトコルの全ての組み合わせを網羅することはできませんが、いくつかの一般的なシナリオについては、この後の情報で説明します。

組み合わせを評価する

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

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

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

信頼関係の確立

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

OpenID Connectの信頼

あなたのCXoneアカウント担当者はあなたと協力して、あなたのCXoneビジネスユニット CXone環境におけるテクニカルサポート、請求、およびグローバル設定を管理するために使用される上位レベルの組織グループとあなたの外部IdPの間の信頼関係をOpenID Connectを使用して設定します。

OpenID Connectの信頼にはこれらの値が含まれ、信頼関係を構成するために必要となります。

発行者 －発行者の値は外部IdPによって異なりますが、常にURLのように見えます。たとえば、Googleは外部IdPとして機能することができ、OpenID Connectをサポートしています。 Googleの発行者はhttps://accounts.google.comです。多くの外部IdPプロバイダーは、IdPの主要URLの末尾に「.well-known/openid-configuration」を追加して公開しており、発行者URLを発見しやすくしています。これにより、多くの場合、IdPからさらに重要な情報を得ることができます。次の画像は、Facebookが以下において、上記の方法で提供する情報の種類を示します。https://www.facebook.com/.well-known/openid-configuration:
クライアント識別子—この値は、外部IdPによって割り当てられ、CXoneで使用できます。認証時に、どのアプリケーションが認証を行おうとしているのかをIdPに知らせます。
クライアントシークレット-この値は、認証が安全であることを保証し、悪意のあるアクターが外部IdPを使用してCXone ビジネスユニットに認証できないようにするのに役立ちます。 CXoneは、client_secret_basicおよびclient_secret_postのみをサポートしています。

SAML 2.0の信頼

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は、全てのユーザーに対して同じ認可プロセスを使用します。アクセスキーで認証されるか、パスワードで認証されるかは問題ではありません。