Advanced Device Connectivity (ADC) Overview

Exosite added a rich set of features to the Murano IoT platform called Advanced Device Connectivity (ADC)—enabled by the Murano device gateway. These features add functionality to how devices are identified and provisioned as well as how they can be managed and configured in Murano.

To see if your account is enabled for ADC, check your account plan and look for the message, "Your account has access to Advanced Device Connectivity." If you do not see this message and would like to request ADC access, you may email support@exosite.com to have it enabled.

The sections below summarize and describe the ADC feature set. In all the features below, the various configuration/settings parameters can be selected for both the Product UI as well as Murano CLI.

Communication and Authentication

This section covers the methods devices can utilize in order to communicate with Murano.

Communication FQDN

Devices will no longer be able to use the m2.exosite.com hostname for communication via the HTTP Device API. Previous incarnations of Exosite's IoT platform (i.e., One Platform, Murano) allowed devices to use this hostname as well as the hostname of their Vendor account, <VENDOR>.m2.exosite.com, where <VENDOR> is the name of their business account. Exosite has sunsetted the concept of a Vendor account and introduced the Product. Devices communicating to ADC-enabled accounts are required to use the fqdn assigned to the Product device gateway you intend it to communicate with. This fqdn can be found in the Product UI as well as via the Device2 getGatewaySettings API method.

Authentication

A Murano device gateway can be configured to use two different methods of authentication:

Token Authentication

When the Token method of authentication is selected, a device can provision a private authentication Token to be used in subsequent communications to uniquely identify and authenticate itself to the Murano device gateway. If provisioning is disabled, then device authentication Tokens must be managed via Murano CLI and UI tools and manually associated and stored on the device.

NOTE: An authentication option available with the Token method can disable the use of TLS connections, allowing unsecured HTTP communication between a device and the Murano device gateway. The use of this option is highly discouraged and maintained in Murano as a development tool for easing the validation and development of firmware on a device connecting to Murano.

TLS Client Certificate Authentication

When the TLS Client Certificate method of authentication is selected, a device uses a unique X509 private and public key that Murano uses to both authorize and identify the connecting device. Murano will use the X509 credentials (which can be provided by a PKI vendor, for instance) to authenticate the device and then subsequently identify it via the /CN element of the certificate subject. The device's identity will be the <value> in /CN=<value>.

Provisioning

Several features have been added and enhanced around the topic of device provisioning.

Identity Format

This feature defines how connecting devices must identify themselves or be considered invalid and ignored in successive communication attempts. Devices are identified differently based on the authentication method chosen—Token or TLS Client Certificate. In the case of Token authentication, the identity of the connecting device is determined by the id field of the HTTP Device activate API method. In the case of TLS Client Certificate authentication, the identity of the connecting device is determined by the common name /CN value of the client certificate. In both of these methods, the Identity Format must be adhered to in order for the device to be recognized in communication requests.

Presenter Identity

The Presenter Identity configuration setting allows devices to identify and provision themselves at the time they first connect to Murano. The Presenter Identity setting simply means that devices connecting to a Murano device gateway do not need to have their identity be whitelisted in advance and that the Murano device gateway will auto-whitelist the identity the device "presents."

This setting is a boolean that, when set to true (default), allows devices to provision themselves and any device identity to communicate with the Murano device gateway. When set to false, devices connecting must first be whitelisted onto the device gateway in order for its requests to be honored.

IP Whitelisting

IP Whitelisting can be used to restrict device provisioning. The IP whitelisting manages known IP addresses that devices will connect from when connecting to Murano for the first time. This feature is useful to IoT vendors working closely with hardware manufacturers. If a connecting device's requests originate from an IP address not in the configured whitelist, then the device will be ignored. Once the device has connected from an IP address in this whitelist, it can make successive requests from any other IP, and its requests will be honored.

Locking

This feature allows Murano Product administrators to revoke the communication privileges on a per-device basis. Marking a device as locked will cause all connection attempts by the device to be ignored. This can be useful, for example, in development or during in-field management to temporarily disable device communications.

Logging

When devices connect, disconnect, make provision attempts, and publish data, these events will be logged. The logging events are not saved, so they can only be viewed in real time either by the Logs section in the Product UI or Murano CLI. This is most useful in debugging and development applications.

Resources

Resource definitions have been updated to specify the available state fields of all devices connecting to the device gateway of a Murano Product. A Resource is identified by an alias that has a data format (string, number, or boolean), and optionally a restricted set of allowed values and whether it is modifiable from "the cloud." Each device identity's state is maintained with the latest reported and set values for every resource.

Resources that are modifiable from "the cloud" have their set value updated when non-device agents update the device state. Resources that are not modifiable from "the cloud" only have their state updated by the values the device reports. The term "the cloud" is a placeholder for any agent such as a mobile or web application that can be authorized to set the device state.

From the connecting device's perspective, there is no change. That is, getting a resource will get the current "set" value in the device's state. Anytime a device posts data to a resource, both "reported" and "set" values in the device's state are updated, whereas when "the cloud" uses the setIdentityState API method, it only updates the "set" value.

Content

The Content area is a simple file storage area that devices can download things like firmware updates and is unique to each Product.

Additional Resources

For more in-depth, technical information on the ADC feature set, please refer to the resources below:

ADC FAQs

Q: How is Murano's Advanced Device Connectivity different than One Platform?

A: The following high-level features highlight some of the many improvements: