Configuring Workers with Trusted Host Authentication
This section outlines topics specific to using Trusted Host Authentication with WVS. This feature allows workers to authenticate without a password, which enables the ability to use the "real user" — i.e. the user who submitted the job, as opposed to a configured user account — for authentication during batch print, batch interference detection, and publishing operations.
See Configuring an Alternative Authentication in Windchill for more details about Trusted Host Authentication with Windchill.
Beginning at Windchill 10.1, when using Trusted Host Authentication for remote workers, you can optionally specify the worker to authenticate as the user who submitted the job. This is done by creating a User Token in the auth.properties file in place of the actual username.
• Currently, users specify the publishing entry in the auth.properties file. A simple example of this could be auth=user:password or auth=$user. In the example:
auth.siteName.publishingApplication=publishing_user_name:publishing_user_password
the entry might appear as auth.master.PROE=wcadmin:wcadmin
In Trusted Host mode, you can now rely on token value user names that are substituted at runtime during publishing. During publishing, WVS interrogates the user entry in auth.properties for the site, and if the token is found, that value is replaced with the session user. In this event, the access of the user performing the publishing is honored. This results in the following changes to auth.properties for added reliance:
◦ A user password is no longer required to be specified as previously (see example above):
auth.siteName.publishingApplication=publishing_user_name:
The example now appears as auth.master.PROE=wcadmin (If you are using Trusted Host, a password is not required.) In this way, you can continue to specify a dedicated user for publishing applications.
◦ The username can simply be a user token value and the password value is not required. No colon delimiter is required after “$user”.
auth.siteName.publishingApplication=$user
The example now appears as auth.master.PROE=$user
During runtime of a publishing action, the $user token is replaced with the actual session user. The WVS Job Monitor shows the user who initiated the job irrespective of the worker authentication. Therefore, greater traceability is available for determining who initiated publishing. The $user is case-insensitive, and could be $USER.
This password omission and user token value replacement holds true for all publishers specified in the auth.properties file:
auth=
auth.siteName.publishingApp=
auth.siteOID.publshingApp
auth.siteName.publishingApp=
auth.siteOID.publshingApp
• User Token or Trusted Host Mode only works when the worker machine IP addresses are added as Trusted Host(s) on the Windchill server. For example, to add any client (i.e., the worker machine) as a trusted host on the Windchill server, the following property setting is added to the xconf.properties file:
<Property name="wt.auth.trustedHosts" overridable="true"
targetFile= "codebase/wt.properties"value="<Host_IP> <Host2> <Host3>">
targetFile= "codebase/wt.properties"value="<Host_IP> <Host2> <Host3>">
... where "<Host_IP>" is the IP address of the worker machine configured on the server using User Token in the auth.properties file.
 |
User Token mode is supported with or without Form-based Authentication enabled.
|
 |
Take care when using the user token $user with the configuration of username with Distributed File Server Workers. Using the $user token with a Distributed File Server Worker fetches the Preferred File Server preference value of the Runtime User, rather than a fixed preference value for a dedicated Windchill user account. This activity may result in the downloading of CAD files across the wide-area network.
See Configuring a Distributed File Server Worker for more details.
|