In the built-in authentication support, the HTTP protocol is stateless. It operates on a per-request basis and has no notion of a client session. To give a server more control over an authenticated session, it is possible to ignore the HTTP protocol built-in authentication support and to rely on stateful session tracking by the server instead. The most common approach is form-based authentication. This mechanism inserts an intermediate HTML page containing a log on form into the user interaction. Form-based authentication relies on the assumption that the user is browsing hyperlinks in HTML pages and can understand how to fulfill the log on page whenever it is presented. Servers using a form-based log on typically track a user session by setting HTTP cookies that are used to recognize subsequent requests as being part of the same authenticated session. This allows the server to time out or log out of the session and to force re-authentication by presenting the log on form at any time.

It is important to realize that form-based authentication is an application level convention for the use of HTTP and is not a part of the HTTP protocol itself. Form-based authentication bypasses the HTTP protocol authentication mechanism. Instead, it uses other features of the HTTP protocol [such as cookie headers and, possibly, redirects (status code 3xx responses)] to achieve authentication without interactions with the protocol. Therefore, form-based authentication cannot be transparently handled at the protocol level and clients used to access Windchill must be specifically designed to support form-based authentication. For example, Windchill programs, such as visualization services or Windchill Desktop Integration, may require changes when form-based authentication is used. Additionally, some Windchill gateway functionality may require changes.

For information about using a form-based authentication solution, see Configuring an Alternative Authentication in Windchill.