SSO Setup

Active Workspace over TLS (the web tier touches)

First, the thing that surprises people

★★ Active Workspace on Teamcenter 2606 is served by a Node gateway, not by Tomcat. Older notes on this tier pointed at C:\apps\Tomcat9, which does not exist on this build. The gateway is:

C:\apps\PLM\tc_root\microservices\gateway\
    node.exe server.js --config config.json --signerKeyPath=...\signer_keystore.pem

⚠ Looking for web applications in a directory that does not exist returns empty, exactly as an empty directory does. Get-ChildItem <missing> -ErrorAction SilentlyContinue therefore reads as "nothing is deployed" regardless of the truth. Use Test-Path, with a known-good and a known-bogus control in the same call.

The switch, read out of the shipped source

The gateway needs no plugin and no proxy. TLS is two config keys, and the behaviour is unambiguous in lib/expressServer.js:

// :401  the switch is purely "are both paths non-empty"
const secure = argv.https || keyPath && keyPath.length > 0
                          && certPath && certPath.length > 0 || false;

// :608
const _server = secure ? await createHttpsSvr( app ) : await createHttpSvr( app );

// :328-329  PEM TEXT. A PFX will NOT work here.
options.key  = await readFile( keyPath,  { encoding: 'utf8' } );
options.cert = await readFile( certPath, { encoding: 'utf8' } );

★★★ It binds ONE port and serves it as HTTP or HTTPS, never both. There is no dual-listener configuration. This is why plain :3000 could not be kept alive alongside TLS, and why every consumer had to be repointed at once.

What was changed

In C:\apps\PLM\tc_root\microservices\gateway\config.json:

Key	Before	After
`port`	`3000`	`443`
`keyPath`	`""`	`.../microservices/certs/tc-server.key`
`certPath`	`""`	`.../microservices/certs/tc-server.crt`
`forceSecureAttributeOnCookies`	`false`	`true`

forceSecureAttributeOnCookies matters and is easy to miss: without it the gateway keeps issuing session cookies without the Secure attribute over what the browser believes is a TLS session. Those are precisely the cookies SSO depends on.

Also added: an inbound firewall rule for 443 scoped to the Hyper-V host, matching the scope of the existing rules.

Practical notes that cost time

★ Use forward slashes in the JSON paths. C:/apps/... avoids the backslash escaping that silently produces a path the gateway cannot open.

★ Validate the JSON before writing it. A malformed config.json means the gateway never starts, and the symptom is a dead web tier rather than a config error.

★ Write the PEM files without a BOM. readFile(..., 'utf8') would carry a BOM straight into the PEM parser. Use [System.IO.File]::WriteAllText with UTF8Encoding($false), then assert the first three bytes are not EF BB BF.

★★ The gateway is supervised by Teamcenter Process Manager, NOT Teamcenter WebTier. Restarting WebTier will not reload it. Config is read only at process start. (On this occasion no restart was needed at all: the tier was restarted for unrelated reasons and the gateway picked up the new config on its first start.)

The 8080 web tier: assessed, not changed

The gateway proxies /tc to http://SIEMENSDC:8080/tc, which is TcWebTierService.exe, a Jetty server. That hop is still plaintext, and that is an honest gap rather than a decision that it does not matter.

Two findings about it:

It can take SSL. It ships config/jetty-webtier/jetty-https.xml, jetty-ssl.xml and jetty-ssl-context.xml, so the capability is present if the internal hop ever needs encrypting.
⚠ It is reachable from outside the guest. The guest firewall has an enabled inbound rule literally named ALL_Ports (LocalPort Any, RemoteAddress Any), and DefaultInboundAction reads NotConfigured on all three profiles. So the carefully host-scoped rules for 3000/4544/8070 are decorative, and 8080 answers in plaintext from the host. This was found by predicting the port would be blocked and testing it rather than asserting it.

Net: Teamcenter is encrypted at the gateway and still available unencrypted on 8080 to anything on that subnet. Closing that is a VM-level firewall decision, not a Teamcenter one.