Desktop Alert has announced the companies planned release of its BlackBerry Mass Notification mobile application at BlackBerry World.
“Initial reviews from our customers such as NATO, the U.S National Guard and other U.S. Department of Defense agencies has been very encouraging. The registration and activation process only requires the entry of a simple 6 digit code to activate the BlackBerry application on private networks,” said Howard Ryan, CEO Desktop Alert Inc.
Desktop Alert provides mobile applications for BlackBerry, Android, Kimble and iOS that can be installed on usersÃ¢â‚¬â„¢ mobile devices and activated with a Desktop Alert server to receive mobile alerts (via push notification), and view recently received mobile alerts, and send alerts (if the user has the appropriate permissions to execute scenarios). In order to provide this functionality, the mobile app needs to communicate with its associated Desktop Alert server.
In most enterprise network environments, a Desktop Alert server running on-premises is shielded from the outside world behind layers and layers of firewalls and other protective network devices. Inbound connections from the internet are deliberately blocked or are extremely constrained due to the widespread security threats inherent in the internet.
Only devices on the internal network, such as domain-joined computers, can communicate directly with the on-premises Desktop Alert server. Devices on the internet (that are not connected to the internal network) cannot communicate with an on-premises Desktop Alert server because any inbound connections from the internet are blocked.
Mobile devices arenÃ¢â‚¬â„¢t usually connected to an enterpriseÃ¢â‚¬â„¢s internal network, if at all. Most of the time, mobile devices are connected to the internet, either via a cellular carrierÃ¢â‚¬â„¢s data plan (e.g. 3G or LTE) or personal/third-party Wi-Fi networks. This presents a challenge: how can mobile devices on the internet (that are not connected to the internal network) communicate with an on-premises Desktop Alert server?
HereÃ¢â‚¬â„¢s how it works: the on-premises service connects to the relay service through an outbound port and creates a bidirectional socket for communication tied to a particular rendezvous address. The client can then communicate with the on-premises service by sending messages to the relay service targeting the rendezvous address. The relay service will then Ã¢â‚¬Å“relayÃ¢â‚¬Â messages to the on-premises service through the bidirectional socket already in place. The client does not need a direct connection to the on-premises service nor does it need to know where it resides. The on-premises service doesnÃ¢â‚¬â„¢t need any inbound ports open on the firewall. This is how most instant messaging applications work today.
Microsoft provides a concrete implementation of such a relay service called the Azure Service Bus Relay Service.
Desktop Alert makes use of the relay service, allowing our mobile apps to securely communicate with on-premises Desktop Alert servers. Full architectural details are available here.
“Numerous mass notification vendors offering mobile notification applications for private networks (non-cloud environments) require very onerous authentication steps by the end-user such as entry of a login name, password, proxy data and complex/long subscription URLs. These manual entries are cumbersome and ultimately result in the apps registration failure from typos and confusion. The Desktop Alert mobile application registration process takes 15 seconds or less using a simple 6 digit code,” Ryan added.
Connections from the mobile app to the relay service are secured using HTTPS (TLS/SSL). The communication consists of simple REST-style requests that are authenticated; only authenticated requests are allowed.
Desktop Alert customers can now download the pre-release version of the application at the company website.