Enterprise Mobile App Challenges, Part 2

This is a continuation of an earlier post, “Enterprise Mobile App Challenges, Part 1”.

Challenge 3: Connectivity

These apps need to talk to backends. Are these servers inside the corporate network or not. For those services on the Internet connectivity seems pretty simple. But what about those services on the internal network behind the firewall? There are a few choices here:

  • Device VPN: The device itself VPNs into the corporate network. This works but presents management and usability problems. We need the VPN to be automatically set up (we cant expect the user to do it), we need it to start on demand and odd things will happen if the user tries to do other things.
  • On demand per app VPN: This varies from platform to platform:for example Samsung Knox, ios7
  • Reverse Proxy: Basically a server straddling the firewall that proxies the traffic from the device into the backend server. Many commercial and open source tools exist: Apache.
  • Outbound relay / rendezvous: In this case the server calls out to a system on the internet. The app calls the same service and hence they can pass messages. This is by far the most complicated solution to implement but has the advantage of not requiring firewall changes. An example of this type of technology is Azure Service Bus.

So what is Centrify doing? Our device management solution can manage the VPN and per app VPN options. We have an on premise server that we use to relay traffic from our cloud service to various on premise services (AD being the main one). This uses the relay / rendezvous technology I described earlier. We are wondering if allowing customer apps to use this secure pipeline for access to their backends would be useful – let me know.

Challenge #4: Command and control

Many systems need to allow communication to the application, as opposed to communication from the app to various services. Examples:

  • An in-app alert generated from a management tool
  • An app on device 1 needs to tell an app on device 2 to do something

(Reminder – in the first post I already discussed data and configuration change management)

Traditional solutions to this that use TCP / HTTP polling or long reads work but they are a tough tradeoff between responsiveness and battery drain. You really need to use services provided by the device platforms: APNS for iOS and GCM for Android. The problem is that these are hard to use and a very different on each platform.

What are we doing? We are adding support for these features to our mobile SDK. An application simply call one API that registers a callback to be invoked when a message arrives. We deal with all the plumbing and platform specifics. On the other end we provide UI in our cloud admin console plus REST APIs that any other application can call to dispatch a command to the device. We don’t impose and semantics on the messages; we just pass an arbitrary JSON payload to the application on the device

I hope this pair of articles was useful. Did I miss and major challenges that you face?