配置中央身份验证服务器
中央身份验证服务器 (CAS) 可管理参与 SSO 框架的 PTC 产品之间的信任关系。CAS 充当应用程序之间的代理，可授权用户登录，并在授权后颁发和验证在服务提供者和资源服务器之间交换的访问令牌。
以下是部署 CAS 时应考虑的一些常规提示：
• 查看用户登录会话的最长有效时间，并考虑是否应在参与 SSO 解决方案的所有应用程序中使用相同的值。
• 确认系统能够在可接受时间偏差容限内正常运行。如果一个或多个系统时钟与 CAS 不同步，并且超出了系统中设置的偏差容限时间，则配置将出错，导致用户无法进行身份验证。
启用了 SSO 的 PTC 产品使用 SSO 框架和标准协议实现以下两个身份验证工作流：
• 联合身份验证
• 授权 - 使用 OAuth 授权类型的委派授权
联合身份验证
联合身份验证是将用户的登录请求与标识提供者中存储的凭据进行比较，从而验证用户身份的过程。
在 PTC 产品 SSO 架构中，应将中央身份验证服务器 (CAS) 配置为将用户登录请求重定向到企业 IdP。IdP 会验证用户登录凭据的真实性，并创建断言，以证明用户已通过身份验证。根据 PTC 产品支持的协议 (请参阅 PTC 产品支持的 SSO 协议) 和客户配置，身份验证将使用 SAML 或 OIDC 来实现。
通过身份验证后，将向请求应用程序发送断言，表明用户已成功通过身份验证并授权用户登录。在此事务处理过程中，CAS 和 PTC 应用程序都不会显示或管理用户凭证。当浏览器被重定向到 IdP 时，用户客户端代理 (浏览器) 和 IdP 之间将直接进行用户名和密码信息的交换。必须为依赖同一 CAS 中的用户身份验证的同一联合中的每个 PTC 产品创建单独的服务提供者 (SP) 连接。
根据 SSO 配置，将遵循标准 SAML 和 OIDC 身份验证工作流。在选择用于 PTC SSO 配置的特定 CAS 技术之前，应审阅该技术支持的选项。
下方序列图中描述了身份验证工作流。在本示例中，ThingWorx 为 SP，PingFederate 为 CAS。ThingWorx 使用开放标准 SAML 2.0 协议在 SP 和 IdP 之间交换身份验证信息。
身份验证流程如下所示：
1. 用户尝试访问服务提供者。
2. 服务提供者会为用户生成 SAML 请求，并将请求发送至 CAS。
3. CAS 将 SAML 请求重定向到 IdP。
4. IdP 将用户重定向到身份验证页面，以供其提供凭据 (例如用户名和密码)。用户输入凭据后，IdP 将生成 SAML 响应。如果用户成功完成身份验证，则 SAML 响应中将包含一个提供用户授权的 SAML 断言。
5. 然后，IdP 会将响应重定向到 CAS。
对于第三方 IdP，必须在 SSO 设置中配置 CAS。
委派授权 (OAuth)
委派授权是一种概念，使服务提供者 (SP) 能够代表用户采取操作或访问资源服务器 (RS) 提供的资源，而无需用户与 RS 共享凭据。
从 CAS 请求 OAuth 2 访问令牌，然后将这些令牌用于从资源服务器请求数据。在分配访问令牌之前，资源服务器依靠 CAS 验证请求者是否为已通过身份验证的用户。您需要为参与委派授权场景的每个 PTC 应用程序创建单独的 OAuth 客户端。
PTC 产品可配置范围，以此作为附加保护措施来进一步保护受 OAuth 保护的资源。当服务提供者发送访问令牌以及面向资源服务器的数据请求时，访问令牌还必须附有范围，该范围针对资源服务器中的数据进行注册。有关详细信息，请参阅管理委派授权中的范围。
PTC 产品支持交互式和非交互式客户端的 OAuth 授权类型。了解客户端功能对于确定要使用的正确授权类型非常重要。
 |
请务必查看特定的 PTC 产品文档，以确认产品所支持的 OAuth 授权类型。
|
◦ 交互式：用户向客户端进行身份验证，客户端将代表该用户请求资源；对资源的访问权限授权取决于最终用户授权。
◦ 非交互式：也称为机器对机器 (M2M) 交互。客户端作为应用程序，在请求 OAuth 令牌时必须向 CAS 进行自我标识。OAuth 令牌中的标识是机器标识 (客户端或服务主体)，并不代表人类用户。
下方序列图描述了 OAuth 授权代码工作流。ThingWorx 为 SP、PingFederate 为 CAS，而 Windchill 为 RS。ThingWorx 为交互式客户端，配置为使用开放标准 OAuth2 协议授权码工作流，以安全、可靠且高效的方式授权 SP 访问资源，并使用最终用户的用户 ID 进行资源检索。
授权流程如下所示：
1. 从 IdP 接收到 SAML 响应后，CAS 会发送一个授权请求页面，供用户批准。CAS 使用授权请求页面来获取授权以生成 OAuth 代码。
2. 用户授予访问权限后，CAS 会生成 OAuth 授权代码。然后，CAS 会将 SAML 响应和授权码重定向到服务提供者。
3. 服务提供者收到 OAuth 授权代码后，将使用授权代码向 CAS 请求访问令牌和刷新令牌。
4. CAS 将验证授权代码并生成 OAuth 访问令牌和刷新令牌。然后，CAS 会将这两个令牌发送到服务提供者。
5. 资源所有者 (通常为用户) 会向服务提供者请求内容，而后者需要资源服务器提供数据。
6. 服务提供者代表资源所有者使用访问令牌向资源服务器请求内容。
7. 资源服务器会通过 CAS 验证访问令牌。
8. 然后，资源服务器会获取请求的内容并将其发送给服务提供者。
9. 收到内容后，服务提供者会将其交付给资源所有者。
可以使用相同工作流来配置替代 CAS 技术；可能需要考虑采用特定的配置步骤和设置。
对于非交互式客户端，将使用客户端登录凭据工作流将客户端 ID 和密码传递到 CAS，以检索 OAuth 令牌。然后，系统会将 OAuth 令牌传递到 RS 以检索请求的资源。RS 必须配置为支持客户端登录凭据授权类型，以便能够管理 OAuth 令牌并验证请求。下方序列图描述了客户端登录凭据工作流，其中非交互式客户端作为 RS 向 Windchill 请求资源。
还可以将 SSO 架构配置为与多个服务提供者和多个资源服务器的联合。SP 和 RS 配置由单个 CAS 管理。这样，所有用户标识都在联合中共享。在下方示例中，Windchill Navigate 为服务提供者，Windchill 和 SAP 为资源服务器。
