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.
SAML Provisioning
If you enabled Single Sign-On (SSO) authentication, SAML provisioning is automatically enabled. User attributes are retrieved through SAML assertions from the authorization server (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 SAML assertion 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 SAML assertion, and then mapped to the user extension properties.
Additional configurations are required to manage the provisioning settings used with this method.
In PingFederate, you create a policy contract for the SP connection that ThingWorx uses to connect to PingFederate. The policy contract is where you map the attributes to be passed from the identity provider to ThingWorx. For more information, see Create PingFederate Connections.
In ThingWorx, configure the ThingworxSSOAuthenticator entity to specify settings for provisioning users and user attributes. For more information, see Single Sign-on Authentication.
In ThingWorx, SAML provisioning can only be used to create and update user accounts; it cannot delete.
If using Azure AD to implement SSO capabilities, see Azure AD 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.
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 Azure AD is both the CAS and the IdP
To list the user attributes in Azure AD, 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?