Skip to content

Additional Security Considerations

When deploying OSLC adapters in distributed environments, several security configurations are required to ensure proper operation while maintaining security standards.

Distributed Deployment Security

Modern web browsers implement multiple protection mechanisms that must be properly configured across all servers in a federated deployment.

Security Protection Mechanisms

The following security mechanisms must be properly configured:

  • Session Management with JSESSIONID
  • Mixed-mode guards (HTTP/HTTPS)
  • Cross-Origin Resource Sharing (CORS) guards
  • Content Security Policies (CSP)
  • Cross-site Request Forgery (CSRF) guards

Cookie Name Conflicts

If you install the Adapter web application and Collaborative Lifecycle Management (CLM) on the same WebSphere Application Server or behind the same reverse proxy, you must change the HTTP session management cookie name.

Both CLM and the adapter use the same JSESSIONID cookie in HTTP sessions. CLM sometimes resets the cookie during login, causing the adapter to lose its session in linking scenarios.

Configuration steps: - Changing the HTTP session management cookie name for Apache Tomcat - Changing the HTTP session management cookie name for WebSphere

HTTP/HTTPS Mixed-mode Blocking

"Mixed-mode" refers to requesting content from both insecure HTTP and secure HTTPS servers. Modern browsers block mixed-mode requests for security reasons.

Mixed-mode Prevention

To avoid mixed-mode denial of service, all servers in your organization must use either only HTTP or only HTTPS.

HTTPS Requirements

When using HTTPS:

  1. Valid SSL Certificates: All servers must use SSL certificates issued by trusted root Certificate Authorities
  2. No Self-signed Certificates: Self-signed SSL certificates cannot be used
  3. Certificate Trust Chain: Each JVM acting as a client must explicitly add SSL certificates to their "cacerts" key stores

SSL Configuration Steps

SSL Setup Checklist

Follow these steps to ensure proper SSL configuration:

  1. Obtain SSL Tools
  2. Get a Java SSL connection utility (e.g., "portecle" or "SSLpoke")

  3. Obtain root-CA-signed certificates (e.g., from "LetsEncrypt")

  4. Configure CLM Server

  5. Install root-CA-signed certificate into the server keystore

  6. Update cacerts files on PLM and RLIA servers with CLM certificates

  7. Configure PLM Server

  8. Enable SSL service and disable HTTP

  9. Install certificates and update cacerts on CLM and RLIA servers

  10. Configure RLIA Server

  11. Install SSL certificates
  12. Update cacerts on CLM and PLM servers

Final Result

When complete, you should have 3 root-signed certificates and 6 trust relationships configured.

Cross-Origin Resource Sharing (CORS)

CORS allows controlled access to resources from different origins. Without proper CORS configuration, browsers will reject cross-origin requests.

CORS Definition

Cross-Origin Resource Sharing (CORS) uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin than the site currently in use.

CORS Configuration

Configure the following HTTP headers:

Source Header Value Purpose
Client Origin https://windchill.acme.com Required for CORS requests
Server Access-Control-Allow-Origin https://windchill.acme.com Allowed origins
Server Access-Control-Allow-Methods OPTIONS, GET, DELETE, POST, PUT, PATCH Allowed HTTP methods
Server Access-Control-Allow-Headers Origin, Authorization, DoorsRP-Request-Type Allowed request headers
Server Access-Control-Expose-Headers WWW-Authenticate, X-jazz-web-oauth-url Exposed response headers
Server Access-Control-Allow-Credentials "true" Enable credential sharing

Configuration guides: - Configuring CORS for Apache Tomcat - Configuring CORS for IBM WAS Liberty

JavaScript Requirements

For browsers to honor CORS requests, XHR requests in client JavaScript must include the withCredentials: true parameter.

Content Security Policies (CSP)

CSP helps prevent Cross-site Scripting (XSS) attacks by controlling which resources can be loaded and executed.

CSP Purpose

CSP mitigates XSS attacks by specifying which domains the browser should consider valid sources of executable scripts.

CSP Configuration for Jazz CLM

  1. Access JTS Admin Site

  2. Browse to each CLM realm (e.g., "rm", "cm", "gc")

  3. Configure Whitelist

  4. Select "Manage this Application" from Administration menu
  5. Choose "Whitelist" from the panel
  6. Add PLM server URL (e.g., https://windchill.acme.com)

Modern Browser Requirements

Modern browsers require proper CSP headers and specific targetOrigin parameters in window.postMessage calls.

Cross-Site Request Forgery (CSRF)

CSRF protection prevents unauthorized actions by ensuring requests come from legitimate sources.

CSRF Attacks

CSRF attacks force users to execute unwanted actions on applications where they're currently authenticated.

CSRF Implementation

The adapter uses OWASP CSRF Guard as a Java Servlet Request Filter to inject session state and prevent CSRF attacks.

Network requirements: - HTTP packet filters must not strip CSRF state - Proxy servers must pass along CSRF state

See Also