CXone 中的驗證和授權

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

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

• 使用內建身分識別提供者設定 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 會驗證該使用者的身分並授予他們存取系統的權限。

此視窗對於被配置使用 MFA 的員工略有不同。 使用者輸入使用者名稱並點擊下一步後，會顯示要求使用者輸入密碼和 MFA 權標的視窗。 使用者輸入正確的密碼和有效的權標後，點擊登入。 如果您設定了基於位置的登入要求，CXone會檢查使用者的 IP 位址，以確保其與允許的 IP 位址相符。 CXone 會驗證該使用者的身分，並授予他們存取系統的權限。

透過內建驗證管理密碼

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

• 密碼的必要字元數目

• 密碼的必要字元類型

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

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

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

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

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

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

CXone 主要支援兩種 MFA：

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

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

登入驗證器將指派給角色。 這意味著員工的驗證方式取決於為其指派的角色。

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

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

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

外部 IdP

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

您應該熟悉所使用的身分識別提供者。 如果還不熟悉，請與管理驗證的公司團隊合作。 如果沒有合適的人員，設定聯合身分可能會比較困難。 貴組織可能已建立用於整合 CXone 等系統與身分識別提供者的流程。 您有責任按照這些流程操作並滿足您的特定安全性需求。 NICE CXone 團隊將全程為您提供支援。

驗證通訊協定

驗證通訊協定用於在不同 IdP 之間建立通訊和信任。 CXone 支援被稱為 SAML 2.0 的驗證通訊協定。

SAML 2.0 是一種比較成熟的技術，比 OpenID Connect 等新技術使用得更廣泛。 其支援由服務提供者 (SP) 發起的驗證流程。 這是很多應用程式和網站都使用的流程和模型。 其使用者體驗為：

• 使用者在 CXone 中輸入認證資訊（即使用者登入）。
• CXone 利用內建的 IdP 與外部 IdP 通訊，以驗證其使用者身分。
• CXone 利用內建的授權機制驗證已通過身分驗證之使用者的存取級別。
• CXone 為通過身分驗證且已取得授權的使用者提供相應的存取權限。

SAML 2.0 還支援由不常見的 IdP 發起的流程。 在此流程中，使用者輸入 IdP 的認證資訊。 然後，IdP 會啟動 CXone。

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

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

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

評估組合

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

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

建立信任

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

有幾個配置參數可用於與 SAML 2.0 建立信任。 與您的CXone 客戶代表配合，使用這些參數在您的CXone租戶 用於管理 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 對所有使用者使用相同的授權流程。 無論是使用存取金鑰還是密碼驗證都沒關係。