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