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:
More use cases can be found at IAM support site.
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 server 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>.
Problem
Every single login shows Request Grant Approval page from PingFederate.
Description
PingFederate does not return scopes upon successful grants approval process.
Solution
On PingFederate:
1. Create or edit the oauth-scope-settings.xml file that is available in the <PingFederate Installation Folder>/server/default/data/config-store locations as follows:
<?xml version="1.0" encoding="UTF-8"?>
<z:config xmlns:z="http://www.sourceid.org/2004/05/config">
<z:item name="always-return-scope-for-authz-code">true</z:item>
</z:config>
2. Restart PingFederate.
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>.
Problem
The following error is displayed in the server.log file of PingFederate:
ERROR [SpringLdapGuidFormatter] Decoded binary guidAttribute is empty. Please check that the source datastore is configured with 'objectGUID' as a binary attribute. [] Channel: channel1
Description
Due the changes in PingFed 11.3 the SCIM needs to be configured manually.
Solution
Follow the steps mentioned in Add LDAP Binary Attributes.
Problem
When AzureAD is configured as CAS, the end-user cannot get data from the resource server (RS) using a SSO connection type that is base on ThingWorx connectors (as the access token is expired).
Description
SecurityLog.log file displays the following error.
ERROR: [ Failed to retrieve access token. ][ A redirect is required to get the users approval ]
Solution
set property mandatoryScopes in AuthorizationServersSettings in sso-settings.json to include offline_access.
Was this helpful?