Security Background: ThingWorx Permissions for the eMessage Connector
The eMessage Connector requires permissions and visibility to execute services, read and write property values, and execute/subscribe to events on many entities. To connect and run effectively without administrator privileges, a User Group needs to be created and permissions granted to that user group. For example, you might create a User Group called eMessageConnectorUserGroup. The Connector will connect to ThingWorx platform using the application key of a non-administrator user that is a member of this user group.
Best Practice: Run the eMessage Connector Using a Non-Admin Application Key
The principle of least privilege is a common tenet of system security, stating that subjects should only be given the permissions and privileges necessary to do their jobs, nothing more. Applying this to the eMessage Connector means that the User referenced by the ThingWorx application key used by the Connector should have the visibility and permissions on only those ThingWorx entities that are necessary for the Connector to function properly. It is recommended that you run the Connector using an application key associated with a non-administrator User.
Best Practice: Use Caution When Granting Permissions to Users
In general, when granting visibility and permissions to Things for your end users, exercise caution. It is strongly recommended that you not grant Service Invoke permissions to users for services that can run executable programs on remote devices.
Create Security Entities
Entity visibilities are granted to an organization and permissions are granted to a user or user group. While you can configure the Connector to run with an application key that is associated with an administrator user, it is strongly recommended that you configure the Connector with an application key that contains only the required entity visibilities and permissions for a non-administrator user.
The following security entities can be created in ThingWorx Composer so that you can run the eMessage Connector with a non-administrator application key:
1. User group that will contain the non-administrator user for the Connector. This user group will be used when executing the services to grant the required permissions to the Connector. For example, eMessageConnectorUserGroup.
2. Non-administrator user to add to the eMessageConnectorUserGroup. For example, eMessageConnectorUser. This user is the eMessage Connector user presented by the Connector when communicating with the ThingWorx Platform.
3. Application key referencing the created non-administrator user. You will use this application key to set the app-key property when configuring the eMessage Connector. The Connector presents this application key when communicating with the ThingWorx Platform.
4. Organization containing the created user group. This organization will be used when executing the services to grant the Connector the required entity visibilities.
* 
The GrantRemoteAccessPermissionsGASFor(Thing|Thing Template) service creates an organization called raOrg and a user group called raGroup when it runs. Unless another organization and user group are specified when the service is run, it grants all visibility and permissions required to perform remote access operations using the Axeda Global Access Server (GAS).
Grant Required Visibility and Permissions for the eMessage Connector
* 
Before you attempt to grant visibility and permissions for the Connector, make sure that you create the security entities that are required in ThingWorx, as explained in Create Security Entities in ThingWorx for a Connector and for Remote Access.
To grant the required permissions and visibility for the eMessage Connector, you use a set of services. In addition to granting visibility to eMessage Things, visibility and permissions to the Connection Services Hub, and visibility and permissions to certain entities of the Axeda Compatibility Extension, these services provide the required permissions and visibility to the file repository on the ThingWorx Platform that the Connector will access for file downloads and file uploads. If you are planning to use the ThingWorx SCM Extension to download SCM packages to Axeda eMessage agent devices, you must grant download permissions on the file repository that is configured to hold the files that are part of packages created in the SCM application. If you are planning to use the ThingWorx Remote Access Extension, you must run services to grant all permissions and visibility required to perform Remote Access operations using Axeda Global Access Server (GAS), including running services such as StartSession, EndSession, GetSession, GetTunnel, and GetSessions on RemoteAccessible Things.
* 
The GrantEMessageConnectorPermissions service also sets the runAsUser for the AxedaPollingTimer to the eMessage Connector user. Once this service has set the runAsUser for the timer, the platform runs the timer as that user.
For v.1.3.0 of the Axeda Compatibility Package, the following permissions and visibility were added to resolve an issue with non-administrative users being able to run remote sessions:
Entity or Resource
Permissions
EntityServices resource
Visibility
RemoteViewerManagerTemplate Thing Template
Visibility
RemoteAccessSubsystem Subsystem
Runtime permission for AwaitClientPresence and ClientPresent
RemoteAccessClient Thing Template
Instance run time permission to ClientPresent
When ready, refer to Setting Up Permissions and Visibility for the eMessage Connector to create the security entities and run the services that grant visibility and permissions that the Connector requires.
Was this helpful?