Provisioning Methods
Active Directory Provisioning
If you are using fixed authentication with Active Directory, configure user provisioning from the directory service. For more information, see Managing Users in Active Directory.
ThingWorx SSO Authenticator Provisioning
If you enabled Single Sign-On (SSO) authentication, by ThingworxSSOAuthenticator, provisioning is automatically enabled. User attributes are retrieved through from the authorization server , for example PingFederate, that acts as the broker between ThingWorx and the identity provider. This is considered “just-in-time” provisioning, because user accounts are created (if they don’t already exist in ThingWorx) and updated when a user logs in to ThingWorx. User attributes are included in the Identity provider response used to authenticate. Work with the IdP administrator to understand the user, and to ensure that the user account in ThingWorx is updated at the time of the login event. Out of the box, ThingWorx only consumes the username attribute to create the user. Any additional attributes that you want consumed must be configured in the authorization server, so they are passed in the Identity provider response, and then mapped to the user extension properties.
Additional configuration are required to manage the provisioning settings used with this method. For more information, see Single Sign-on Authentication.
In ThingWorx, ThingworxSSOAuthenticator provisioning can only be used to create and update user accounts; it cannot delete.
If using Microsoft Entra ID to implement SSO capabilities, see Microsoft Entra ID as the CAS and IdP in the PTC Identity and Access Management help center.
If using AD FS to implement SSO capabilities, see AD FS as the CAS and IdP in the PTC Identity and Access Management help center.
SCIM Provisioning
SCIM is an automated method that synchronizes changes to user accounts in the identity provider to be pushed to the user accounts in ThingWorx. SCIM provisioning can be enabled to supplement the SAML provisioning settings configured with SSO authentication. SCIM provisioning can also be enabled, or it can be enabled independently of SSO authentication. Instead of the just-in-time updates to user accounts that occurs with SAML provisioning, SCIM automation means that changes to user accounts are auto-provisioned to ThingWorx based on changes to the user account in the identity provider.
To configure SCIM provisioning, refer to the following topics.
SCIM
Using Both SCIM and SAML Provisioning
If you are using both SAML and SCIM provisioning, the configurations for both must be aligned, so they consume user attributes in a logical fashion. For example, confirm that ThingWorx and IdP groups are mapped the same way in the ThingworxSSOAuthenticator and the SCIM Subsystem. If a group that a user belongs to in the IdP is mapped to different ThingWorx groups in the SCIM Subsystem and the ThingworxSSOAuthenticator, the user can be added to different ThingWorx groups when the user account is updated based on SCIM or SAML provisioning.
Refer to Create a Channel to the Data Store for a list of ThingWorx user extension properties that are mapped to SCIM 1.1 schema resource types. When configuring SAML provisioning in the ThingworxSSOAuthenticator, the User Extension Provision Names table maps user metadata values that are passed from SAML attributes to ThingWorx user extension properties. When using both SCIM and SAML provisioning, you must ensure for each of the user metadata values that are retrieved from the IdP, there is a corresponding SAML attribute mapping configured in the ThingworxSSOAuthenticator User Extension Provision Names table. If the user extension metadata is not mapped in the ThingworxSSOAuthenticator; when the user logs in and SAML provisioning occurs, that user extension value is cleared because no value for that user extension is retrieved from the SAML assertion.
Using the appropriate sections below, configure the ThingWorx UserExtension object to match the attributes you configured in the CAS to be provisioned:
If PingFederate is the CAS
1. Work with the IdP administrator to understand what user metadata is returned for each SCIM 1.1 schema resource type listed in Create a Channel to the Data Store.
2. Coordinate with your PingFederate administrator to ensure that the same user metadata is mapped to SAML attributes that are included in the assertion returned to ThingWorx when the user logs in.
3. Configure the ThingworxSSOAuthenticator User Extension Provision Names table to map the appropriate SAML assertion value to the corresponding user extension properties that are provisioned from the corresponding SCIM schema resource type.
If Microsoft Entra ID is both the CAS and the IdP
To list the user attributes in Microsoft Entra ID, select your enterprise application and navigate to Provisioning > Mappings > Provision Azure Active Directory Users > Attribute Mapping. For more information, see the ThingWorx to SCIM Mappings table.
In ThingWorx
Ensure that each of the user attributes stored in the IdP, that you want to provision to ThingWorx, is listed in the CAS to be provisioned.
Was this helpful?