Single Sign-on Authentication
Windchill can be configured to participate in single sign-on (SSO) user authentication using either SAML or Open ID Connect protocol. Only one SSO authentication protocol can be configured for a single Windchill system. In addition, Windchill supports use of OAuth 2.0 to secure access to protected Windchill resources from a client through Windchill Rest Services (WRS). In this configuration, Windchill acts as a resource server. It is recommended to ensure that if SSO authentication is configured for Windchill users, client authentication is configured using the OAuth 2.0 token-based capabilities (do not configure different authentication methods across different clients).
 |
Multi factor authentication (MFA) is configured in the Identity Provider and is not managed by the Windchill application. You are required to implement MFA through your IdP as per your requirement; PTC is not responsible for this implementation.
|
For SAML authentication, PTC supports using Shibboleth Service Provider as a SAML client that is configured on the PTC HTTP Server to direct Windchill user authentication to a trusted identity provider. For more information, see Security Assertion Markup Language (SAML) Authentication.
For Open ID Connect (OIDC) authentication, Apache will provide the necessary support of the protocol through Windchill configuration. For more information, see OpenID Connect Authentication Support.
If you have configured either SAML or OIDC authentication for Windchill and your site uses electronic signatures as part of its workflow process, then you can optionally configure the system to require users to provide their credentials before submitting an electronic signature. For more information, see eSignature Validation for SSO Configurations and eSignature Validation for SSO with OIDC.
When a client application is accessing Windchill using OAuth 2.0, the OAuth token must be obtained using a standard OAuth grant flow. Windchill supports both the Client Credentials flow for non-interactive clients (M2M) and the delegated authorization code flow for interactive clients. Applications or mashups built on the ThingWorx platform will use the delegated authorization code flow. If the user grants the application permission to access their Windchill data, then the application will present an access token to Windchill when requesting data owned by the user. PTC products affix scopes to access tokens to further protect and manage access to resources. In Windchill, scopes must be registered in the securityContext.properties file. For more information, see Establish a Central Authorization Server and Configure OAuth Delegated Authorization.
For SSO configurations, PTC specifies using PingFederate as the central authorization server (CAS) to manage the trust relationship between PTC products participating in an SSO federation and authentication session management. The CAS issues access tokens and verifies their authenticity to trusted applications. For PingFederate installation instructions, refer to PingFederate help documentation provided by Ping.
|
|
PTC no longer provides PingFederate product or licenses on the PTC downloads page. Beginning April 1, 2022 new PTC products entitlements will not include a PingFederate license by default. New customers choosing to use PingFederate must contract directly with PingIdentity to purchase a PingFederate license. PTC customers, who were previously entitled prior to April 1st, 2022, can still request a PingFederate license by contacting PTC Technical Support, this includes requests for license renewals.
PTC Cloud customers will be provided a PingFederate license if required, as part of the provided PTC offering.
|
It is possible to configure Windchill to use both SAML authentication and OAuth (delegated authorization or client credentials) these scenarios are not exclusive of the other. If you have enabled OAuth delegated authorization using PingFederate as the CAS, you can optionally use PingFederate as an identity provider (IdP) in the SAML authentication scenario. You also have the option of using a different IdP in your SAML configuration, and using PingFederate as the CAS in the OAuth configuration. Optional configuration instructions for using PingFederate as an IdP are included in Security Assertion Markup Language (SAML) Authentication.
For a full description of supported SSO use cases and the configuration steps required for setting up an SSO federation between PTC products, refer to the PTC Product Platform Single Sign-on Guide.