验证
本部分将介绍 Windchill 可支持的各种身份验证策略。
Windchill 身份验证策略
Windchill 用户身份验证策略基于 Java Platform、Enterprise Edition (Java EE)。Java EE 身份验证策略将免除 Web 应用程序的身份验证责任，并将此责任赋予部署该应用程序的 Java EE Web 应用程序容器。目的是使运行时所使用的身份验证机制和策略成为用于部署该应用程序的环境的特性。身份验证不会写入应用程序代码中。
Java EE Web 应用程序容器必须支持以下内容：
• HTTP 基本验证
• SSL/TLS 客户端身份验证
• 基于表单的身份验证
商用 Web 服务器安全产品 (如 SiteMinder) 可能会在多个站点中包含这些并添加令牌 (SecureID)、生物特征或单一登录的附加选项。除 HTTP 基本验证和 SSL/TLS 客户端身份验证以外，其他机制通常与基于表单的身份验证类似。这些机制依赖于客户端会话跟踪，方法是使用 HTTP cookie 标头来获得其结果。
Windchill 的设计用途是依靠 Web 服务器验证来提供已验证的用户名。因此，Web 服务器或 servlet 引擎上维护的访问控制可确定对已验证 Windchill URL 的访问权限。这些控控制根据 Web 浏览器获得的用户名和密码确定访问权限。HTTP 验证的实施会带来如下 Windchill 配置要求：
• 验证用户名是 Web 服务器用户名。
• Windchill 经身份验证的 URL 必须受到 Web 服务器或 servlet 引擎的访问控制，仅允许已通过身份验证的用户对其进行访问。默认情况下，使用的身份验证机制为 HTTP 基本身份验证 (用户名和密码)。
如需了解在遵循标准 Java EE 身份验证策略的情况下仍然能导致问题的原因，则必须了解后续各部分中所述的幕后运行的机制。
HTTP 基本验证
HTTP 协议具有用于身份验证的机制。接收受保护资源的未授权请求的服务器会返回 401 响应状态代码以及 WWW-authenticate 标头，用于指示访问受保护资源所需的身份验证方案。该请求必须在下一个请求中使用相应的身份验证头重新执行。HTTP 代理也可以通过相同方式添加一个使用 Proxy-authenticate 和 Proxy-authenticate 标头的身份验证层。
HTTP 基本身份验证是标准 HTTP 身份验证方案之一，它要求资源的所有用户请求都具有有效的用户名和密码才能访问受保护领域 (Web 站点的一部分) 中的信息。为避免对每个请求重新进行身份验证，HTTP 客户端 (Web 浏览器) 会存储用户名和密码，以便在每次请求时提供。
但是，HTTP 服务器无法强制浏览器清除用户名和密码，因为用户名和密码在客户端上每个受保护领域中都进行了缓存。因此，HTTP 服务器无法强制进行重新身份验证。此限制可通过使用替代验证机制 (如单一登录工具) 来解决。
基于表单的身份验证
在内置身份验证支持中，HTTP 协议是无状态的。它以每个请求为基础运行，并且没有客户端会话的概念。为使服务器对已验证会话进行更多控制，可以忽略 HTTP 协议内置身份验证支持，并改为依赖于通过服务器进行有状态会话跟踪。最常用的方式是基于表单的身份验证。此机制会将一个包含登录表单的中间 HTML 页面插入到用户交互中。基于表单的身份验证假设用户将在 HTML 页面中浏览超链接，并了解在每次显示登录页面时如何完成所需操作。服务器使用基于表单的登录时通常会通过设置 HTTP cookie 来跟踪用户会话，其中 HTTP cookie 旨在将后续请求识别为该已验证会话的一部分。这使得服务器可以超时或注销会话，并可随时通过显示登录表单来强制执行重新验证。
必须意识到基于表单的身份验证是使用 HTTP 的应用程序级约定，并不包含在 HTTP 协议之内。基于表单的身份验证会绕过 HTTP 协议身份验证机制。然而，它可使用 HTTP 协议的其他功能 [例如，cookie 标头和可能的重定向 (状况代码 3xx 响应)] 来实现身份验证，而无需与协议进行交互。因此，基于表单的身份验证无法在协议级别透明处理，并且用于访问 Windchill 的客户端必须进行专门设计以支持基于表单的身份验证。例如，在使用基于表单的身份验证时，可能需要更改诸如可视化服务或 Windchill Desktop Integration 之类的 Windchill 项目群。此外，某些 Windchill 网关功能可能需要更改。
有关使用基于表单的身份验证解决方案的信息，请参阅
在 Windchill 中配置替代身份验证。
SSL/TLS 客户端身份验证
在本主题中，SSL/TLS (安全套接字层/传输层安全性) 客户端身份验证和 HTTPS 客户端身份验证可互换使用。实际上，HTTPS 将通过使用 SSL/TLS 的安全通信信道执行，其中 SSL/TLS 是通过 TCP 连接进行协商和建立加密连接的协议。HTTP 基本验证发生在协议级别，而基于表单的身份验证发生在应用程序级别 (高于协议级别)。HTTPS 客户端身份验证发生在传输级别 (低于协议级别)。
HTTPS 可通过以下两种方式使用 SSL/TLS：
• 第一种也是最常用的方式是仅要求 SSL 连接的服务器端使用来自服务器证书的已认证公钥。这种方式用于处理以下用例：客户端需要确定其正在与预期服务器进行交谈，但如果需要对客户端进行身份验证，则服务器希望使用传统的身份验证机制，如 HTTP 基本身份验证或基于表单的身份验证。
• 第二种方式是要求 SSL 连接的服务器和客户端都具有已认证公钥。在这种情况下，服务器会根据建立 SSL 连接时所使用的客户端证书来标识客户端。这也称为相互 SSL 身份验证或双向 SSL 身份验证。对于 Java EE Web 应用程序，称为 HTTPS 客户端身份验证。
HTTPS 客户端身份验证是 HTTP 协议身份验证机制以外的其他验证 (例如基于表单的身份验证)。但是，HTTPS 客户端身份验证低于 HTTP 协议级别。因此，它可能对 HTTP 应用程序代码用例保持透明 (与基于表单的身份验证不同)。为此，在打开 SSL 连接时，用户的证书和私钥必须可用。对于 Java 应用程序，这可能需要设置 Java 系统特性，以将所需的密钥库特性传递到协议处理程序。
除基于主机的证书外，TrustedAuthFilter 现在还支持基于双向 SSL 证书的信任客户端。在这种情况下，不需要将客户端证书映射到特定用户；相反，它只是一个附加证书 (非常像派对邀请函或俱乐部会员证)。此客户端证书随后会提供用户标识。有关使用 TrustedAuthFilter 的其他信息，请参阅其 Javadoc。
Microsoft NTLM 身份验证
NTLM 是 Microsoft Windows NT 质询和响应身份验证系统。本地用户域身份验证凭据用于对 Web 资源进行身份验证。Windows 域控制器向客户端发送一个随机质询。客户端将使用此随机质询和用户凭据构建响应。系统会将此响应将发送至域控制器，然后域控制器将对响应进行解密并验证用户凭据。
NTLM 身份验证需要客户端协议处理程序必须满足某些特殊要求。如果客户端协议处理程序无法分析 NTLM 质询或无法生成正确的响应，则此身份验证方案无法正常工作。
安全声明标记语言 (SAML) 身份验证
安全声明标记语言 (SAML) 身份验证是基于 XML 的开源标准身份验证框架，由 OASIS 安全服务技术委员会维护。SAML 将为联合中的服务提供者提供单一登录功能的框架。PTC 已测试并记录了 Shibboleth 服务提供者的配置，其中将 Windchill 建立为可参与基于 SAML 的单一登录联合的服务提供者。此身份验证方法需要具备 SAML 标准方面的专业知识。如需了解联合配置要求，请咨询组织的标识提供者管理员或本地 SAML 专家。