Using PingFederate as a Central Auth Server
The PTC product platform SSO solution uses PingFederate that acts as the Central Auth Server (CAS) to manage SSO-enabled products. Thus, a user is able to access data from their application, and use it in their session in ThingWorx.
In the ThingWorx SSO architecture, ThingWorx sends SAML requests for user authentication to the CAS, and the CAS redirects the authentication request to your enterprise identity provider (IdP), which verifies the authenticity of the user credentials. In this SAML transaction, the CAS does not handle user credentials. The IdP sends a SAML assertion to the CAS that the user credentials are valid, and the CAS then sends an assertion to ThingWorx authorizing the user login.
The CAS is also used to manage the trust relationship between ThingWorx and resource servers that ThingWorx retrieves data from. The CAS generates access tokens that ThingWorx includes in requests for data from resource providers. Resource servers rely on the CAS to verify the authenticity of the access tokens. This scenario is called delegated authorization because the user is authorizing ThingWorx to obtain their data from a resource server. The access tokens exchanged between ThingWorx, PingFederate, and other PTC products use the OAuth protocol.
Before you proceed, make sure you read through the PTC Identity and Access Management Help Center. This Help Center provides an overview of single sign-on and related terminologies as well as detailed information on installing, upgrading, and configuring PingFederate. It also provides examples of single-sign on configurations, such as the following:
PingFederate as the IdP and Windchill DS as the Data Store
Implementing SCIM with PingFederate as the CAS, ADFS as the IdP, and Windchill as the Resource Server
Windchill SSO Implementation with PingFederate as Broker
Was this helpful?