Windchill 依赖站点现有的 HTTP 验证体系结构提供用户验证功能。这通常是一个 Web 服务器，可通过使用作为其用户数据库的 LDAP 可访问目录服务器来验证 HTTP 请求。只允许通过验证的用户访问 Windchill 资源。该验证过程经常使用 HTTP 基本验证。然而，因为这是 Web 服务器和浏览器的功能，所以可在 Windchill 中透明地使用其他验证方案和第三方安全产品。Windchill 并不依赖于 HTTP 会话状态 (例如 cookie) 来进行验证。Web 应用程序服务器在其验证方案中使用 cookie，但是 cookie 的使用对于 Windchill 来说是透明的，鉴于该服务器的这个特点所以对其使用不予以排除。在 Windchill 中，每个 HTTP 请求在到达 Windchill 代码前都经过了 Web 服务器或 servlet 引擎的验证。Windchill 要求主 Web 服务器和 servlet 引擎为每个 HTTP 请求提供经过验证的用户名。可以不考虑如何确定用户名。

Windchill 保持对以下文件中用于验证的资源进行跟踪：

其中 <Windchill> 是安装解决方案的目录。此文件中包含所有为生成特定用户的唯一动态响应而需要用户标识的资源。对于那些没有指定类型属性的条目，此用户标识可通过基于表单或基于协议 (如：HTTP 基本验证) 的验证来获得。对于协议验证类型的条目，认证必须是基于协议的而不能是基于表单的。

尽管每个已验证的 HTTP 请求都是由 Web 服务器或 Java servlet/JSP 服务器单独进行验证，Java RMI 通信还是使用了 Java 客户端和 Windchill RMI 服务器之间的直接连接。这种直接通信通过以下方式利用 HTTP 验证：

从客户程序到服务器的后续 RMI 调用包含将该调用映射到现有已验证的会话的信息。该 RMI 会话验证将根据需要自动进行。当试图调用需要用户标识的服务时，这种处理对于调用代码来说是透明的，除非进行调用的客户程序本身是一个多用户服务器应用程序。在这种情况下，当调用 Windchill API 时，调用代码应明确地管理基于线程的环境。有关详细信息，请参阅 wt.util.WTContext 和 wt.httpgw.WTContextBean 的 JavaDoc。