Security and the eMessage Connector
Application keys and token authentication are used to secure communications between:
The eMessage Connector and ThingWorx Platform (application key authentication).
Axeda assets and ThingWorx Platform (token authentication).
Application Key Authentication
As part of configuring the eMessage Connector, you generate an application key on the ThingWorx Platform. This application key is set into the Connector’s configuration, and is used to authenticate requests that are made by the Connector against ThingWorx Platform.
Both the value of the application key, and the user account under which the key was generated, are used by the ThingWorx Platform to determine if the requested action is permissible or not. For example, if the key is a match, but the user account associated with the key does not have sufficient permissions, the request is denied.
Token Authentication
Tokens are used to authenticate requests from Axeda assets against the eMessage Connector. Upon startup, the agent itself generates a token and includes it in the registration message and in each subsequent message that it sends to the eMessage Connector. After the Connector forwards the registration message (first message) to the ThingWorx Platform, the token value is stored as a property on the Axeda entity in ThingWorx and used to authenticate the agent on subsequent messages. The default name of the property is token.
When the eMessage Connector receives any requests from an Axeda asset, the model and serial number, either as configured by you, or supplied as part of a migration process from the Axeda Platform, are used to locate the corresponding Axeda entity. If no match is found, the request cannot be processed. If a match is found, the token that accompanies the message is compared to the known value to determine if processing can continue.
It is also possible to force a token to be “pre-provisioned” by clearing the check box for the parameter, Update Token on First Message, in the TokenPropertyAuthenticator configuration. In this case, if no value is sent up for a token, no match will be found and the request cannot be processed. For information on setting this parameter, refer to Configuring the TokenPropertyAuthenticator (eMessage Connector).
* 
Currently, a subscription to the token property exists on the DataChange event in the Axeda.Asset Thing Shape. This subscription invokes the process to clear the authentication result from the cache on the eMessage Connector. At this time the property name is token. If you create another property to hold the token value, you need to create a new subscription on the DataChange event and point it to the name of the new property. The new subscription needs to ensure that the authentication result is cleared from the cache.
For more information on how the TokenPropertyAuthenticator validates tokens, refer to TokenPropertyAuthenticator Behavior (eMessage Connector).
Was this helpful?