Troubleshooting Single Sign-on
Enable event logging to troubleshoot SSO-related problems. To enable logging, use a standard logback.xml file in the ThingworxPlatform directory. If a logback.xml file exists in this location, you can simply add the SSO loggers to the existing set of loggers. For more information on the logback.xml file, see Configuring logging.
The logback.xml functionality is a Java standard. For instructions about configuring these files, refer to Java documentation.
The following table provides information about the logger packages that can be added to help you investigate problems related to your SSO configuration of ThingWorx:
Package
Description
com.thingworx.security.authentication.sso
Package for all ThingWorx SSO Authentication components. The following examples are entries in the logger packages:
For messages that go to the application log, for example:
LogUtilities.getInstance().getApplicationLogger([class name]):
<logger name="com.thingworx.security.authentication.sso" level="DEBUG"/>
Security loggers are used in many classes in this package. For example:
LogUtilities.getInstance().getSecurityLogger(ThingworxSSOAuthenticator.class);
To turn on these loggers, add SecurityLog as the root parent logger:
<logger name="SecurityLog.com.thingworx.security.authentication.sso" level="DEBUG"/>
SecurityLog.com.thingworx.security.sso
Package for delegated authorization work flows used by Integrated Connectors when getting access tokens and their configurations.
com.thingworx.ptc.eauth.identity
Package for all PTC core SSO library components.
com.springframework.security
Package for all spring framework security components.
com.springframework.jdbc
Package for all spring framework JDBC authentication components.
The following troubleshooting items can be investigated if your SSO implementation is causing errors.
Problem
ThingWorx administrator cannot sign in — Invalid_scope error received
Description
After signing in, the user is redirected to a ThingWorx error page, stating that the system is currently encountering an authentication configuration error.
Solution
One or more of the scopes registered in a ThingWorx Integration Connector or a media entity do not match the scopes registered in PingFederate (or your chosen CAS). This mismatch of scopes between PingFederate can cause the ThingWorx administrator to be locked out. The resource provider scopes that have been registered in ThingWorx can be viewed in the security log. To resolve this:
1. Log in to PingFederate and compare the reported scopes from the ThingWorx security log with the scopes that are registered PingFederate. For any scopes in ThingWorx that are not registered in PingFederate, or have mismatched names, add the scope in PingFederate or modify the name to match the spelling in ThingWorx (even if this is not the correct spelling of the scope).
2. Now, the grants approval page functions correctly, and you can sign in to ThingWorx as administrator. In ThingWorx Composer, navigate to the Integration Connector or media entity that is trying to use the scope. Remove it from the scopes registration table for the Integration Connector or media entity. Log in with a new session of ThingWorx to verify that login is successful.
3. When ThingWorx was trying to use a scope that was not registered, in PingFederate, remove the unwanted scope from the scope management page. When the scope names were mismatched, delete the scope, and register it again with the correct spelling in PingFederate, and in the ThingWorx Integration Connector or media entity.
Problem
Service on an Integrated Connector or Media Entity does not work – Failed to retrieve access token.
Description
You are logged in to ThingWorx Composer and already have an access token. You imported or created a connector with a scope and attempted to execute a service on the connector, and it did not work.
Solution
Log out and log in to open the grant approval page for the scopes for your connector. You need to approve the newly registered scope grant for the services to work.
The same is true if you are importing or creating media entities that contain scopes.
Problem
SSO Context and Bean initialization errors at ThingWorx startup.
Description
ThingWorx fails to start up.
Solution
Refer to the error logs to determine the problem. The text at the end of the context or bean initialization warning or error log describes the problem. For example, a possible error could state:
SSOConfigurationException: BasicSettings > idpMetadataFilePath cannot be null or empty
Check the value of the idpMetadataFilePath parameter in the sso-settings.json file and add the appropriate value.
Problem
The ThingWorx mashup or application does not load after the user clicks Don’t allow for the requested scopes on the Request Grant Approval page from PingFederate.
Description
After clicking Don’t allow on the Request Grant Approval Page, the mashup does not load, and the browser URL ends with a hash “#” and period “.”.
Solution
By default, PingFederate uses a period “.” as a fragment placeholder, which causes this issue to occur. To resolve this, do the following:
1. In the PingFederate install location, navigate to <PingFederateInstallation>\server\default\data\config-store\sanitize-fragments.xml.
2. Edit this XML file and remove the period “.” from fragment placeholder. The line should be as follows: <con:item name="FragmentPlaceholder"></con:item>
3. Restart the PingFederate server.
Problem
SAML authentication against http://<your server>:<port>/Thingworx/runtime/index.html#mashup=<MyMashup> redirects to http://<your server>:<port>/Thingworx/runtime/index.html after successful login.
Description
During a login against a mashup URL, the fragment part of the URL (that is, #mashup=<MyMashup>) is not sent to the ThingWorx server or the Authentication server for a proper redirect after a successful login because the browser keeps that data for use by the client only. Thus, the ThingWorx server and the Authentication server receive the URL without the fragment, that is, http://<your server>:<port>/Thingworx/runtime/index.html.
Solution
For mashup URLs that are used as the initial authentication point, construct the URLs with query parameters instead of fragment parameters.
Thus, in this case, use this URL: http://<your server>:<port>/Thingworx/runtime/index.html?mashup=<MyMashup>.
Was this helpful?