|
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.
|
|
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
|
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 CAS is configured AzureAD and the end-user cannot get data from the resource server (RS) using ThingWorx connectors based SSO connection type ( as for 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.
|