Skip to main content
avillanueva
23-Emerald I
23-Emerald I
July 22, 2024
Solved

CAD Worker publishing, SSO and trustedHosts

  • July 22, 2024
  • 1 reply
  • 2242 views

I am curious what goes on behind the scenes with using trustedHosts setting. I am knee deep in on playing with SSO but still have some accounts that are not using SSO (not AD). This help doc points to using trustedHost parameter:  https://support.ptc.com/help/wnc/r12.1.1.0/en/index.html#page/Windchill_Help_Center/WVSPrintManagement/WVSVisualizationFormbasedAuthentication.html

Seems like doing this, I can remove the password from auth.properties for my publishing user. From what I knew before with basic auth, the creds would get passed to the CAD worker with would start a Creo session and register a workspace just like a normal user. I would expect that to hit the webserver which is configured for SSO. What black magic occurred since it appears like Windchill trusts all connections from that host? How did it not get blocked by the webserver?  I may need to explain for our security folks. Is there any other alternate configurations for the publishing user when configured for SSO that do not rely on trustedHost?

Best answer by avillanueva

Closing this one out. I will assume that when you configure CAD worker without password, it utilizes the trustAuth location in the webapp configuration to grant authorization based on hostname. I figured the CAD worker first pings that URL to establish a session then continues with the normal workspace operations. 

1 reply

jbailey
18-Opal
July 24, 2024

The creds still get passed when configured for SSO using auth.properties. They go through the protocolAuth endpoint, which allows basic credentials to be passed. As you mentioned, if you don't use auth.properties, all publishing will happen under the username of the user who submits a job - meaning that publishing will fail if a non-MCAD user tries tp publish a representation (because they aren't assigned to one of the MCAD licenses in Windchill).

 

The wt.auth.trustedHosts property also works along with worker.exe.whitelist.prefixes. In the second property, you define the location that things can run from on the trusted host from a worker standpoint.

avillanueva
23-Emerald I
23-Emerald I
July 24, 2024

Not quite following. Previously, my auth.properties was username:password and we used basic auth. According to that link, I dropped the password portion in that file and added CAD worker IP to trustedHosts. Publishing still succeeded. I did not use the $user variable which I think is what you are referring to, the user who submits the job. It still is a admin level non-user account who should be executing publishing jobs. I will double check on this. My question was does being a trustedHost forgo the need for a password from that host? For example, when executing windu, I provided a username in the command line but no password. It ran successfully. 

jbailey
18-Opal
July 24, 2024

OK I thought you were using the $user variable. I can confirm that if you maintain the user:password configuration, it uses username and password even with SSO configured. I would recommend that method as long as it is supported. I can also confirm that if the account password changes, it WILL fail if your auth.properties is set with user:password (Ask me how I know 🙂 ).

 

I would also recommend using an AD managed service account that is never used for interactive login.

 

I am assuming you used In Windchill shell, running commands with SSO, you need to use the "--javaargs="-Dwt.auth.trustedAuth.username=<YOUR ADMIN USER>" switch - which I am assuming you did because you ran windu :-).

 

At this point, PTC is expecting that your security is sufficient at the VM/server level.. You need to make sure that only certain people can RDP to the server, and that file/folder permissions are set to the level required for admins to manage Windchill and the system to run.