Configurations Necessary for Distributed Deployments

The Connector is a web service that gathers and dispenses information from a federation of servers. Modern web browsers employ several protection mechanisms to prevent attackers from gaining access to unauthorized information and from forcing the user’s browsers to perform forbidden behavior.

Such protections include:

Successful operation of OSLC Connect for Windchill requires that each of these protection mechanisms is properly configured on the appropriate servers of the federated deployment.

Session Management Cookie (JSESSIONID)

If you install OSLC Connect for Windchill web application and Collaborative Lifecycle Management (CLM) on the same WebSphere Application Server or if the Connector and CLM are behind the same reverse proxy, such as IBM HTTP Server (IHS), you must change the HTTP session management cookie name. CLM and the Connector both use the same JSESSIONID cookie in an HTTP session. CLM sometimes resets the cookie when you log in, which causes the Connector to lose its session in some linking scenarios. See Changing the HTTP session management cookie name for Apache Tomcat or Changing the HTTP session management cookie name for WebSphere as required.

HTTP / HTTPS Mixed-mode Blocking

“Mixed-mode” is the requesting of content from both insecure HTTP servers and secure HTTPS servers and the execution of browser scripts from a set of servers using both HTTP and HTTPS protocols.

In legacy browsers, the browser would allow script loaded from HTTPS servers to make “mixed-mode” requests to HTTP servers. Today, modern browsers block these requests.

To avoid mixed-mode denial of service, the organization’s servers must all use HTTPS. Furthermore, when using HTTPS, the servers must use SSL Certificate credentials which are issued by trusted root Certificate Authorities. An organization cannot use “self-signed” SSL certificates.

Not only must each server in the deployment present a valid, root-trusted SSL certificate, each of the other two JVMs which act as clients to the other server must explicitly add the SSL certificate to their “cacerts” key stores.

The “cacerts” file used by an application is often not the same as the one used by a user’s browser or by the default “JAVA_HOME” JVM on the hosting server.

To assure that proper SSL keys are published and then are trusted:

  1. Obtain a Java SSL connection utility such as “portecle” or "SSLpoke"
  2. Obtain 3 root-CA-signed certifications from a service such as "LetsEncrypt"
  3. On the CLM server
  4. On the PLM server
  5. On the OSLC Connect for Windchill server

When finished, you should have 3 root-signed certificates and 6 trust relationships. If one or more of these 9 configurations is incorrect, the Connector integration will fail in one or more ways.

Content Security Policies (CSP)

In addition to performing client-to-server requests, the Connector within the Windchill Javascript in the browser of a PLM user will also attempt to make requests between the browser’s execution contexts, that is between windows whose source was loaded either from the PLM server (in Windchill extensions) or from the OSLC Connect for Windchill server (in JSP-loaded scripts) or from the CLM server (in iframe content). Without the use of CSP headers on the servers, the user’s browser will reject those cross-domain requests.


"A primary goal of Content Security Policy (CSP) is to mitigate and report Cross-site Scripting (XSS) attacks. XSS attacks exploit the browser’s trust of the content received from the server. Malicious scripts are executed by the victim’s browser because the browser trusts the source of the content, even when it’s not coming from where it seems to be coming from.

CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those whitelisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes)."

In legacy versions of browsers and of Javascript, a programmer could set the targetOrigin argument in window.postMessage calls to be “✱” to allow all sites to post messages between the browser’s windows. In modern versions of the browsers, the use of “✱” only disables the error warning that the browser would otherwise raise for cross-site messaging. Today, the servers must provide a suitable Content-Security-Policy header for their scripts and the programmer must supply a proper host URL for the targetOrigin parameter.

To configure CSP support in Jazz CLM for the PLM server:

  1. Browse to the JTS admin site for each of the CLM realms with which the Connector has an association
  2. Select Manage this Application from the Administration menu
  3. Select Whitelist from the panel of Consumers, Friends, and Whitelist
  4. Add a new URL for the PLM server to the set of any Whitelisted URLs already present
Cross-Site Request Forgery (CSRF)

The Connector server responds to requests that are external to it with information that is intended only for the authorized user making the originating request. To assure that responses from the server are not sent to unauthorized strangers, the Connector server exploits CSRF protections.


"Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request."

The Connector web application uses the OWASP CSRF Guard as a Java Servlet Request Filter on each request to inject session state to prevent CSRF attacks.

Your network should not employ HTTP packet filters that strip CSRF state from packets or use proxy servers that neglect to pass along CSRF state.