Community Tip - You can change your system assigned username to something more personal in your community settings. X
I am looking if someone has a good summary on these two Location declarations. In my journey to move to SSO, I've been trying to find the right balance, SSO for users, basic for non-users and integrations, trustedHost for CAD workers and Index Server, etc. Security is also on my mind, not allowing any additional attack vectors.
I came across article Windchill Authentication with a Host IP (Trusted Host) configuration is deprecated which gave me pause. I was also dealing with issues with ThingWorx Navigate called out in How to have basic authentication for some URLs when SSO is enabled. So just taking a moment to make sure I get things right and watch out for future changes.
From what I gathered from trustedHost entries and trustedAuth, it was an anonymous Location declaration which would allow unauthenticated access from any host or IP listed in trustedHost line. Yep, I can see how that would cause me pause but between Windchill host, index server and CAD worker, I can see how it would make things work easier (CAD Worker publishing, SSO and trustedHosts). Since PTC has decided to deprecate this, its obvious that relying on the host's security is not sufficient. Can't wait to see what they come up with.
As for protocolAuth, I could not find much but it appears to me to be a Location prefix where you can append any other Windchill path and it will allow a different authentication mechanism. I found the following supporting articles:
Does it have another function? I stumbled across this when diagnosing an integration which was calling a Windchill report expecting a CSV file. It returned the shibboleth redirect page text as described above. Adding protocolAuth to the URL worked and we are back to Basic. It seems like REST calls might use this too and any command line calls from server shell. I haven't tested fully it seems I only needed to keep Basic config kicking around for this Location. Do I have that right?
Solved! Go to Solution.
Hah... I started and stopped last night and almost sent you a message.
From my understanding, protocolAuth was really for noninteractive client access to Windchill. Regardless of whether or not you use it now, it was always there. You would use it for forms based auth, infoengine calls etc.
The trustedHost stuff was being deprecated, I believe, to allow different methods to secure connections to remote machines. I spoke with PTC about this last year a little. It is still around (and needed) in 13.0.2.0. One thing I did notice in 13.0.2 - when adding CAD workers, you now have the ability to pass the credentials from the worker setup.
Additionally, you secure the trustedhost by configuring the path to which you want to allow EXE's to run with the worker.exe.allowlist.prefixes property, then lock down that folder so only certain accounts can use it.
Hah... I started and stopped last night and almost sent you a message.
From my understanding, protocolAuth was really for noninteractive client access to Windchill. Regardless of whether or not you use it now, it was always there. You would use it for forms based auth, infoengine calls etc.
The trustedHost stuff was being deprecated, I believe, to allow different methods to secure connections to remote machines. I spoke with PTC about this last year a little. It is still around (and needed) in 13.0.2.0. One thing I did notice in 13.0.2 - when adding CAD workers, you now have the ability to pass the credentials from the worker setup.
Additionally, you secure the trustedhost by configuring the path to which you want to allow EXE's to run with the worker.exe.allowlist.prefixes property, then lock down that folder so only certain accounts can use it.