CAD Worker publishing, SSO and trustedHosts

[avillanueva]

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?

[jbailey]

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]

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]

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.

[avillanueva]

In this case, I have a non-AD account managed by local LDAP (OpenDJ) but one that I do not use for interactive login. There is this note from the help docs:

This confirms what I was questioning, password not required. I found that confusing since my assumption is that when the CAD worker fired up, it was passed previously, username and password that it used to connect inside of Creo to create a workspace, download files and publish them. That process would have hit the webserver now configured for SSO to AD. Since that user is NOT an AD user, authentication should have failed. So WVS must be passing something that bypasses this and the webserver allows it through. 

I get the security expectation at the server level (yes, that is how I supplied username). I just want to make sure I didn't open things too much on the CAD worker. Is it therefore possible that I could open a browser from the  CAD worker host to Windchill and connect as any user by just supplying a username? That would not be good. 

I may eventually replicate the non-user admins in AD but regardless, what piece decides where to validate the credentials against? It must be the webserver right? With basic auth it was easy, some LDAP configured in the Location section. Now with SSO, its a bit more complex. Seems like there is no pathway that works other then trustedHosts.

[avillanueva · Accepted solution]

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.