Authentication Security Considerations
Windchill relies on a site's existing HTTP authentication infrastructure to provide user authentication. Typically, this is a web server, which authenticates HTTP requests using an LDAP-accessible directory server as its user database. Access to Windchill-served resources is then restricted to authenticated users. This authentication often uses HTTP basic authentication. However, because it is a function of the web server and browser, additional authentication schemes and third-party security products can be used transparently in Windchill. Windchill does not rely on HTTP session state (such as cookies) for authentication. It does not preclude the use of web application servers that use cookies in their authentication schemes, but its use would be transparent to Windchill. In Windchill, each HTTP request is authenticated by the web server or servlet engine before reaching Windchill code. Windchill requires that the hosting web server and servlet engine provide the authenticated user name with each HTTP request. It does not matter how the user name is determined.
Windchill keeps track of the resources that are used for authentication in the following file:
<Windchill>/apacheConf/config/authResAdditions.xml
where <Windchill> is the directory where your solution is installed. Any resource that requires user identification to generate a unique dynamic response for the given user is included in this file. For those entries not specifying a type attribute, this user identification can be obtained through form-based or protocol-based (such as HTTP basic) authentication. For entries of type protocolAuth, the authentication must be protocol-based, not form-based.
 |
No authentication can be applied to entries of type anonymous; these entries must be anonymously accessible and configurations requiring authentication of these resources are not supported.
|
Although each authenticated HTTP request is individually authenticated by the web server or Java servlet/JSP server, Java RMI communication uses direct connections between Java clients and Windchill RMI servers. This direct communication leverages HTTP authentication in the following manner:
• It establishes session state on behalf of the RMI client within the Windchill servers.
• It uses an authenticated HTTP request to identify the session's user.
Subsequent RMI calls from the client to the server contain information that maps the call to an existing authenticated session. This RMI session authentication happens automatically on an as-needed basis. When an attempt is made to invoke services that require user identification, this is handled transparently to the calling code, unless the calling client is a multi-user server application itself. In that case, the calling code should explicitly manage thread-based context when calling Windchill APIs. For more information, see the JavaDoc for wt.util.WTContext and wt.httpgw.WTContextBean.