The release notes below are intended to provide descriptions of any new features, improvements, and bug fixes included in this release of Exosite’s Murano platform. Where applicable, an explanation of the user impact is provided, as well as any additional information that may be useful.
This is a major Murano release—it includes multiple new capabilities that are part of the Advanced Device Connectivity feature set, including new security, advanced device/lifecycle management, and product/application capability additions.
All new businesses created as of this release will have the Advanced Device Connectivity features described below. Existing businesses will be migrated over the next 90 days.
- Advanced Device Connectivity (ADC) Features:
- Communication Fully Qualified Domain Name (FQDN) change
- Each product now has a unique device communication URL for device communication over the HTTP Device API (see Communications FQDN). This allows you to work with logs from low-level device communications since all traffic belonging to your product uses a unique FQDN.
- All device management APIs now use ProductID as the primary management index. This simplifies the APIs and allows Team Member permissions management as administered by the business account.
- Authentication & Security
- Device authentication methods now include both Token (Client Interface Key) and TLS Client Certificates (see 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.
- All communications require use of a secured transport by default. A special “Dev Mode” setting is supported for devices that use payload-level encryption over the FQDN <productname>.devmode-m2.exosite.io
- Device Provisioning
- Flexible Provisioning Whitelisting
- Products can be configured to allow Devices to register their own identity (identities do not have to be whitelisted). If not configured in this way, Devices connecting to Provision Communication Credentials must have their identities whitelisted, or the device communication will be rejected and Provisioning will not proceed.
- An identity format specification can be set to ensure connecting Devices use an expected identity pattern. If the pattern is not matched, the Provisioning will fail and subsequent communications from that Device will be ignored.
- Extended Provisioning methods. As always, a Device must have Provisioned Communication Credentials with Murano in order to communicate. However, with this release, the Provisioning methods have been extended:
- 1) Vendor pre-configured provisioning. The Administrator sets up the device Communication Credentials (either Token or TLS Client Certificates) in advance of the device communicating. In this situation, the device may immediately start communicating data with Murano without having to go through device-initiated Provisioning steps.
- 2) Device initiated Provisioning. This is different depending on the device Authentication method set for the Product. For example, if the “Token” authentication method is set, the Device initiates provisioning by sending its identity, and the server responds with a private key “Token” that is subsequently used by the Device to communicate with Murano. If “TLS Client Certificate” authentication method is set, the device connects with its client certificate in the TLS handshake, and the server looks up the identity specified in the certificate. If the identity is not yet provisioned, the server auto-associates the certificate with the identity. After that, only the device having the private key matching the certificate public key can communicate as that identity.
- Provision IP Whitelisting
- It is now possible to restrict IP addresses that can Provision devices. This restriction is often used when device Communication Credentials are initially Provisioned from a factory floor.
- Advanced Device Management Capabilities
- Locking: communication privileges can now be revoked on a per-device basis. Marking a device as locked will cause all subsequent connection attempts by the device to be ignored.
- Force-reprovision: devices can be forced to reprovision on a device-by-device basis. Force-reprovision expires the device's credentials, requiring the device to authenticate and provision new communication credentials. For example an IoT security policy may require devices to reprovision every N days.
- Settable Provisioning windows: single or batch devices that are being whitelisted by an administrator may be given a specified Provisioning window within which they must connect. This is useful for manufacturing runs or retail releases to limit the Provisioning window to the expected run or shelf-duration only.
- Batch whitelisting and identity management system integration: batch whitelisting is now supported via CSV upload or identity system integration. This is useful when your organization may manage certificates or other product information in another identity management or manufacturing management system.
- Logging: device activity for connect, disconnect, and data reporting is logged on the Products’ FQDN and accessible via the UI and CLI. This is useful for development and for monitoring device behavior.
- Firmware management updates: the Product’s firmware and content storage functionality has been expanded and is now accessible to internal scripts and also has a new UI for listing and management. This simplifies managing over-the-air updates and firmware version for the Product.
- Device Events: upon successful Provisioning by a device, events are broadcast to the internal Product context where security and housekeeping functions can be triggered that are specific to the Product. This allows the Product to be choreographed with manufacturing systems and IT anomaly detection systems.
- Device Communications
- Resource updates: resource definitions have a new UI and behave slightly differently. They can now be protected so that only devices can modify their contents, and data validation can be enforced on the values.
- Command/Control Resource support: if a Resource is set to allow modification by something-other-than-the-device (e.g., an Application that wants to control the device), setting the Resource by the Application will only modify the Resources’ <setval> property, whereas setting the Resource by the device will modify both the <setval> and the <reportval> properties. This provides a clear workflow for managing command/control messages that are set by the cloud that can be acknowledged by the devices.
- Connection state visibility: the eventing system and the UI now shows if a device is currently long-polling (has an open session) or is disconnected. This is helpful to create event-driven command/communications with low power devices and devices that require soft real-time communication.
- Solution Menu item & Application terminology updates - With the introduction of Advanced Device Connectivity, every Product now has a full Solution capability under the hood (eventing, scripting, API management, static content capabilities, etc.). Therefore, the name of UI-focused Solutions have been changed to “Applications.” Murano now has Application Solutions and Product Solutions—both of which have full Solutions under the hood, but which are equipped with different Services and UIs to enable the specific needs of Applications and Products.
- Advanced Application support for multiple Products - Applications that communicate with multiple Products can now define custom rules/scripts for each Product. This simplifies the maintenance of Application business logic as it relates to Product data.
- Auth0 - The Auth0 service has been extended to add an operation for getting logout URL.