We are using Windchill Authentication for Thingworx user authentication . While Windchill can authenticate the AD users and doesn't validate case sesnitivity , ThingWorx autherntication fails for user when UsernName is Uper/Lower Caaase . Example: if AD user name is xyz.pqr , User can login and authenticated to Windchill with any user name ( Xyz.Pqr/ xyz.pqr) . However, in Thingworx user can't get Authenticated with Xyz.Pqr
We've yet implemented SSO and using Windchill 12.0.2 with TWX -9.3.
I kow other enterprises who are using Thingworx extensively with 1000s of concurrents users logging into system . Anyone can help , how to do an User Management in ThingWorx and navigate ?
Solved! Go to Solution.
We solved this by implementing a lowercase rule in shibboleth on the windchill side. Yes, we had the same issue as described where users typed with mixed case and it fouled up Windchill. Windchill did not care but I was constantly deleting accounts in Thingworx and pre-creating good ones with all lowercase. We added the following to our shibboleth2.xml file:
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
<!-- Adding Attribute Resolver to try and fix username case issue -->
<AttributeResolver type="LowerCase" source="uid"/>
From what IT told me, same could have been done on the IDP side in Azure. What we noticed without this is that the case how they were entered in Azure is how the uid would come across so it was out of our and the user's control. I did not want to force IT to go out and lowercase all entries in AD. This seems to have solved it.
From "Help Center" - "ThingWorx Authentication Deployment": https://support.ptc.com/help/thingworx/platform/r9.6/en/index.html#page/ThingWorx/Help/Installation/DeploymentArchitecture/thingworx_authentication_deployment.html
Hi @vijayaRath,
I wanted to see if you got the help you needed.
If so, please mark the appropriate reply as the Accepted Solution. It will help other members who may have the same question.
Of course, if you have more to share on your issue, please pursue the conversation.
Thanks,
Anurag
No, the case sensitivity is the reason we have not been able to roll this out very widely to our userbase. Thingworx creates a seperate account for every seperate case of a name, e.g. Joe.Bloggs/joe.bloggs/Joe.bloggs/joE.bloggs, which is absolutely terrible functionality. Makes it impossible to manage user accounts, especially as an user must first log in before you can assign their user to any roles.
SSO is supposed to work around this issue, but is appears to be difficult to implement and is very dependent on your local IT infrastructure
Yes, Windchill's username is case-insensitive whereas ThingWorx's username is case-sensitive, this is by product design and currently, there's no plan to change that. Refer to article https://www.ptc.com/en/support/article/CS230846
Implementing SSO for ThingWorx seems to be the only workaround.
For example, as far as I'm concerned when sign-in to Entra ID, the case of the username - UPN entered is not validated.
And, you can transform the claim in the SAML response to ThingWorx - to all lower case for example to ensure no duplicated user account is created in ThingWorx.
Respectfully, this is a disastrously stupid decision.
This means rolling out Thingworx Navigate with Windchill is IMPOSSIBLE without SSO.
SSO instructions are not excellent and possibilities for SSO are restricted by organisational architecture.
The fact that users have to be managed in Thingworx, but they don't exist until they login for the first time is a problem on its own.
But then this is complicated by users logging in a second time using a different case of username, and are then stumped when their TW session is empty or does not have the correct content!
Having to manage duplicate users like this for potentially hundreds of users is a complete nightmare.
You also mention MS Entra ID, where OP mentions AD. These are not the same, and AD SSO is non-trivial as far as I understand.
It's probably possible using ADFS?
We solved this by implementing a lowercase rule in shibboleth on the windchill side. Yes, we had the same issue as described where users typed with mixed case and it fouled up Windchill. Windchill did not care but I was constantly deleting accounts in Thingworx and pre-creating good ones with all lowercase. We added the following to our shibboleth2.xml file:
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
<!-- Adding Attribute Resolver to try and fix username case issue -->
<AttributeResolver type="LowerCase" source="uid"/>
From what IT told me, same could have been done on the IDP side in Azure. What we noticed without this is that the case how they were entered in Azure is how the uid would come across so it was out of our and the user's control. I did not want to force IT to go out and lowercase all entries in AD. This seems to have solved it.