Windchill は、サイトの既存 HTTP 認証インフラストラクチャによってユーザー認証を行います。通常はこの役割を Web サーバーが担い、LDAP 対応のディレクトリサーバーをユーザーデータベースとして使用して HTTP リクエストを認証します。これにより、Windchill が提供するリソースへのアクセスは、認証ユーザーのみに制限されます。多くの場合、この認証では HTTP 基本認証が使用されます。ただし、これは Web サーバーとブラウザの機能なので、Windchill ではほかの認証方式やサードパーティ製品を透過的に使用できます。Windchill での認証は、HTTP セッションの状態 (cookie など) に左右されません。認証スキームで cookie を使用する Web アプリケーションサーバーの使用は除外しませんが、Windchill にはバックグラウンドで使用されます。Windchill では、それぞれの HTTP リクエストが Windchill コードに到達する前に、Web サーバーまたはサーブレットエンジンによって認証されます。Windchill では、ホストの Web サーバーとサーブレットエンジンが、各 HTTP リクエストのユーザー名を認証する必要があります。ユーザー名の指定方法は特に問題にはなりません。

Windchill は、認証に使用されるリソースの状況を次のファイルで管理します。

ここでの <Windchill> は、ソリューションがインストールされているディレクトリです。特定のユーザーに対して一意の動的なレスポンスを生成するためにユーザーの識別を必要とするリソースは、このファイルに含まれています。タイプ属性を指定しないエントリの場合、このユーザー識別はフォームベースまたはプロトコルベース (HTTP 基本など) の認証によって取得できます。タイプ protocolAuth のエントリの場合、認証はフォームベースではなくプロトコルベースであることが必要です。

各認証済み HTTP リクエストは Web サーバーまたは Java サーブレット、あるいは JSP サーバーによって個別に認証されますが、Java RMI 通信では Java クライアントと Windchill RMI サーバーとのダイレクト通信が使用されます。ダイレクト通信では、以下のように HTTP 認証が利用されます。

クライアントからサーバーへの後続の RMI 呼び出しには、この呼び出しを既存の認証済みセッションへマッピングする情報が含まれます。この RMI セッション認証は、必要に応じて自動的に行われます。ユーザーの識別に必要なサービスの呼び出しが行われる際、呼び出しクライアントがマルチユーザーサーバーアプリケーションでないかぎり、呼び出しコードにバックグラウンドで処理されます。その場合は、Windchill API を呼び出す際、呼び出しコードがスレッドベースのコンテキストを明示的に管理する必要があります詳細については、wt.util.WTContext および wt.httpgw.WTContextBean に関する JavaDoc を参照してください。