Four key enterprise features in iOS 7 that aren't ready to go out of the box

Credit: Steven Straiton via Flickr

Apple's iOS 7 offers many new capabilities to IT departments regardless of whether the iOS devices they manage are employee-owned BYOD devices, more traditional locked-down corporate devices, or fit into the emerging choose your own device (CYOD) or company-owned personally enabled (COPE) models that are beginning to take hold in Europe and the U.S. respectively. While many iOS 7 additions are easily understood by IT pros and can be implemented immediately via the appropriate enterprise mobility management solutions, there are a handful that aren't quite as easy to understand, have unexpected limitations, and that come with unexpected requirements.

Of the nearly two dozen new mobile management capabilities, there are four that aren't quite the easily implemented options that they seem: enterprise single open-in management, managed app configuration, enterprise single sign-on, and per-app VPN.

Open in management: Less restrictive than containerization but more limited

One of the most attractive additions to iOS 7 from an IT perspective is open in management (also called managed open in). The concept of this feature is very simple. It allows an administrator to limit which apps and services appear in the share sheet of iOS 7 apps. That affords a form of de-facto containerization and data leakage protection, and is almost transparent to the user since they simply don't see any obvious sign of restriction.

At first glance, this is an incredible capability. The challenge is that the settings are global and cannot be set on a per-app basis.

Managed open in is based around Apple's emerging concept of managed vs. unmanaged apps (those installed or provided by the IT department vs. those installed by individuals from the public iOS App Store). It offers essentially four basic choices for allowing or restricting sharing of content between apps.

  • Managed apps can send data to both managed and unmanaged apps (essentially no restriction).
  • Managed apps can send data only to other managed apps (restricting "work" apps to only speaking to other "work" apps, but not to personal apps).
  • Unmanaged apps can send data to both managed and unmanaged apps (the major restriction here is that "work" apps cannot send data to personal apps but can receive content from them).
  • Unmanaged apps can send data only to other unmanaged apps (again restricting personal apps to only personal content).

This feature does create a security baseline by separating work and personal apps without much impact on the user experience. But you can't configure rules based on the type of data or creating app-specific rules. If a user has enterprise apps A, B, and C installed as managed apps, the three can exchange data freely. You cannot create a rule that says app A can share with app B but not with app C.

For organizations that have invested in containerization or mobile app management (MAM) solutions, this feature isn't going to be particularly useful because you probably already have better and more granular capabilities. For organizations that haven't mane such an investment or that are still determining MAM and content management strategies, this is a great option because it puts in place some controls (including control for user privacy by limiting the sharing from unmanaged apps) while investigating other options. Some organizations may also find that this basic capability effectively meets their needs.

Managed app configuration: A great idea that requires developer support

Like Windows or Mac applications, most iOS apps have a series of settings options that allow the user to tailor the app to their needs, link it to network resources, specify user credentials, and activate or disable certain features for both personal preference and data security needs. Although many iOS features can be pre-configured using a mobile management tool or manually installed configuration profiles, until iOS 7 there wasn't an easy way to ensure that apps were properly configured for use in a specific company or department.

iOS 7 introduces the concept of managed app configurations, which allow administrators to push down app configurations as well as the app itself. The approach used to enable this capability in iOS 7 is similar to the way Apple has been allowing IT administrators to pre-configure OS X apps for years, or the ways in which PCs can be managed by Active Directory group policies. When an organization deploys a managed app to iOS devices (by pushing the app out over the air or by including it in an enterprise app store), administrators can also push out configuration data for that app.

The limitation here is that developers must choose to support this feature and that they need to offer some information about what features or options can be managed. That includes not just describing the options, but what type of data each option accepts -- a simple enable/disable switch, a URL for a cloud service or internal server, user account information, or a custom list of specific items. Apple isn't requiring developers to implement these capabilities, and even if a developer embraces them, there's no guarantee that all settings will be supported or will be supported immediately. Some developers may have opted wait to add such capabilities in order focus on the other challenges to getting their apps iOS 7 ready.

The good news, however, is that many business app developers are more likely to see value in supporting managed app configuration than, say, game developers. In the end, developers may even see this as a way to stand out in the crowded business and productivity categories of the app store. That could lead to fairly widespread support over time.

Per-app VPN: Increases privacy and security if your VPN server can support it

Per-app VPN offers a huge advances for BYOD users. In a traditional VPN where all network traffic gets sent through the secure tunnel created between a user's device and the VPN server, it gets routed through the corporate network as though the device were connected to that network. That means that personal emails, connections to social or gaming networks, and even personal web browsing can be sent through a corporate network.

That impacts users in a couple of key ways: it can reduce performance because everything is being routed through the VPN and corporate network, and it means that personal data is flowing down the pipe into the corporate network, which could raise some major privacy concerns.

One way to limit these effects is to use an on-demand VPN connection that is triggered only when services or resources on the corporate network are requested by an app. But that isn't a perfect solution as some personal data may still go through the connection as well. With iOS 7 introducing true multitasking, the chances for background apps to request or send data across an on-demand connection increases significantly.

Per-app VPN offers the greatest streamlining of VPN use because only specific apps can establish or access the connection(s).

For any VPN connection to function, both the VPN client built (in this case the client built into iOS) and the VPN server used by an organization to support remote users must share common capabilities, like support for the same VPN protocols. The same goes for additional functionality, like two-factor authentication: Both the client and server need to support those features.

So it goes for per-app VPN connections in iOS 7. The appropriate capability must exist not just in a user's iPhone but also in the employer's network infrastructure. By and large, the major vendors are building such capabilities into their products, but many organizations may need to update the appropriate systems via a patch or firmware update in order to support this feature. It's also possible that some older solutions may not be supported and may need to be replaced.

Enterprise single sign-on: Effortless authentication if you're on the corporate network

Single sign-on has been one of the hottest areas of interest since Apple previewed the business and enterprise additions to iOS 7 earlier this year. I took an early look at Apple's approach to enterprise single sign-on around the time of the iOS 7 launch. Since then, more information about single sign-on has been released by some enterprise mobility and mobile management companies. Of particular interest is support for Kerberos authentication, which is the underpinning of most enterprise environments and a key component of Active Directory.

Using Kerberos allows iOS devices to perform as full digital citizens on an enterprise network. That's an incredible advantage from a security perspective because it doesn't require a device to store user passwords or rely on adjunct technologies to facilitate access to enterprise systems and resources. The challenge is that Kerberos is typically deployed within a secure or trusted network and not directly exposed to the Internet at large because doing so could severely comprise the security that Kerberos offers.

This creates an issue when users are trying to access secure resources remotely. Using a secure corporate Wi-Fi network provides iOS devices access to Kerberos authentication because they are using a trusted network. A home network, public Wi-Fi, and even a cellular connection are not trusted networks and don't provide secure access to Kerberos systems easily accessible in the workplace.

This is a limitation, but it's one that can be mitigated by the use of a VPN connection. That connection can come in different forms, however. It could mean a manual VPN session initiated and terminated by the user; an on demand VPN connection when certain URLs or network resources are requested; or a per-app VPN. There is no one "right" choice of these three options. The decision should be guided by the security posture of an organization, what types of resources users need to access remotely, what is most convenient to users, and what the existing network supports for remote access. 

From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies