Thingworx 9.6.1 SSO issue

[EM_10066743]

Hi, we use Thingworx 9.5.1 With SSO login and that works good , all parameters for reverse proxy we implemented like in the CS : CS327279 - "Incoming SAML message is invalid" "Endpoint with message binding <Binding> and URL <URL> wasn't found in local metadata" is logged in the SecurityLog when authenticating to ThingWorx Platform with Single Sign-On (SSO) enabled 

Now we upgraded in our DTA to 9.6.1 , with LDAP all works fine, when we test with SSO then the application returns the HOME URL in HTTP://Thingworx/Runtime/index.html?mashup=MSU.Mainmashup=MSU.Main and lands in a Loop to go to a https url,  Where 9.5.1 returns the URL Relative like this

 //Thingworx/Runtime/index.html?mashup=MSU.Main. Does anyone has an idea?

[TonyZhang]

Hi @EM_10066743,

Could you please elaborate on the issue you are facing? It'd be ideal if you could provide some screenshots to demonstrate the issue replication steps.

Also, could you please provide your sso-settings.json and idp metadata?

[EM_10066743]

root@f24dce9dd7f4:/ThingworxPlatform/ssoSecurityConfig# cat sso-settings.json
{
"BasicSettings": {
"clientBaseUrl": "https://xxx.xxx.nl/Thingworx",
"idpMetadataFilePath": "/ThingworxPlatform/ssoSecurityConfig/sso-idp-metadata.xml",
"metadataEntityId": "xxx-Thingworx-xxx",
"metadataEntityBaseUrl": "https://xxx.xxx.nl/Thingworx",
"webSSOProfileConsumerResponseSkew": "300",
"webSSOProfileConsumerReleaseDOM": "true",
"webSSOProfileResponseSkew": "300",
"retriggerOnScopesRemoval": "true",
"samlAssertionUserNameAttributeName": "uid",
"samlAssertionMaxAuthenticationAge": "77760000"
},
"ApplicationKeySettings": {
"enabled": true
},
"SAMLContextProviderSettings": {
"scheme": "HTTPS",
"serverName": "xxx.xxx.nl",
"serverPort": "443",
"includeServerPortInRequestURL": "false",
"contextPath": "/Thingworx"
},
"AccessTokenPersistenceSettings": {
"dbType": "postgres",
"driverClassName": "org.postgresql.Driver",
"url": "jdbc:postgresql://postgresql:5432/thingworx",
"username": "thingworx",
"password": "xrowgniht",
"encryptTokenInDatabase": "false",
"keyczarKeyFolderPath": "/ThingworxPlatform/ssoSecurityConfig/symmetric/"
},
"KeyManagerSettings": {
"keyStoreFilePath": "/ThingworxPlatform/ssoSecurityConfig/sso-keystore.jks",
"keyStoreStorePass": "thingworx",
"keyStoreKey": "thingworx",
"keyStoreKeyPass": "thingworx"
},
"AuthorizationServersSettings": {
"AzureSSO-1": {
"clientId": "f2b1bfd4-61a6-4e5d-a10e-xxxx",
"clientSecret": "8eb8Q~zZ6behnxxxx~fTLwWGpHLSv_xxx",
"authorizeUri": "https://login.microsoftonline.com/339333e1-b5c5-410a-8b9e-xxx/oauth2/v2.0/authorize",
"tokenUri": "https://login.microsoftonline.com/339333e1-b5c5-410a-8b9e-xxx/oauth2/v2.0/token",
"clientAuthScheme": "form"
}
}
}

[EM_10066743]

Hi Tony, Thank you for your reply, hereby some additional information.

[EM_10066743]

Here a screenshot from Devtools, this is how it is on Thingworx 9.5.1 where SSO Work fine, we get the Relative URL seen at Location /Thingworx/Runtime ........ In our 9.6.1 version we do get http://Thingworx/Runtime..... here, and than it returns to MS login again...

[TonyZhang]

Hi @EM_10066743,

I'm afraid I'm still not clear about what exactly the issue is here.

It appears your login URL contains OrganizationName parameter and I'm guessing the reverse proxy, Nginx is redirecting users to the mashup page according to the Organization? 

Can you please try login using the URL -  https://xxx.xxx.nl/Thingworx exactly the one you configured as clientBaseUrl in sso-settings.json without adding any additional path or parameters at the end of the url?

And you can configure Home Mashup for the users in ThingWorx to redirect users to home mashup upon login.

If that doesn't work, I'd suggest you open a support case as a deeper investigation seems to be required to understand your situation and collect logs, configuration, SAML trace etc for further troubleshooting.

I can help you to create a support case using your e-support account on your behalf if you wish.

[EM_10066743]

Hi @TonyZhang ,

When we go to the clientBaseUrl directly in the browser the result is the same, the browser will go from SSO  to Home?OrganizationName=xxx to SAML2?SAMLrequest........etc back to SSO and the loop continues this on and on.........