User role mapping fails for AD groups in asset-tracking module after SSO upgrade (twx-97)

IoT PTC ThingWorx
, , , , , , , ,
1

After upgrading our SSO implementation to support SAML 2.0 in ThingWorx 9.7, users in certain AD groups are losing access to the asset-tracking dashboards. The SSO authentication works fine - users can log in successfully - but their roles aren’t being mapped correctly, resulting in loss of dashboard access.

Before the upgrade, we were using a simpler authentication method and role assignments worked perfectly. Now users from the “AssetOperators” and “MaintenanceTeam” AD groups can authenticate but get access denied errors when trying to view asset dashboards.

SSO configuration snippet:

<AttributeStatement>
  <Attribute Name="memberOf">
    <AttributeValue>CN=AssetOperators,OU=Groups,DC=company,DC=com</AttributeValue>
  </Attribute>
</AttributeStatement>

I suspect the issue is with how the SSO group claim format is being parsed, or maybe our role mapping rules need adjustment for the new SAML format. Has anyone dealt with AD group membership mapping issues after upgrading SSO?

2

Thanks, that makes sense. Where exactly do I configure the role mapping rules in ThingWorx? Is this in the SSO configuration subsystem or in the Organizations/Users section?

3

Check your SAML attribute mapping configuration in ThingWorx. The memberOf attribute format from AD includes the full distinguished name, but ThingWorx might be expecting just the group name. You may need to configure attribute transformation rules to extract the CN value from the full DN.

4

I’ve implemented SSO role mapping for several ThingWorx deployments and dealt with this exact issue multiple times. Here’s the complete solution:

Understanding the Problem: The issue is a mismatch between the SSO group claim format (full DN from AD) and ThingWorx role mapping rules (expecting simple group names). When SAML sends “CN=AssetOperators,OU=Groups,DC=company,DC=com”, ThingWorx is looking for “AssetOperators”.

SSO Group Claim Format Configuration: You have two options for fixing the format mismatch:

Option 1: Configure IdP to send simplified group names

  • In your SAML IdP (Okta/Azure AD/etc.), configure attribute transformation
  • Extract CN value from memberOf attribute before sending
  • Send only “AssetOperators” instead of full DN

Option 2: Configure ThingWorx to parse full DN format

  • Update role mapping rules to use regex pattern matching
  • Extract CN value from full distinguished name
  • This is more flexible but requires careful regex configuration

Role Mapping Rules in ThingWorx: Navigate to System > Authenticators > your SSO authenticator

Configure role mapping rules:

<RoleMapping>
  <Rule pattern="CN=AssetOperators,.*" role="AssetOperator"/>
  <Rule pattern="CN=MaintenanceTeam,.*" role="MaintenanceTech"/>
</RoleMapping>

The pattern uses regex to match the full DN and maps to the corresponding ThingWorx role.

AD Group Membership Verification: Before implementing fixes, verify the SAML assertion content:

  1. Open browser dev tools (F12)
  2. Go to Network tab
  3. Complete SSO login
  4. Find the SAML response POST request
  5. Decode the SAMLResponse parameter (base64)
  6. Verify memberOf attributes are present

Composer Permission Settings: After fixing role mapping, verify that the mapped roles have correct permissions:

  1. Navigate to Organizations & Users > Roles
  2. Find AssetOperator and MaintenanceTech roles
  3. Verify they have visibility permissions for asset-tracking mashups
  4. Check Runtime permissions for data streams and things
  5. Ensure ServiceInvoke permissions for asset-tracking services

Role Inheritance Considerations: ThingWorx supports role inheritance, which can affect permissions:

  • If AssetOperator inherits from a base role, ensure that inheritance is configured
  • Check for permission conflicts between inherited and directly assigned permissions
  • Test with a single user first to validate complete permission chain

Testing and Validation:

  1. Clear user session cache (logout completely)
  2. Log in with test user from AssetOperators AD group
  3. Verify user object shows correct role assignment in Composer
  4. Test access to asset-tracking dashboards
  5. Check ApplicationLog for any permission denial messages

Common Gotchas:

  1. Case sensitivity: Group names in SAML are case-sensitive, ensure exact match
  2. Nested groups: AD nested group memberships may not be included in SAML by default
  3. Token refresh: Role changes don’t take effect until user logs out and back in
  4. Permission propagation: New role assignments can take a few minutes to propagate

Implementing these changes should restore dashboard access for your AD groups. The key is ensuring consistent format between what SAML sends and what ThingWorx expects in role mapping rules.

5

I’ve seen this before. The problem is usually that ThingWorx role mapping rules are looking for a specific group name format, but SAML is sending the full DN. You need to update your role mapping configuration to either parse the DN or configure your IdP to send just the group names instead of full distinguished names.