This section describes the various authentication strategies that Windchill can support.

The Windchill user authentication strategy is based on Java Platform, Enterprise Edition (Java EE). The Java EE authentication strategy removes the responsibility for authentication from the web application, and the responsibility is given to the Java EE web application container on which the application is deployed. The intent is to make the authentication mechanisms and policies that are used at runtime become properties of the environment in which the application is deployed. Authentication is not written in the application code.

Java EE web application containers are necessary to support the following:

Commercial web server security products, such as SiteMinder, may include these and add additional options for tokens (SecureID), Biometrics, or single sign-on across multiple sites. Mechanisms other than HTTP basic and SSL/TLS client authentication typically behave similar to form-based authentication. These mechanisms rely on client session tracking by using HTTP cookie headers to achieve their results.

Windchill is designed to rely on web server authentication to provide authenticated user names. Therefore, access controls that are maintained on the web server or servlet engine determine access privileges to an authenticated Windchill URL. These controls determine access based on a user name and password that is obtained by the web browser. The HTTP authentication implementation results in the following Windchill configuration requirements:

To understand how following a standard Java EE authentication strategy can still lead to problems, you must understand the mechanisms at work behind the scenes as described in the following sections.

The HTTP protocol has mechanisms for authentication. A server receiving an unauthorized request for a protected resource returns a 401 response status code along with a WWW-authenticate header which indicates what authentication scheme is required to access the protected resource. The request must be redone with an appropriate authorization header in the next request. An HTTP proxy can also add a layer of authentication that uses Proxy-authenticate and Proxy-authorization headers in the same way.

One of the standard HTTP authenticate schemes is HTTP Basic authentication, which requires all user requests for a resource to have a valid user name and password to access information within the protected realm, which is a portion of the web site. To prevent re-authenticating each request, the HTTP client (web browser) stores the user name and password in order to supply them for every request.

However, the HTTP server cannot force the browser to clear the user name and password because they are cached per protected realm on the client side. Thus, the HTTP server cannot force re-authentication. This limitation can be addressed by using an alternative authentication mechanism, such as a single sign-on tool.

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.

In this topic, SSL/TLS (Secure Socket Layer/Transport Layer Security) Client Authentication and HTTPS Client Authentication are used interchangeably. HTTPS is essentially HTTP performed over a secure communication channel using SSL/TLS, which are protocols for negotiating and establishing an encrypted connection over TCP connections. HTTP Basic authentication happens at the protocol level, and form-based authentication happens at the application level (which is above the protocol level). HTTPS client authentication happens below the protocol level at the transport level.

HTTPS can use SSL/TLS in two ways:

HTTPS client authentication happens outside the HTTP protocol authentication mechanism (such as form-based authentication). However, HTTPS client authentication happens below the HTTP protocol. Therefore, it can remain transparent to the application code usage of HTTP (unlike form-based authentication). To do this, the user’s certificate and private key must be available to use when opening SSL connections. For Java applications, this can require setting Java system properties to communicate the necessary keystore properties to the protocol handlers.

In addition to host-based certificates, TrustedAuthFilter now supports trusting clients based on 2-way SSL certificates. In this case, the client certificate does not need to be mapped to a particular user; rather, it can simply be an additional credential (much like an invitation to a party or a club membership). This client certificate then provides the user identify. For additional information about using TrustedAuthFilter, see its Javadoc.

NTLM is the Microsoft Windows NT challenge and response authentication system. The local user domain authentication credentials are used to authenticate against web resources. The Windows domain controller sends the client a random challenge. The client uses this random challenge and the user’s credentials to construct a response. This response is sent to the domain controller and the domain controller decrypts the response and validates the user credentials.

NTLM authentication has special requirements that the client protocol handler must be able to fulfill. This authentication scheme will not work without a client protocol handler capable of understanding NTLM challenges and generating the correct response.

Security Assertion Markup Language (SAML) authentication is an XML-based open standard authentication framework maintained by the OASIS Security Services Technical Committee. SAML provides a framework for single sign-on capabilities for service providers within a federation. PTC has tested and documented a configuration with Shibboleth Service Provider that establishes Windchill as a service provider that can participate in a SAML-based single sign-on federation. This authentication method requires expertise in the SAML standard. Consult with your organization’s Identity Provider administrator or local SAML expert to understand your federation configuration requirements.