CXone 中的驗證和授權

該頁面詳細介紹了 CXone 中的驗證和授權機制如何運作。如果這是您首次接觸這些概念，您應該先大致了解驗證和授權的概念的術語。

查閱這些資料後，您即可：

當使用者登入任何應用程式套件（包括 CXone）時，一般會按順序顯示以下兩個步驟：

  • 驗證 — 使用者身分是否屬實？
  • 授權 — 通過驗證的使用者是否應擁有所請求的存取權限？

所有使用者必須通過驗證並取得授權，然後才能存取 CXone。

使用者可以是人員或應用程式。例如，聊天機器人和虛擬助理通常由使用者帳戶執行。大部分應用程式套件都對真人和虛擬使用者使用相同的流程。在關於驗證和授權的線上說明頁面中，我們將人員和應用程式統一稱作使用者。若有差異，會有明確說明。

身分驗證的設定可能比較複雜，而且比較難測試和驗證。為了在 CXone 中設定驗證，您需要了解：

  • CXone 中驗證機制的運作方式

  • 內建的 CXone 身分識別提供者

  • 外部身分識別提供者

  • 驗證真人使用者和應用程式使用者的區別

您還需要 CXone 平台中授權機制的運作方式。

下圖顯示了 CXone 如何驗證使用者身分並授權：

  1. 使用者透過受支援的網頁瀏覽器存取 CXone。

  2. CXone 要求使用者輸入登入認證。

  3. 使用者輸入認證。

  4. CXone 透過身分識別提供者 (IdP) 驗證使用者。CXone 自帶內建的 IdP，但也可以使用外部 IdP。

  5. 使用者通過身分驗證後，CXone 授權伺服器會提供存取 CXone 平台的權限。CXone 不支援外部授權系統。

使用內建身分識別提供者驗證

內建的 CXone IdP 透過使用者名稱和密碼驗證使用者的身分。每個使用者名稱在組織中皆具唯一性。您可以選擇增加多重要素驗證 (MFA)，以提升安全性。

應用程式使用者

有時候，應用程式也需要存取 CXone 功能。CXone 將這些應用程式也視作使用者，例如機器人和互動式虛擬助理 (IVA)。應用程式使用者僅支援內建驗證。此外，應用程式使用者亦不使用登入驗證器，而是使用存取金鑰。

使用者透過內建驗證登入

使用者首先會看到要求其輸入使用者名稱的畫面。在 CXone 知道使用者名稱之後，才能要求提供其他認證資訊。CXone 在知道是哪個使用者登入後，僅會要求輸入密碼或 MFA 權標。

CXone 初始登入畫面，使用者在其中輸入使用者名稱

使用者輸入使用者名稱並點擊下一步後，會顯示要求使用者輸入密碼的新視窗。使用者輸入正確的密碼並點擊登入後，CXone 會驗證該使用者的身分並授予他們存取系統的權限。

CXone 二次登入畫面，使用者在其中輸入密碼

此視窗對於被配置使用 MFA 的使用者略有不同。使用者輸入使用者名稱並點擊下一步後，會顯示要求使用者輸入密碼和 MFA 權標的視窗。使用者輸入正確的密碼和有效的權標後，點擊登入。CXone 會驗證該使用者的身分，並授予他們存取系統的權限。

CXone 中的員工密碼輸入畫面，顯示 MFA 特定欄位

透過內建驗證管理密碼

可以使用登入驗證器自訂密碼條件。透過登入驗證器，您可以控制：

  • 密碼的必要字元數目

  • 密碼的必要字元類型

  • 使用者必須在多少天後重設密碼

  • 鎖定帳戶之前允許輸錯密碼的次數

  • CXone 記住的密碼數目，可防止使用者重複使用這些密碼

密碼在 CXone 中不會顯示。出於隱私和安全性考量，密碼將保留在內部，僅可使用忘記密碼或重設密碼流程進行變更。使用者可使用密碼登入畫面上連結並按照畫面上的說明操作。如果使用者的密碼已變更，使用者將收到一封電子郵件通知。

CXone 自帶預設登入驗證器，無需自訂登入驗證器時可以使用。但您仍必須將此預設驗證器指派給您希望其使用該驗證器的使用者。

您可以根據需要，設定多個自訂登入驗證器。例如，您可能要求有權存取重要資訊的使用者設定更複雜的密碼。每次為使用者帳戶設定不同的驗證要求時，都需要建立新的登入驗證器。對驗證器的變更將在已指派的使用者下次登入時套用。

您可以使用自訂的登入驗證器設定多重要素驗證 (MFA)。MFA 會增加額外的驗證層，從而提升安全性。例如，您可以要求使用者透過使用者名稱和密碼驗證。然後，您可以要求使用者再透過傳送至其行動裝置的驗證碼進行驗證。這些驗證碼一般稱為 MFA 權標，雖然並不涉及實體權標。

CXone 主要支援兩種 MFA：

  • 基於時間 — 一般由軟體驗證器使用，如 Google
  • 基於計數器 — 一般由硬體權標使用

使用單一剔選框即可為多個登入驗證器啟用 MFA。但是，使用者的特定資訊、其 MFA 設定及其身分都將保留在各員工的帳戶中。

登入驗證器和安全性設定檔完全獨立。這意味著使用者的驗證方式與他們可在 CXone 中存取的內容無關。

CXone 中的員工記錄，顯示「清除 MFA 密碼」按鈕

使用外部身分識別提供者驗證

使用帳戶從其他站點登入系統時，您將使用外部驗證。例如，您可能會在手機上使用 Google 帳戶登入應用程式。

外部驗證（有時也成為聯合身分）使用外部身分識別提供者 (IdP) 來幫助驗證使用者。外部 IdP 與 CXoneIdP 一起工作來驗證使用者。若要使兩者相結合，兩種 IdP 將依賴驗證通訊協定。

外部 IdP

CXone 支援託管式和雲端服務身分識別提供者。

您應該熟悉所使用的身分識別提供者。如果還不熟悉，請與管理驗證的公司團隊合作。如果沒有合適的人員，設定聯合身分可能會比較困難。貴組織可能已建立用於整合 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 通訊，以驗證其使用者身分。
  • CXone 利用內建的授權機制驗證已通過身分驗證之使用者的存取級別。
  • CXone 為通過身分驗證且已取得授權的使用者提供相應的存取權限。

SAML 2.0 還支援由不常見的身分識別提供者 (IdP) 發起的流程。在此流程中，使用者輸入身分識別提供者的認證資訊。然後，身分識別提供者啟動 CXone。

對於 SAML 2.0，CXone 僅支援對訊息/回覆進行簽名，而不是判斷提示進行簽名。

由 IdP 發起的流程適用於單個應用程式，而不是整個 CXone 套件。例如，您可以使用該流程啟動主要的使用者介面應用程式，但您不能使用該流程啟動其他應用程式，比如 Studio。為了使整個套件順暢運作，需要由 IdP 發起的流程。

您的使用者可能比較熟悉這兩種驗證流程中的一種或兩種。如果您使用 SAML 2.0，需要了解每種流程的限制。這些限制將在下一部分詳細討論。OpenID Connect 一律使用由 SP 啟動的流程。

CXone 不支援某些驗證通訊協定額外提供的加密功能。

詳細配置因您選擇的 IdP 和驗證通訊協定而異。雖然無法涵蓋所有可能的 IdP 和驗證通訊協定組合，但下列資訊討論了一些常見場景。

評估組合

CXone 套件並不支援應用程式、外部 IdP 和驗證通訊協定的每一種組合。在某些情況下，可能會不支援。在其他情況下，會有因應措施方面的限制。由於很難顯示每種組合和場景的潛在問題，因此您應該測試身分識別提供者的設定。測試時應考慮不同的用例和使用者流程。下表可幫助引導您完成評估。

CXone 應用程式 外部 IdP 驗證通訊協定 限制和因應措施
CXone 平台和所有應用程式 全部 全部 不支援申索加密。
CXone 平台和所有應用程式 全部 SAML 2.0 僅支援訊息簽署。必須在回應中包含公用憑證。
CXone 平台 Azure AD SAML 2.0 僅支援由 IdP 發起的流程。

僅主要的 Web 應用程式支援由 IdP 發起的 SAML 2.0 流程。需要存取 Studio 或各種客服專員應用程式的使用者必須使用內建驗證或由 IdP 發起的流程。

建立信任

身分識別提供者必須相互信任才能通訊。每個提供者都必須擁有對方的資訊。所需的資訊取決於驗證通訊協定。資訊獲取方式取決於 IdP。

OpenID Connect 中的信任

您的CXone 客戶代表將與您配合，使用OpenID Connect的外部 IdP 和您的CXone 業務單位Closed 用於管理 CXone 環境的技術支援、計費和全域設定的高級組織分組之間配置一個可信的關係。

OpenID Connect 中的信任包含這些值，您需要這些值來配置信任關係：

  • 簽發者 — 此值與 URL 相似。簽發者值將依外部 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:

    從 Facebook 外部身分識別提供者的發現 URL 傳回的資訊類型範例。其中包括簽發者、端點和受支援的回應類型和申索等。

  • 使用者端識別碼—該值由您的外部 IdP 指派，供您使用 CXone。在驗證期間，此識別碼可讓 IdP 知道哪個應用程式正在嘗試驗證。
  • 用戶端密碼—這個值確保認證是安全的，有助於確保惡意行為者不能使用外部 IdP 來認證您的CXone業務單位。CXone 僅支援 client_secret_basic 和 client_secret_post。

SAML 2.0 中的信任

有幾個配置參數可用於與 SAML 2.0 建立信任。與您的CXone 客戶代表配合，使用這些參數在您的CXone業務單位Closed 用於管理 CXone 環境的技術支援、計費和全域設定的高級組織分組和您的外部 IdP 之間建立一個信任關係。

欄位

詳細資訊
實體 ID

當使用 SAML 2.0 通訊協定時，您的外部 IdP 可能要求您輸入的預先填入、不可編輯的全域唯一 ID。IdP 將其包含在 SAML 2.0 請求訊息中作為簽發者的實體 ID。某些 IdP（包括 Okta 和 OneLogin）不要求您在其一側設定實體 ID。包括 Salesforce 在內的其他公司也是如此。

端點 URL

您的 IdP 提供的端點 URL。
斷言 URL

IdP 設定任何 SAML 2.0 流程所需的預先填入、不可編輯的 URL。它用作接收和解析驗證斷言的端點 URL。您必須在 IdP 配置中輸入此 ID，通常在 ACS URL 欄位中。一些 IdP 稱其為 ACS 以外的其他名稱。例如，在 Okta SAML 2.0 範本中，您在單一登入 URL 欄位中輸入此 URL。
憑證 您的 IdP 將為您提供安全性憑證。

應用程式的驗證

使用者和應用程式的驗證方式非常相似。主要的區別是，應用程式使用存取金鑰進行驗證，而使用者則使用使用者名稱和密碼進行驗證。與使用者不同，應用程式無需透過瀏覽器進行互動。可以在後台環境中運作。

您可以建立使用者設定檔來代表應用程式，以代替使用者。為此，需建立使用者設定檔，根據應用程式進行命名，然後建立存取金鑰。CXone 會在內部管理應用程式的驗證。應用程式無法透過外部身分識別提供者驗證。

CXone 中的授權

授權是指確認允許使用者存取哪些資源的過程。資源可能包括應用程式、檔案和資料。您可以利用安全性設定檔來存取資源。CXone 會在登入過程中自動管理授權。如果使用者通過驗證，將僅為他們授予其被授權使用之資源的存取權限。

使用者的驗證方法不影響授權。CXone 對所有使用者使用相同的授權流程。無論是使用存取金鑰還是密碼驗證都沒關係。