CXone 中的身份验证和授权

此页面详细介绍了 CXone 中身份验证和授权的工作原理。如果您是第一次接触这些理念，您应当先基本了解身份验证和授权的概念和术语。

读完这些材料后，您就能够：

当用户登录到任何应用程序套件（包括 CXone）时，这两个步骤通常按如下顺序进行：

  • 身份验证 — 用户是否为他们声称的那个人？
  • 授权 — 经过身份验证的用户是否应拥有他们请求的访问权限？

所有用户必须通过身份验证和授权才能访问 CXone。

用户可以是人，也可以是应用程序。例如，聊天机器人和虚拟助手通常由用户帐户运行。大多数应用程序套件对真人和虚拟用户使用相同的流程。在这些关于身份验证和授权的在线帮助页面中，我们将术语用户同时应用于真人和应用程序。如果存在差异，我们会给出清晰的解释。

身份验证设置复杂，难以测试和验证。如要在 CXone 中设置身份验证，您需要了解：

  • 身份验证在 CXone 中的工作原理

  • 内置 CXone 身份提供程序

  • 外部身份提供程序

  • 人类用户和应用程序用户身份验证的区别

您也需要里了解授权在 CXone 平台上的工作原理。

下图展示了 CXone 如何对用户进行身份验证和授权：

  1. 用户通过受支持的 web 浏览器访问 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 会验证用户的身份并向其授予访问系统的权限。

为 MFA 特定字段时 CXone 中的员工密码输入屏幕

使用内置身份验证的密码管理

密码准则可以使用登录身份验证程序自定义。借助登录身份验证程序，您可以控制：

  • 密码所需的字符数量

  • 密码所需的字符类型

  • 用户必须重置密码前的天数

  • 锁定帐户前允许的错误密码尝试次数

  • CXone 记住的密码数量，以阻止用户重复使用这些密码

CXone 中不显示密码。为了隐私和安全，密码在内部维护，只能通过“忘记密码”或“重发密码”流程来更改。用户可使用密码登录屏幕上的链接并按照屏幕上的指示操作。如果密码已更改，用户将收到一封通知电子邮件。

如果您不需要自定义登录身份验证程序，CXone 附带您可以使用的默认登录身份验证程序。您仍必须将此默认身份验证程序分配给您想使用的用户。

您可以设置任意数量的自定义登录身份验证程序。例如，对于能够访问有价值的信息的用户，您可能需要更复杂的密码。任何时候您想对用户帐户设置不同的身份验证要求时，您都需要创建一个新的登录身份验证程序。所分配用户下一次登录时，对身份验证程序的更改将应用于这些用户。

您也可以通过自定义登录身份验证程序来设置多因素身份验证 (MFA)。MFA 添加了另一层身份验证，提高了您的安全性。例如，您可让用户使用用户名和密码进行身份验证。然后，您可以让他们使用发送至其移动设备上的代码来再次进行身份验证。这些代码通常称为 MFA 令牌，即使不涉及物理令牌。

CXone 支持以下两种主要的 MFA 类型：

  • 基于时间 — 通常用于软件身份验证程序（如 Google）
  • 基于计数器 — 通常用于硬件令牌

您可以通过一个复选框为登录身份验证程序启用 MFA。但是，有关用户的特定信息、其 MFA 设置及其身份均在个人员工帐户内维护。

登录身份验证程序和安全配置文件是完全分开的。这意味着员工的身份验证方法与其在 CXone 中可以访问的内容无关。

CXone 中的员工记录，显示“清除 MFA 密钥”按钮

使用外部身份提供程序的身份验证

使用某个帐户从另一个站点登录系统时，您使用的是外部身份验证。例如，您可能通过您的 Google 帐户在手机上登录一个应用程序。

外部身份验证（有时称为联合身份验证）使用外部身份提供程序 (IdP) 来协助验证用户的身份。外部 IdP 与 CXone IdP 一起对用户进行身份验证。要配合完成工作，两个 IdP 均要依赖于身份验证协议。

外部 IdP

CXone 既支持托管的身份提供程序，也支持云服务身份提供程序。

您应当非常熟悉自己的身份提供程序。如果不熟悉，请与负责管理身份验证的公司团队合作。如果没有合适的人员参与，很难设置联合身份验证。您的组织也许已经制定了将 CXone 此类系统与您的身份提供程序集成的流程。您的责任是遵循这些流程，满足您特定的安全需求。NICE CXone 团队会一直为您提供支持。

身份验证协议

身份验证协议用于在不同 IdP 之间建立通信和信任。CXone 支持以下身份验证协议：

  • OpenID 连接
  • SAML 2.0

OpenID 连接 具有更多功能并且更易于提供支持。其优点包括：

  • 行业标准技术

  • 可实现对用户透明的无缝 IdP 集成。

  • 可启用一系列多因素身份验证 (MFA) 选项

  • 平台服务模型的可扩展基础

OpenID 连接 使用名为 JWKS 的行业标准通过公共/私有证书签名来验证用户身份。因此，OpenID 连接 配置决定了获得这些公共证书的方式。使用一个客户端标识符和密钥即可建立对证书签发方的信任。

SAML 2.0 是一种较旧的技术，可能会导致集成问题。但是，当前它的应用范围比 OpenID 连接 更广。对于应该采用哪种协议，您的组织可能制定了指南。通常，它们都提供类似的用户体验和基础安全级别。

OpenID 连接 和 SAML 2.0 均支持服务提供商 (SP) 启动的身份验证流程。这是我们熟悉的流程和模式，许多应用程序和网站都在使用。用户体验如下：

  • 用户在 CXone 中输入其凭据（也就是登录）。
  • CXone 使用内置 IdP 与外部 IdP 通信，以验证用户身份。
  • CXone 使用内置身份验证程序来验证已经过身份验证的用户的访问级别。
  • CXone 为已完成身份验证的获授权用户提供正确的访问权限。

SAML 2.0 也支持身份提供程序 (IdP) 启动的流程，这种流程不太常见。在这种流程中，您的用户通过身份提供程序来输入其凭据。然后，身份提供程序启动 CXone。

对于 SAML 2.0，CXone 仅支持对消息/响应进行签名，而不支持对断言进行签名。

IdP 发起的流适用于单个应用程序，而不适用于整个 CXone 套件。例如，您可以使用此流来启动主用户界面应用程序，但不能使用它来启动其他应用程序，例如 Studio。为了使整个套件无缝运行，需要 SP 发起的流。

您的用户可能熟悉这两种身份验证流程，也可能只熟悉一种。如果您使用 SAML 2.0，请注意每种流程所存在的局限性。这些内容将在下一部分详细讨论。OpenID 连接 一直使用 SP 启动的流程。

CXone 不支持某些身份验证协议提供的额外加密。

配置细节根据您选择的 IdP 和身份验证协议而异。这里无法列举 IdP 和身份验证协议的所有可能的组合，但是下面的信息讨论了一些常见的场景。

评估组合

CXone 套件不支持应用程序、外部 IdP 和身份验证协议的任何组合。有些情况下，支持并不存在。其他情况下，相应的解决办法也存在局限性。很难显示每个组合和场景的潜在问题，所以您应该使用您的身份提供程序进行测试设置。测试应考虑到不同用例和用户流程。下表可帮助指导您的评估。

CXone 应用程序 外部 IDP 身份验证协议 局限性和解决办法
CXone 平台和所有应用程序 All All 不支持对索赔加密。
CXone 平台和所有应用程序 All SAML 2.0 仅支持消息签名。响应中必须包含公共证书。
CXone 平台 Azure AD SAML 2.0 仅支持 IdP 启动的流程。

只有主 Web 应用程序支持 IdP 发起的 SAML 2.0 流。需要访问 Studio 或各种坐席应用程序的用户必须使用内置身份验证或 SP 发起的流。

建立信任

身份提供程序在进行通信之前必须相互信任。每个提供程序都必须拥有关于另一个提供程序的信息。所需的信息取决于身份验证协议。如何获取信息取决于 IdP。

OpenID 连接 内的信任

您的 CXone 客户代表 将与您一起使用 OpenID 连接 配置 CXone 业务单位关闭 用于管理 CXone环境的技术支持、计费和全局设置的高级组织分组 和外部 IdP 之间的信任关系。

OpenID 连接 内的信任涉及到以下值，您需要这些值来配置关系：

  • 签发方 — 这个值看起来总是像一个 URL。签发方的值因外部 IdP 的不同而不同，但它们看起来总是像一个 URL。例如，Google 可用作一个外部 IdP，且支持 OpenID 连接。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 业务单位关闭 用于管理 CXone环境的技术支持、计费和全局设置的高级组织分组 和外部 IdP 之间创建信任关系。

字段

详细信息
实体 ID

使用 SAML 2.0 协议时，您的外部 IdP 可能要求您在它们一侧输入的预先填充且不可编辑的全局唯一 ID。IdP 将其包含在 SAML 2.0 请求消息中作为签发者的实体 ID。包括 Okta 和 OneLogin 在内的某些 IdP 不需要您在其一侧配置实体 ID。包括 Salesforce 在内的其他 IdP 则不然。

端点 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 对所有用户采用相同的授权流程。无论是通过访问密钥还是密码进行身份验证都无关紧要。