CXone Mpowerにおける認証と認可

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

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

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

認証-ユーザーは本人ですか?
承認 - 認証されたユーザーは、要求したアクセス権を持つ必要がありますか?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このウィンドウは、MFAを使用するように構成されているユーザーのの場合、若干異なって表示されます。ユーザーがユーザー名を入力し、次へをクリックすると、新しいウィンドウでパスワードとMFAトークンの入力が要求されます。ユーザーが正しいパスワードと有効なトークンを入力したら、サインインをクリックします。 CXone Mpowerはユーザーを認証し、システムへのアクセスを許可します。

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

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

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

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

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

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

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

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

時間ベース通常、Googleなどのソフトウェア認証コードで使用されます
カウンターベース通常、ハードウェアトークンによって使用されます

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

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

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

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

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

外部IdP

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

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

認証プロトコル

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

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

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

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

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

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

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

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

組み合わせを評価する

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

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

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

信頼関係の確立

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

OpenID Connectの信頼

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

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

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

SAML 2.0の信頼

SAML 2.0との信頼関係を確立するために使用される構成パラメーターがいくつかあります。アカウント担当者と協力してこれらのパラメーターを使用し、CXone Mpower ビジネスユニット CXone Mpowerシステムにおけるテクニカルサポート、請求、およびグローバル設定を管理するために使用される上位レベルの組織グループ。と外部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 Mpowerは、アプリケーションの認証を内部的に管理します。アプリケーションは、外部のIDプロバイダーで認証されることはありません。

CXone Mpowerでの認可

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

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