Configuring the Central Auth Server – PingFederate
PTC supports PingFederate as the Central Auth Server (CAS). The CAS manages the trust relationship between PTC products participating in the SSO framework. The CAS acts as a broker between applications by authorizing user logins, once the user has been authenticated, and by issuing and verifying access tokens that are exchanged between service providers and resource servers.
PTC products implement the following elements in the SSO framework:
1. Use SAML assertions to authenticate users with the IdP.
2. Then, after the user has been authenticated, PingFederate presents the user with a grants approval page where it asks the user if they want their data from the resource server to be shared with the application they are using.
When working with PingFederate, you should review PingFederate documentation. The following are some general tips you should consider when deploying PingFederate:
• Review the maximum time that a user login session is valid and consider if the same values should be used in each of the applications participating in your SSO solution.
• Confirm that systems are working within an acceptable time skew tolerance. If one or more system clocks are out of sync with the CAS, and it exceeds the skew tolerance time set in the systems, then the configuration will throw errors and prevent users from being authenticated.
Federated Authentication
Federated authentication is the process of validating a user’s login request by comparing it with the credentials stored in the identity provider.
In the PTC product SSO architecture, PingFederate does not directly authenticate user logins. Instead, PingFederate should be configured to redirect user login requests to your enterprise IdP. The IdP verifies the authenticity of the user login credentials and sends an assertion to PingFederate that the user has been authenticated. Then, PingFederate sends an assertion to the requesting application that the user has been authenticated and authorizes the user login. Throughout this transaction, PingFederate does not handle the user credentials; when the browser is redirected to the IdP, the exchange of username and password information occurs directly between the user client agent (browser) and the IdP. You must create a separate service provider connection for each PTC product that routes user authentication through PingFederate.
In the following example, ThingWorx is the service provider, and PingFederate is the CAS. ThingWorx uses the open standard SAML 2.0 protocol for authentication exchange between the service provider and identity provider.
The authentication process is as follows:
1. The user attempts to access the service provider.
2. The service provider generates a SAML request for the user and sends the request to the CAS.
3. The CAS redirects the SAML request to the IdP.
4. The IdP redirects the user to an authentication page to provide their credentials (e.g. user name and password). Once the user has entered their credentials, the IdP generates a SAML response. If the user is successfully authenticated, the SAML Response will include a SAML Assertion which contains the user’s authorization.
5. The IdP then redirects the response to the CAS.
PTC provides automation scripts for PingFederate configuration with PingFederate as the IdP. For more information, see Configuring PingFederate as the Central Auth Server automatically.
For third-party IdPs, you must configure PingFederate in the SSO setup. For more information, see Configuring authentication for third-party IdPs manually.
Delegated Authorization
Delegated authorization is a concept that allows a service provider to take actions or access resources from a Resource Server (RS) on behalf of a user, without the user sharing their credentials with the RS.
PingFederate generates OAuth 2 access tokens that PTC products include in requests for data from resource servers. Resource servers rely on the CAS to verify the authenticity of the access tokens. You need to create separate OAuth clients for each of the PTC applications participating in delegated authorization scenarios.
PTC products further protect resources that are protected by OAuth by configuring scopes as an additional protective measure. When a service provider sends an access token along with its request for data from the resource server, the access token must also have a scope attached that is registered against the data in the resource server. For more information, see Managing Scopes in Delegated Authorization.
In the following example, ThingWorx is the service provider, PingFederate is the CAS, and Windchill is the resource server. ThingWorx uses the open standard OAuth2 protocol to authorize a service provider to access resources in a secure, reliable, and efficient manner.
The authorization process is as follows:
1. After receiving the SAML response from the IdP, the CAS sends a grant authorization request page for the user to approve. The CAS uses the grant authorization request page to get authorization to generate an OAuth code.
2. After the user grants access, the CAS generates an OAuth authorization code. The CAS then redirects the SAML response and authorization code to the service provider.
3. Once the service provider receives the OAuth authorization code, it requests an access token and refresh token from the CAS, using the authorization code.
4. The CAS validates the authorization code and generates an OAuth access token and refresh token. The CAS then sends both tokens to the service provider.
5. The resource owner (typically the user) requests content from the service provider that requires data from the resource server.
6. The service provider requests content from the resource server on behalf of the resource owner using the access token.
7. The resource server verifies the access token with the CAS.
8. The resource server then obtains the requested content and sends it to the service provider.
9. After receiving the content, the service provider delivers it to the resource owner.
You can also implement SSO architecture with multiple resource servers. In the example, ThingWorx Navigate is the service provider and Windchill and SAP are the resource servers.
