SAML 2.0 authentication can be integrated into Windchill to enable participation in a federated single sign-on solution. This topic presumes you have prerequisite knowledge of the SAML 2.0 specification. For more information, refer to the SAML v2.0 documentation published by the OASIS Security Services Technical Committee, available at https://www.oasis-open.org/standards#samlv2.0.

The Windchill authentication strategy relies on the web server to enforce authentication. The following procedure describes an integration that PTC tested using Shibboleth Service Provider 2.6.0 with PTC HTTP Server to confirm Windchill compatibility with SAML. This was tested under specific conditions and is provided as an example configuration. Each site will have unique methods of implementing SAML. The selection of a SAML service provider is up to each customer. PTC has only tested and verified the suitability of Shibboleth Service Provider and does not make any warranty about the suitability of other SAML service providers. PTC does not directly support the setup or configuration of a SAML service provider. For assistance configuring the SAML service provider that you select, refer to that product’s documentation or customer support. This procedure does not address how to establish or configure an identity provider within your federation. Refer to OASIS or Shibboleth documentation for information about establishing an identity provider, or consult with your identity provider administrator.

Most single sign-on solutions use the SAML Web Browser SSO Profile. In this scenario, there are a minimum of three roles.

These roles, and others, are described in more detail in the OASIS SAML v2.0 documentation. The following graphic depicts the authentication process between these roles.

It is possible to configure an identity provider as a service provider to other identity providers. When this procedure refers to an identity provider, it is only referring to the identity provider that the service provider must communicate with directly, not any additional federated identity providers.

The following steps are required to enable SAML capabilities for Windchill using Shibboleth Service Provider 2.6.0.

The Shibboleth Daemon log files are located in <shibboleth_install>/var/log/shibboleth. These log files require root access to read on Linux. If you want to switch to a different location: the HTTP server, Shibboleth module log files are in <install_directory>/var/log/shibboleth-www. On Linux, this directory is not writable by a non-root user. PTC HTTP Server usually runs as a non-root user if you are not attempting to run the web server on port 80. When this happens, the log files will not be created. The log file location can be changed by modifying /etc/shibboleth/native.log. Change the following two properties to a writable location:

For example, you could create the following directory /opt/ptc/logs. and set the properties to use log files in that directory.

To enable debug logging:

Edit /etc/shibboleth/native.loggger and change the rootCategory loglevel to DEBUG. (log4j.rootCategory=INFO, native_log, warn_log becomes log4j.rootCategory=DEBUG, native_log, warn_log). This will greatly increase the verbosity of both the Shibboleth Daemon and shibboleth module and the native files from /var/log/shibboleth-www or wherever you place them.

The Shibboleth Service Provider contains two components: a Shibboleth Daemon and the module in PTC HTTP Server. When restarting either, both services need to be restarted. On Windows, the Shibboleth Daemon is configured as a Windows service and can be restarted via the services control panel. On Linux it is a shibd.service systemd unit and can be stopped and started using systemctl. See Starting the HTTP Server and the Windchill Method Servers for details on starting and stopping PTC HTTP Server.

The embedded browsers for Creo Parametric and Windchill Workgroup Manager are unable to use the login cache from the Windchill session in the primary browser. Because of this, a single sign-on experience cannot be fully created as users may see an additional login request from embedded browsers for Creo Parametric and Windchill Workgroup Manager. The embedded browsers will authenticate the users with the identity provider designated in your SAML configuration.

If Servigistics Arbortext Editor is part of your PTC solution, there are additional considerations for configuring SAML at your site. For more information, see https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS250036.

Configuring some clients for SAML authentication is unsupported. Before you implement SAML authentication at your site, you should examine the extent to which these clients are used at your site and whether these client exclusions are an impediment to using SAML authentication. PTC does not support SAML authentication configurations for the following clients:

For up-to-date information about client compatibility with SAML authentication, refer to the following article: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS250038.

The following steps provide guidance on configuring a connection between PingFederate and the Shibboleth SP installation on your Windchill server. This is an optional configuration and is not required to enable SAML authentication in Windchill. You may choose to use a different IdP in your SAML deployment, depending on the requirements of your enterprise SSO federation. For more information about downloading a supported version PingFederate and obtaining a license, see Single Sign-on Authentication.

These steps supplement the instructions found in the preceding SAML configuration topic and assumes that PingFederate and Shibboleth Service Provider are already installed. The configuration steps for PingFederate as IdP and Shibboleth Service Provider are interdependent, and so you’ll need to update the configuration for each client to import the metadata XML file that is exported from the other client.